The agentic development lifecycle: the hours move to the edges

The first time an agent writes a piece of software for you, the lesson seems obvious. A task that would have taken a developer a day takes twenty minutes. Multiply that across a backlog and the delivery plan shrinks to a fraction of itself.

We have been building this way for most of the year, on our own products and on client work, and we have written our delivery method down as a set of instructions an agent reads before it starts. The lesson we actually learned is different. The lifecycle does not get shorter. It gets lopsided.

Where the hours go now

A software project has always had three parts: deciding what to build, building it, and checking that what was built is what was wanted. For decades the middle part was so expensive that it absorbed the other two. Senior people applied their judgement while typing, almost for free, and most of the checking happened in the same motion.

When an agent does the typing, that incidental judgement disappears. The middle becomes cheap and fast, and the hours move to the two ends. Deciding what to build has to be done properly, in writing, before the agent starts. Checking what came back has to be done deliberately, afterwards, by someone who knows what they are looking for. If nobody schedules those two jobs, they simply do not happen, and the project finds out at acceptance.

The front end is mostly familiar discipline done more carefully. The back end is where the work changes in kind, because an agent's code fails differently from a person's.

The front end: a task an agent can be handed

An agent given an ambiguous requirement does not ask. It produces something confident and plausible against its own reading, and you spend longer discovering what it assumed than you would have spent writing the thing yourself. An unready task is worse than no task.

Ready means the acceptance criterion can be tested without asking its author, the change is scoped to a known part of the codebase, no architectural decision is still open, nothing in it needs a conversation with the client, and the conventions the change must follow are written in the repository where the agent will read them. If the criterion contains the words “appropriate”, “sensible” or “as needed”, it stays with a person.

Then hand over the context, not the instruction. The criterion goes to the agent verbatim from the approved requirements. A paraphrase is a second specification, and now two exist. Alongside it go the file boundaries the change should stay inside and the glossary of the client's domain. The glossary is the one people forget. An agent with no domain vocabulary invents plausible names, and they end up in identifiers, in screen labels, and in the sentence someone reads out to the client. Renaming afterwards touches every file that used the guess.

One more habit pays for itself every time. Acceptance criteria are written as sentences, and sentences hide conjunctions. “A failed delivery records one reason from an agreed list, and the dispatcher sees it within a minute” is two requirements about two different people. We have watched a build satisfy the first completely, with passing tests, while the failed job quietly left the board and the dispatcher never saw it. Split the criterion before anyone builds against it. A criterion that mentions two roles almost always contains two pieces of work.

The back end: agent code fails differently

Human code tends to fail where the human was confused, and the confusion shows. There is a hedge in a comment, a TODO, a variable called temp2. Agent code fails where the specification was ambiguous, and it looks equally confident either way. It does not hedge, it does not leave a note, and it does not ask.

So the review has to look for different things. The code in front of you is usually correct about itself. The useful questions are about what is not there. Is this reachable from the product, or only from its tests? Which criterion does each part serve, and what is the part that serves none? What happens when the input is absent, empty or malformed? Those are three cases, and an agent will routinely collapse them into one. Did it change something it was not asked to change?

Two signals that used to mean something no longer do. The first is style. An agent will match your file layout, naming, comment style and test structure almost perfectly while doing the wrong thing. A diff that looks like it belongs in the codebase has cleared the lowest bar, not the highest. The second is size, which now points the other way. A large diff for a small task means the agent decided something, and you need to find out what. It is usually either scope nobody asked for or a workaround for an obstacle worth knowing about.

The tests it wrote are the riskiest thing in the change

When the same agent writes the code and its tests, the tests can end up asserting what the code does rather than what the requirement demands. They pass by construction, and they will pass forever, including after the code breaks.

For every test in the change, ask one question: would this fail if the code were wrong? Do not answer it by reading. Break the code and watch. Invert the condition, return a constant, delete the line the test is supposed to protect. A test that still passes is decoration, and it is worse than nothing because somebody will count it.

In our own builds this has turned up an ordering test that compared two timestamps written in the same second and passed with the sort deleted, a check that a page did not display a zero that also passed when the page displayed nothing at all, and a test that a command was documented, satisfied by an unrelated sentence elsewhere in the file. Each had a green tick next to it.

Running it beats reading it

A green test suite proves the code does what the tests say. It says nothing about whether the feature can be reached by a user, and nothing about whether the tests assert anything. So the last step before a task is done is to use the product the way a user would. Open the page. Call the endpoint. Click the control. Log in as the other role.

Every one of the following shipped from an agent with working code and passing tests. A panel was fully built, fully tested, and never called from the page that was supposed to show it. Six tasks of work, invisible. A filter toggled a stylesheet class that no stylesheet defined, so the control lit up and nothing was filtered. The logic for creating and assigning work was complete and covered, and no route in the application reached it. None of these was found by running tests or reading the diff. Each was found in the first minute of using the thing.

If a change cannot be driven, a migration or a scheduled job, say what you checked instead and say what remains unverified. An unverifiable change is not a failed one. Describing it as verified is.

When the build shows the specification was wrong

This happens on every real project, and a method that pretends otherwise is how an approved specification quietly stops describing the system. We sort what the build turns up into three kinds. A requirement that cannot be built as written is a defect in the specification, and it goes back to the client as a change. A criterion that two sensible readers interpret differently is not testable, which means it should never have been approved, and it needs one sentence from the client. A requirement that is right but has something missing around it is an ordinary gap, and it becomes a new task against the same requirement with no conversation needed.

What a discovery during the build is not is permission to edit the requirement. The requirements were approved against a named version. Change them silently and the approval on record describes something the client never saw. Record the discovery, take it back, and get a new yes.

Budget for the ends

None of this is new engineering. Testable criteria, verbatim handover, reviewing for omissions, using the product before calling it done. Good teams did all of it before agents existed. What has changed is that it used to be absorbed into the typing, and now it has to be scheduled, by name, with a person's hours against it.

If you are planning a first build with agents, plan it that way. Put the senior people at the front, writing criteria a stranger could test, and at the back, breaking their own code to see whether the tests notice. The middle will look after itself.