Most teams adopting AI bolt a coding assistant onto an unchanged process and are disappointed when velocity barely moves. That’s the right amount of improvement for that change. The assistant made the typing faster, and typing was never the bottleneck.
I run this lifecycle on a genuinely complex domain product. What changed things wasn’t a better autocomplete. It was moving agents to the two ends of the lifecycle, definition and validation, and leaving the humans on the judgment in between.
Here’s the whole thing.
The Guiding Tension
We’re too small for ceremony and too complex for chaos. Everything below resolves to one rule:
Capture everything. Execute only what’s fully defined.
Most process failures are one half leaking into the other. Make capture expensive and you lose the signal. Let underdefined work into execution and you burn a week discovering what the ticket meant.
Phase 1: Capture
Anyone in the company can file work. Engineering, product, leadership, support, or an automated alert. The quality bar is zero.
A forwarded customer email is a valid capture. So is a screenshot of a broken screen, or the sentence “login is slow since the last deploy.” Reporters are done the moment they hit save. There is no template to fill out, no severity to guess at, no component to assign.
An imprecise signal beats silence, and making people feel underdressed for the ticket form is how you get silence.
Phase 2: Definition
Definition is a separate step with a different owner, and it’s where the payoff is.
The output is an issue that passes one test: could an engineer or an agent pick this up cold and execute it without a clarifying conversation? That question is the gate. Everything else is scaffolding for reaching it.
An agent does the research lift. Given a raw signal, it reads the relevant source across every repo, queries infrastructure for current state, pulls logs for the relevant window, runs read-only queries against the database for data patterns, scans the tracker for related issues and prior attempts, and reads the product documentation for the decisions already made. Then it writes up what it found.
That’s the shape of the whole system: the human provides intent, the agent provides depth. A one-line bug report becomes an executable ticket without anyone spending an afternoon on archaeology.
Two rules keep this honest. Definition ownership scales with scope, so bugs and chores are engineering’s call while large arcs require product to write a brief first. And context beats ceremony: a forwarded thread with a one-paragraph summary is as valid as a formal document if it gives the executing engineer everything they need. We are not in the business of producing named artifacts.
Phase 3: Execution
Issues are scoped to be atomic and parallelizable, with dependencies declared explicitly. That’s what lets multiple agents work concurrently without colliding, and the dependency graph is the coordination primitive. Nothing blocked ever starts.
Every execution run begins with a mandatory step before any code gets written.
The Drift Check
Time passes between definition and execution. Code moves. The person who defined the ticket usually isn’t the one executing it. So the first thing that happens is a validation of the ticket against the current state of the codebase: do the files and services named in the implementation notes still exist and still match the description, have referenced code paths changed, are the declared dependencies actually resolved, has anything opened or closed since that changes the scope.
If there’s drift, the ticket gets updated first. Then work starts.
This is a five-minute step that routinely saves a day. Executing a confidently stale ticket is one of the most common ways agentic work goes sideways, and it’s entirely preventable.
Isolation Per Unit of Work
Each ticket gets an isolated workspace: its own worktree, its own ports, its own stack. Parallel lanes can’t contend for a database or step on each other’s dev server. When a lane fails, it fails alone.
Phase 4: Validation
Four tiers, each answering a different question.
Tier 1 is static analysis, on every PR, blocking: lint, type-check, unit tests, build. Required status checks, nothing merges red.
Tier 2 runs post-merge against real services and a real database, plus API contract tests and data pipeline validation.
Tier 3 is the interesting one. Before a release, an agent drives a real browser against staging, reads the acceptance criteria off the ticket, executes them as user scenarios, and posts pass/fail with screenshots. Failures block the production deploy.
This tier replaced selector-based end-to-end tests on purpose. Playwright and Cypress suites break on every UI refactor, so teams either maintain them constantly or quietly stop trusting them. A scenario-based agent adapts as long as the goal is still achievable, which means the test survives the refactor. The scenarios are plain language in the ticket’s acceptance criteria, so anyone can write one, including the person who reported the bug.
Tier 4, observability, post-deploy. Error rate compared across a one-hour window before and after. Latency regression alerts past 10%. Issue-specific signals defined in the ticket itself. Every shipped feature has a signal, so deploy confidence comes from data rather than from vibes.
The Part Nobody Expects: PR Batching
Review bandwidth is the bottleneck on a small team. Not authoring. Once agents make authoring nearly free, this gets worse, not better, and the natural failure mode is a queue of thirty small PRs that nobody can get through.
So the defaults push toward fewer, more coherent review surfaces:
- Batch a single throughline into one PR. A mechanical sweep or a migration is one parent ticket with sub-issues, each milestone a commit, closing many tickets at once. A large PR is fine when the change is uniform.
- Size ceiling around 800 lines or 30 files. Past that, split on a real seam or carry a one-line explanation of why it can’t be smaller. Reviewers may bounce an unjustified giant unread.
- Open-PR cap: about three per person, ten team-wide. Merge or close before opening another.
- Review before authoring. A daily sweep of the open queue comes first. Anything unreviewed past five business days gets rebased and re-requested, folded into a sibling, or closed.
These pull against each other deliberately: coherent work batches up, incoherent work splits down. The goal is fewer review surfaces, not a dependency chain of them.
Agents Amplify, They Don’t Replace
The rule that keeps all of this from going wrong: a subagent’s self-report is not evidence.
Everything an agent reports is treated as unverified until it’s checked against something external. Run the code. Read the diff. Execute the test. Open the artifact. An agent’s confident summary of its own work, or a second agent’s opinion with no grounding, is not verification, and folding an unverified claim into a shipped result is how teams get burned by this technology.
Verification and verdict work runs on the strongest available model, always. The whole value of a verification step is that it catches the thing the execution step missed, so it’s the last place to economize.
The same principle shows up in code review, where a diff gets read in parallel by a set of narrow reviewers, each looking for one class of problem, and their combined findings then go through a pass whose only job is catching plausible-sounding nonsense before a human ever sees it. Parallel reviewers are cheap. The filter on their output is what makes them usable.
Every Repo Has a CLAUDE.md
An agent that can’t figure out how to run your tests will confidently write code it cannot verify. So every active repo carries an operating manual written for an agent to read, and a new repo gets one before its first merge. Most of it is the obvious inventory: how to run the service, how to run tests, branch and release conventions, how to run migrations.
The section that actually pays is the list of footguns and things that fail silently. What makes an unfamiliar codebase slow is rarely its complexity. It’s the handful of things that break without announcing it, and those are exactly what a new agent walks into every time.
How You Know It’s Broken
The failure signals are more useful than the process description, because they tell you which part to fix:
| Signal | What actually broke |
|---|---|
| ”What does this ticket mean?” | Definition was incomplete |
| Someone struggles to file a ticket | Capture has too much friction |
| Something breaks in prod after merge | A validation tier has a gap |
| An agent executes the wrong scope | The issue lacked context |
| Work started on a blocked issue | Dependencies were wrong or ignored |
| Nobody works the intake queue | Definition ownership isn’t clear |
| A big feature ships and misses the point | The brief wasn’t written, or wasn’t read |
What Actually Made the Difference
Agents are extraordinary at the research lift that turns a vague signal into an executable spec, and at the tireless verification work humans do badly because it’s boring. Put them there, and keep humans on intent, scope, and the judgment calls about what’s worth building.
The teams getting disappointing results from AI are usually the ones who automated the middle of the lifecycle and left both ends alone.
Running a small team that needs to ship like a larger one? Let’s talk about your process.