Preview Everything
Every change is deployed to its own environment before merge.
The Principle
Stakeholders should review working software, not specs, mockups, or screenshots. Every pull request — no matter how small — gets its own isolated preview environment. The person who requested the change can click a link and see exactly what will ship.
This compresses the feedback loop from "wait until staging" to "see it now." It means a domain expert can review a change in minutes, not days. It means fewer surprises in production.
You're doing it right if: A domain expert can click a link and see exactly what will ship — without asking anyone.
Implementation
- PR preview infrastructure (Vercel, Netlify, Railway, or custom)
- Automated deployment on every push to a PR branch
- Shareable preview URLs posted in PR comments
- Preview environments that mirror production config
Shared Validation
CI/CD, agent hooks, and pre-commit hooks all run the same pipelines.
The Principle
There's one source of truth for "what does good look like" — and it runs everywhere. On the developer's machine. In the agent's environment. In the CI/CD pipeline. The same checks, the same rules, the same validation.
This eliminates the "works on my machine" problem for quality. If something passes locally, it passes in CI. If an agent generates code that passes its checks, it passes yours.
You're doing it right if: A check that fails in CI would have failed locally and in the agent's environment too.
Implementation
- Shared configuration files for linting, formatting, testing
- Pre-commit hooks that mirror CI checks
- Agent environments configured with the same validation
- Single source of truth for all quality rules
Democratize PRs
Everyone on the team can create pull requests, not just engineers.
The Principle
The ability to propose changes is not limited to those who can write code manually. Product owners, designers, domain experts — anyone who can describe a change can create a PR, with the help of an agent.
This removes the bottleneck of "waiting for an engineer to get to it." Small changes (copy, configuration, styling) can be shipped by the person who knows what needs to change — without a handoff.
You're doing it right if: Your product owner shipped a copy change last week without asking an engineer.
Implementation
- LLM coding tools accessible to non-engineers
- Clear guidelines on what's "small" vs what needs engineering review
- Training for non-engineers on the PR workflow
- Agent access configured for all team members
Async Agents
Coding agents run remote, in the cloud, in parallel.
The Principle
Engineers are not bottlenecked by their local machine or their typing speed. Agents run in the cloud, asynchronously. One engineer can kick off 5 agents on 5 different tasks and check back when they're done.
This changes the unit of work from "what can I type in an hour" to "what can I direct in an hour." The engineer's job becomes specification, direction, and review — not implementation.
You're doing it right if: Your engineer has multiple agents running right now — and isn't watching any of them.
Implementation
- Cloud-based agent infrastructure (not just local Copilot)
- Async task management (agents report back when done)
- Parallel execution across multiple cloud environments
- Notification system for agent completion
Codified Standards
Design systems, code style, architecture, and docs are written down and available to agents.
The Principle
Your agents should never guess at your preferences. Design systems, code style guides, architecture principles, documentation standards — all of it should be written down, version-controlled, and available as context to agents.
These standards are enforced during generation (when the agent writes code) and review (when the agent or pipeline checks code). The agent reads your rules and follows them.
You're doing it right if: An agent's first attempt at a component matches your design system — because it read the design system.
Implementation
- Design system documentation in a format agents can consume
- Style guides included in agent context/system prompts
- Architecture decision records (ADRs) available to agents
- Automated enforcement during generation and review
- Version-controlled standards that update agent behavior when changed
Shared Agent Context
Agent rules, plugins, and prompts are versioned and shared across the team.
The Principle
Everyone's agents should behave the same way. Agent configuration — system prompts, plugins, rules, tool access — is version-controlled and shared. A new team member's agent behaves identically to a veteran's on day one.
This eliminates the "my agent does it differently" problem. It makes agent behavior reproducible and auditable.
You're doing it right if: A new team member's agent behaves identically to a veteran's on day one.
Implementation
- Agent configuration stored in version control
- Shared prompt libraries accessible to all team members
- Team-wide plugin/tool configuration
- Onboarding documentation includes agent setup
- Regular syncs to update shared context
Agents in Every Conversation
Agents available in meetings, Slack, email — ready to act.
The Principle
The gap between "we should do X" and "X is in progress" should be minutes, not days. Agents are present in every conversation — meetings, Slack threads, email chains. Any conversation can spawn a spec, a ticket, or an agent action.
This collapses the translation layer between "discussion" and "work." You don't have to wait for someone to write up the meeting notes, create a ticket, and assign it. The agent was there. It can act.
You're doing it right if: Someone mentioned an idea in standup this morning and it's in PR review this afternoon.
Implementation
- Meeting transcription + agent integration
- Slack bots that can trigger agent actions
- Email-to-action workflows
- Voice-to-spec pipelines
- "Do this" commands that spawn agent tasks from any channel
Unified Dev Environment
Agents and developers work in the same coding environment.
The Principle
When an agent writes code, it runs in the same context a developer would use. Same dependencies. Same configurations. Same access. Same environment.
This eliminates "the agent couldn't access that" and "it works differently in the agent's environment." What works for the agent works for the developer and vice versa.
You're doing it right if: You've never said "the agent couldn't access that" or "it works differently in the agent's environment."
Implementation
- Dev containers / reproducible environments
- Cloud-based development (same infra for humans and agents)
- Shared secrets/access management
- Environment parity enforcement
- Single environment definition used by both humans and agents
Show Don't Tell
Put ideas in code, get them in front of customers, walk back rapidly if wrong.
The Principle
Prioritize putting ideas in code over debating them in documents. Get working software in front of customers as fast as possible. Structure everything to be walkable-back — easy to delete, easy to revert, easy to pivot.
It's cheaper to build the wrong thing and learn than to plan the right thing and wait. The cost of being wrong has dropped; the cost of being slow has not.
You're doing it right if: Your last three product decisions were made after seeing a working prototype, not after a planning meeting.
Implementation
- Prototype-first culture (build before speccing in detail)
- Feature flags for easy rollback
- Small, reversible commits
- Customer feedback loops measured in hours
- "What would it take to try this?" as the default question
Data Accessible
All system data accessible in very few API calls, available to all agents and systems.
The Principle
No data locked in silos. No "we'd need to build an integration for that." Agents can query, read, and act on your data as easily as a team member can.
When data is accessible, agents become capable. When data is locked away, agents are crippled. The accessibility of your data determines the ceiling of what your agents can do.
You're doing it right if: An agent can answer "what happened with customer X last week?" without custom integration work.
Implementation
- API-first data architecture
- Minimal calls required for common queries
- Agent-friendly authentication and access
- Data accessible to all internal agents and systems by default
- Documentation that agents can read to understand data schemas
Small Pods
One domain expert + 1-2 engineers, no more.
The Principle
Teams consist of one domain expert and one to two engineers. No more. No separate PM. No separate designer. No separate QA. The roles overlap. The pod is the unit of shipping.
Small pods eliminate coordination overhead. Everyone knows what everyone else is doing. Decisions happen in minutes, not meetings. The domain expert can ship small changes. The engineers can make product calls.
You're doing it right if: You can name every person on your team without pausing.
Implementation
- Maximum 3 people per pod
- Domain expert with taste and stakeholder context
- 1-2 engineers with system knowledge
- Overlapping responsibilities, not siloed roles
- Pod-level ownership of outcomes, not task-level ownership
Complexity-Based Process
Low-complexity changes merge automatically with no sign-off; process scales with risk.
The Principle
Not every change deserves the same process. A typo fix and an architecture change shouldn't go through the same approval flow.
Define complexity tiers — based on lines changed, files touched, risk surface, or type of change. Low-complexity changes that pass automated validation merge automatically. No sign-off. No approval. No waiting for a human. Higher-complexity changes get more scrutiny — but even then, the goal is speed.
| Complexity | Examples | Process |
|---|---|---|
| Low | Typo fix, copy change, color tweak | Auto-merge on passing CI |
| Medium | New component, feature flag, minor logic | Automated review + 1 human glance |
| High | Architecture change, data model, security | Full review, explicit sign-off |
You're doing it right if: Your designer fixed a button label and it was in production 10 minutes later — without pinging anyone.
Implementation
- Automated complexity scoring for PRs
- Auto-merge rules for low-complexity changes
- Clear, documented criteria for complexity tiers
- Automated validation as the quality gate for low-complexity
- Escalation paths for edge cases