Agile replaced upfront design because building the thing is how you find out what it should be. Agentic coding hands that discovery to the agent.
Coding agents write code and tests faster than we do. That part is getting less interesting. But writing code was never only about producing code. Working through an implementation is how a developer finds out where the domain is messier than it looked, and which assumptions don't survive contact with the existing system. It is also where you see what should be simpler, or should not be there at all. That learning changes the solution while there is still time to change it, which is why what you ship is usually different from what you specified, and usually better for it.
When the agent does the implementation, the human stops learning any of that by default.
You can push more thinking into the specification, but that walks straight back into the upfront-design assumptions agile spent a decade escaping. Or you can wait and review the result. By then the agent has made the decisions, and you are reviewing conclusions instead of forming them.
Either way the loop breaks. Iterative delivery depends on implementation creating understanding, understanding improving the next decision, and that decision redirecting the work. Take the human out of the middle and the agent keeps producing code, but nobody is steering.
If you think humans no longer need to read the code, that is a coherent position, and for low-risk changes automated evidence may be enough. But where behaviour is critical, or architecture and business rules still need human judgement, readability is not something you add after the code works. It belongs in the acceptance criteria.
The agent's job is not only to produce code that runs. It is to produce a change the team can understand well enough to decide what comes next.
As implementation gets cheaper, protecting that loop becomes the expensive part.
Coding agents write code and tests faster than we do. That part is getting less interesting. But writing code was never only about producing code. Working through an implementation is how a developer finds out where the domain is messier than it looked, and which assumptions don't survive contact with the existing system. It is also where you see what should be simpler, or should not be there at all. That learning changes the solution while there is still time to change it, which is why what you ship is usually different from what you specified, and usually better for it.
When the agent does the implementation, the human stops learning any of that by default.
You can push more thinking into the specification, but that walks straight back into the upfront-design assumptions agile spent a decade escaping. Or you can wait and review the result. By then the agent has made the decisions, and you are reviewing conclusions instead of forming them.
Either way the loop breaks. Iterative delivery depends on implementation creating understanding, understanding improving the next decision, and that decision redirecting the work. Take the human out of the middle and the agent keeps producing code, but nobody is steering.
If you think humans no longer need to read the code, that is a coherent position, and for low-risk changes automated evidence may be enough. But where behaviour is critical, or architecture and business rules still need human judgement, readability is not something you add after the code works. It belongs in the acceptance criteria.
The agent's job is not only to produce code that runs. It is to produce a change the team can understand well enough to decide what comes next.
As implementation gets cheaper, protecting that loop becomes the expensive part.