Skip to content
peterengineers.ai

Rethink the Whole Lifecycle, Not Just the Coding Phase

Published 3 min read

  • Engineer
  • Lead
  • Executive

TL;DR

Fast code generation is real, and it is one phase of a longer process. Planning, requirements, design, testing, deployment and maintenance each remain a distinct job, and each can now be carried a long way by an agent: supported, not handed over, because every one still ends in a decision somebody owns. In many organisations, the agents went to the code and the rest of the lifecycle stayed as it was. How much agents contribute depends on how well they are worked into the whole lifecycle, into each phase and into the joins between them: what each phase hands the next, in what form, and whether the next one can reach it at all.

An agent builds a working application in a single run, from a paragraph of description. Almost everyone has now seen that happen, and it does what it appears to do. There is no trick in it. What is worth stopping on is where that run sits in the , the sequence of phases software passes through from idea to operation.

Software development runs through distinct phases, and each one has to be considered.

#

One common way to lay out its phases:

  1. Planning: decide what is worth building, for whom, and at what cost.
  2. Requirements: turn the business need into requirements a technical team can build against.
  3. Design: decide the technical shape (architecture, data, interfaces).
  4. Implementation: write the code.
  5. Testing: establish that the result does what was asked.
  6. Deployment: put it in front of its users.
  7. Maintenance: keep it running, fix it, extend it.

Different people or teams often hold these phases, and none of them was invented for agents.

folds the lifecycle into the prompting: what to build and what it has to do are worked out one prompt at a time. Design decisions still get made, implicitly and prompt by prompt, but nobody checks them, because nobody reads the code.

The business waits on the whole lifecycle, not just on the coding.

#

Many organisations point their agents at writing code and leave the other phases of the lifecycle without them. Requirements still arrive when they always arrived, in the form they always took. The hand-off from requirements to design still happens the way it did. Testing still starts when the code lands. One phase got quicker; everything deciding when work reaches it, and what shape it arrives in, is untouched.

The gap reads differently depending on where you stand. If you write the code, the waiting has moved upstream of you. If you lead a team, the delivery gain you were promised is being absorbed by the phases nobody changed. If you run the business, you have funded one phase and are measuring all of them. One gap, read from three heights.

Agents can support every phase, not just the coding.

#

Every company runs the phases before implementation in its own way, with its own tools. The agentic setup has to fit that way of working: if the requirements live in Confluence, the agent gets access to Confluence and helps write and improve them there.

Each phase also has its rules: how a requirement is written, and what a has to contain before design can start from it. Those rules go to the agent. It applies them, checks a draft against them and says where the draft falls short.

The person still drives. The agent does not define the requirements; it takes the ones a person wrote, challenges them, finds the missing pieces and puts them in a form the next phase can build on.

FROM THE REFERENCE PROJECTA Jira ticket resolved by an agent, with a human in the loop where it matters

A production system engineered this way, taken apart section by section.

A ticket is read with its attachments, analysed against the repository, planned, implemented, reviewed in a fresh context, then written back in business language to whoever raised it. Analysis runs unattended; no file changes until a person has read the plan and agreed to it.

Each phase's output should be a clean input for the next.

#

Treat each join between two phases as an agreed interface. The phase produces its result in a defined form, so the next one knows what it receives instead of inferring it. That matters most for an agent: it works best when it knows what kind of input it is getting.

The other half of the interface is access. When an agent can reach a phase's result on its own, the next phase can start as soon as a person has judged that result ready, without anyone carrying it across, and more of the chain can run automatically.

None of this is an argument for more process. The phases were always there. What is new is that each of them can now be worked with agents, so the work changes for whoever holds a phase, not only for the engineers. A company that wants needs that change in every phase.

Keep exploring