In my article on where AI can help with quality engineering, I wrote about planning, testing, review, and the parts of software delivery where faster feedback can improve the result.
Since then, I have been thinking about the other side of that argument. AI can make implementation much faster, but the more I work with coding agents, the more I find that engineering discipline matters.
The structure of a codebase shapes what an agent can understand from it. Clear patterns and boundaries reduce the amount it has to infer or guess. When it does have to guess, those assumptions can turn into code very quickly.
Agents will fill the gaps
It is common to pick up a ticket and find something nobody has decided yet.
Maybe the design covers the happy path but says nothing about a partial failure. Maybe the API contract leaves room for interpretation. Or the change crosses a boundary that looks arbitrary in the code but exists for a reason that is no longer obvious.
In a large codebase, the ticket only tells you so much. You might need to dig through an old discussion, ask product what the expected behaviour should be, or talk to someone who remembers why a particular choice was made. Sometimes finding that missing context is the engineering work.
Coding agents often handle that differently. When a requirement has two plausible interpretations, an agent will often choose one and keep going. The choice may be perfectly reasonable given what it can see, even when the missing context is the part that matters most.
Engineering still happens before implementation
I have found planning with agents useful. Before implementation starts, I want the agent to show me where the task is still unclear. What assumptions is it making? Which behaviours are underspecified? Are there decisions that could materially change the solution?
Sometimes a short conversation is enough. Larger changes may benefit from a more structured approach such as spec-driven development.
Planning surfaces decisions that might otherwise be made implicitly during implementation. From there, someone still needs to decide the correct behaviour, weigh the trade-offs, and understand which constraints are intentional.
AI speeds up development, and that can make it easier to skip some of the decision-making because plausible assumptions can quickly turn into code.
More documentation is not always more context
That kind of planning can also produce useful artefacts before implementation starts. Specs and implementation plans make important decisions easier to review and communicate with stakeholders.
The concern is what happens over time. LLMs make it cheap to produce specs, architecture notes, and instructions for future agents, but keeping them accurate is much harder. Code changes, designs evolve, and behaviour shifts.
If the documentation does not change with the implementation, it can keep describing an older version of the system while still looking authoritative. That creates another source of truth, and stale documentation can be especially confusing for coding agents because it is still usable context.
Prose is also difficult to validate against the implementation as the system changes. A document can say that copied records must stay independent, or that a dependency boundary must be preserved, but nothing fails when those rules are broken.
The reasoning may still be worth documenting. If something needs to remain true, though, prose alone is a weak place to keep it.
Make the decisions executable
Humans build up context over time through reviews, incidents, conversations, and experience with the codebase. An agent starts without that history, so it has to rely on the task, the context we give it, and what it can work out from the repository.
That makes the context in the codebase important. When a constraint matters enough to shape the implementation, I want to see whether the codebase can carry it directly.
A behaviour that must not regress can become a test. Types or validation can rule out invalid states. Linting or dependency rules can make architectural boundaries enforceable. These ordinary engineering practices give an agent immediate feedback when it gets something wrong, rather than relying on it to find and correctly interpret a Markdown file at the right moment.
Product reasoning, trade-offs, and historical context still need prose. Documentation is most useful when it captures what the code cannot, instead of becoming a second implementation of the system in English.
Faster implementation raises the stakes
I do not think coding agents require us to rethink software engineering from scratch. Faster implementation puts more pressure on the decisions around it: what gets clarified up front, what still needs human judgment, what is worth documenting, and what the codebase should enforce.
Good AI-assisted development comes from making the right context available where it matters, so fewer important decisions are left to guesswork.