Container Hub

SDLC · 2026-10-11 · 4 min read

What agentic development is and why it changes the SDLC

A programmer in 2026 spends more time describing and reviewing than writing. That is not a forecast. It is what happens on a team that works with agents every day. The editor is still open, but what is on screen is increasingly a specification, a plan, a diff waiting for approval. The code itself is written by something else.

We call that way of working agentic development. This article explains what it is, what changes in each phase of the software lifecycle and, perhaps more importantly, what does not change.

What it is

Agentic development is delegating tasks of the software lifecycle to agents: programs built on language models that plan, run tools (editor, terminal, tests, browser) and check their own work before handing it over. The human sets the intent and the standard. The agent walks the path.

The difference from the "smart autocomplete" of three years ago is in the word walk. An assistant suggests the next line. An agent receives a goal, decides the steps, runs them, reads the results and corrects itself. It may take minutes or hours. It can create files, install dependencies, open a pull request. The unit of work stops being the line and becomes the task.

This does not make the programmer disposable. It makes them responsible for different things.

What changes in each phase

Planning

The specification becomes the main artifact. When code is cheap to produce, what is expensive is knowing exactly what you want. A two-page spec with closed decisions and clear completion criteria is worth more than a thousand lines written in a hurry. Planning meetings stop discussing "how long will it take" and start discussing "what counts as done".

Code

The diff is no longer the product. Verification is. If an agent can produce three different implementations in an afternoon, the right question is not "which one is prettier" but "which one passes the tests, meets the spec and is the smallest". Taste still matters, but it applies to review rather than typing.

Testing

Agents write them first, or there is no trust. An agent that implements without a failing test beforehand is guessing, and it guesses with great conviction. The discipline of seeing the test red, then green, stops being an optional good practice and becomes the only reliable signal that the work was done. Teams already doing TDD adapt quickly. The others find out why it existed.

Review

Review intent, not syntax. Generated code tends to be syntactically correct and stylistically uniform. What fails is the framing: the extra feature, the forgotten edge case, the abstraction nobody asked for. The human reviewer reads the diff with the spec beside it and asks whether what is there is what was requested, no more and no less.

Deploy and operations

Agents reading logs and proposing fixes. The same mechanism that writes code can read a stack trace at three in the morning, locate the commit that introduced it and open a pull request with the test that reproduces it. The person on call approves or rejects. The time between symptom and fix shrinks, and so does the fatigue.

What does not change

Three things remain human, and they are the ones that matter.

Responsibility. The agent does not sign the contract, does not answer to the client and does not get fired. Whoever approves the diff owns the diff. This is not a legal footnote; it is the reason review cannot be delegated.

Taste. Knowing that a solution is too small or too large, that an API will age badly, that a name is wrong. Models imitate taste, but they do not have it. Whoever has it remains the scarce resource.

Decision. Which problem is worth solving, which trade-off is acceptable, when to stop. An agent optimises what it is asked for. Deciding what to ask for is the job.

How Container Hub works

In practice, our cycle has three rules.

Short specs, closed before any code. A spec that still has open questions does not go to implementation.

Executable plans, with small tasks, each with its own test and its own commit. The agent follows the plan; deviations are recorded with the reason.

Verification before claiming completion. "It should work" is not a state. A test that ran and passed is.

Calm

The promise of agentic development is not writing faster. It is making fewer mistakes. Speed shows up as a consequence: less rework, fewer incidents, fewer meetings to figure out what someone meant. The programmer of 2026 works more calmly than the one of 2020, not because they do less, but because they do things in the right order.

Ler em português