Agentic software engineering: where autonomous agents make sense – and where they do not

“Agentic” is currently the label for everything between autocomplete and the idea that a system develops itself. In between lies a field where real work happens – if you know which tasks tolerate autonomy and where it reliably becomes expensive.

1. What “agentic” means

A system is agentic when it breaks a task into steps, uses tools, evaluates results and continues on that basis – across several rounds, without each step being triggered individually. What separates it from plain code generation is not model quality but feedback: the agent sees what its action did.

From that follows the single most important condition: autonomy works only as far as reliable feedback reaches. Without an checking authority the agent flies blind – just faster than a human.

2. Five maturity levels

Most teams work productively at levels 2 and 3. Level 4 pays off for well-bounded types of task. Level 5 today makes sense mainly where results are cheap to check and mistakes have no consequences.

3. When a task is fit for autonomy

Four criteria that should hold together:

1. Checkable. Something automatic establishes success – tests, compiler, schema, contract.
2. Bounded. The affected area can be named and is limited – not “the application”.
3. Reversible. A wrong result can be discarded without breaking anything.
4. Describable. The goal can be phrased in a few sentences such that two people understand the same thing.

Typical candidates that meet all four:

• migrations along clear rules across many files,
• adding test coverage for existing, stable modules,
• fixing known defect classes for which a reproducible test case exists,
• dependency updates followed by a test run,
• translating between formats when a schema defines both sides.

4. Where autonomy fails

• Unclear requirements. The agent then solves a plausible neighbouring version of the problem – thoroughly and across many files.
• Architecture decisions. Nothing automatic answers “is this the right structure?”.
• Domain edge cases. What is correct in domain terms is not in the code – it is in the heads of the business side.
• Irreversible actions. Migrations of production data, deployments, permission changes.
• Poorly tested legacy systems. Without feedback, exactly the condition autonomy rests on is missing.

5. The loop: plan, act, check

A productive run almost always follows the same pattern: plan, execute the smallest meaningful step, check automatically, evaluate the result, continue or abort. Three details decide the quality:

• The plan is visible before anything is done – misunderstandings are still cheap at that point.
• The check is independent of the proposed change; a self-written test that confirms its own implementation checks nothing.
• Intermediate states are visible, not just the final result. Otherwise there is no way to tell where it went wrong.

6. Abort conditions

Without hard limits an agent runs until the budget or the patience runs out. Sensible limits:

• A maximum number of rounds per task.
• No improvement over several rounds – abort instead of searching for variants.
• Change size beyond a threshold – a human takes over.
• Affected areas outside the approved scope.
• A cost or time budget per run.

An aborted run is not a failure but the cheapest form of error detection.

7. The cost side

Autonomous runs consume compute and produce results that have to be reviewed. Neither is free. An honest calculation accounts for three items: the execution itself, a person's review time, and the probability that a run gets discarded.

For well-suited tasks the arithmetic is clearly positive. For poorly suited ones it is worse than manual work – because review time is spent on a result that is discarded in the end.

8. What this means for teams

The shift in roles is real but less spectacular than usually described: less time implementing, more time scoping tasks, reviewing and shaping architecture. Anyone who can phrase tasks so they are checkable becomes markedly more productive – at heart the same skill that makes good requirements work.

Responsibility is unchanged: whoever submits a change set answers for it – even if an agent produced it. More on this in the pillar article AI in software development.

Checklist: dosing autonomy

Conclusion

Agentic development is neither hype nor a self-runner. It is a tool with one clear precondition: something has to be able to establish success. Where that condition holds, multi-step runs are remarkably productive. Where it is missing, autonomy mainly produces review work.

The practical consequence is unspectacular: invest in good tests, clear contracts and cleanly scoped tasks. That raises the share of tasks fit for autonomy – and pays off regardless of how the tools evolve.