THE
AGENTIC
PDLC
An agent is a colleague, not a tool. The whole of this page follows from that: if you hand a colleague a finished answer and ask them to type it up, you have hired an expensive typist. The work is to give the agent the problem, leave it room to decide, and then judge what comes back.
"Every decision you make for the agent before it sees the problem is a decision you paid human rates for that it could have made in seconds."
This came out of moving a production engineering organization onto agents. Almost every way a team leaves value on the table turns out to be a version of deciding too early.
The Value Curve
Value scales with decision space. The more decisions the agent makes on your behalf, the more you get out of it. Hand over a problem and it explores the solution space and makes hundreds of calls. Hand over a finished mock and it makes almost none.
The Seams Principle
Every spec you write creates a seam, and your team owns every seam. One spec covering a whole feature has none: the agent holds the connections itself. Split that feature five ways and you have bought four integration problems.
For practitioners: the decision test
If you changed the core entity's schema, how many specs would break? If the answer is more than one, they should have been one spec.
| Core entity | What belongs in one spec |
|---|---|
| Support cases | Intake, triage, assignment, communication, resolution, reporting |
| Bulk uploads | Upload, validation, processing, error reporting, history |
| Appointments | Scheduling, queue management, resource matching, notifications |
- Split by domain, not by team. Different users looking at the same system is one spec. Different systems sharing a user is two.
- Personas are not a seam. A customer-facing upload flow and the internal screen that manages the same records are one spec, not two, however many teams touch them.
- Phases are seams in disguise. Plan, then design, then build, with gates between and no re-litigating, is three specs and two seams. It recreates the handoff problem in a new medium.
- Watch for the single author. If a spec is so specific that only its writer can produce or judge it, that person is now the chokepoint for all the work.
What the Human Brings
The role does not shrink. It shifts up the stack. Four things an agent cannot get on its own, and they are the four worth your morning.
- The problem, and why now
- Business context and customer pain. The agent has no way to know either.
- Constraints as durable skills
- Regulation, business rules, org politics, the mission. Encode them once where every run can read them.
- Success criteria as outcomes
- Not features. "No-show rates drop by half." Let the agent generate the features that hit the number.
- The messy context
- Customer quotes, competitor screenshots, the long Slack thread. Do not filter it. Let the agent synthesize.
| Traditional | Working with agents |
|---|---|
| Write detailed user stories | Define the problem and the success criteria |
| Specify UI flows | Evaluate the approaches the agent proposes |
| Decompose into tasks | Set constraints and priorities |
| Manage a backlog of tickets | Steer direction between iterations |
| Write acceptance criteria | Define measurable outcomes |
| Groom with engineering | Hand over messy context and let the agent sort it |
Steering, Not Driving
The cycle alternates. You set the problem, the agent explores, you react to what it actually produced, it refines, you judge against the criteria. Every human turn is a reaction to real output, never a guess about what the output might be.
- YouProblem, constraints, context, success criteria
- AgentExplores approaches, proposes solutions
- You"Approach two, but you missed the data-retention angle"
- AgentRefined spec, breakdown, implementation
- You"This meets the criteria," or "this misses X"
A designer reviewing three generated approaches and saying "that one, but fix the spacing" beats mocking one approach and hoping it survives translation. The trade is prescription for curation, and it runs on one rule about how specific to be:
Red Flags
Warning signs, before the next planning session. Recognize any of these and the move is the same: go back and re-engage the agent with the problem instead of the solution.
- The spec describes screen layouts to the pixel.
- A requirements doc exists, and it already picks phases or a solution.
- Two or more specs share a core entity.
- Someone spent more than a week on the idea before an agent saw it.
- User stories describe micro-interactions instead of outcomes.
- Design produced mocks before the agent explored any approach.
- Specs are split along team boundaries instead of domain boundaries.
- A prompt prescribes output format, section structure, or a deliverable template.
- The work is split into phases with rigid handoffs between them.
- A spec exists that only one person can write or judge.
If you checked any of these, you are paying human rates for work that runs at machine speed.
Everything above keeps a person in the loop.
Each cycle still needs someone to aim it and someone to judge what came back. That works, and it is where most teams should be. It also has a ceiling: you are the throughput. Loop & Harness Engineering is what you build when you would rather be on the loop than in it, with the judging wired into the system and your attention on whether the judging is any good.