Deciding the shape of a system, what the parts are, what each one owns, and how they talk to each other, used to be the job of systems engineers and architects. Most developers worked inside those parts. That is where the hours went, and where most of us learned the craft.
Coding agents have taken over much of that inside work. That does not make systems thinking a nice next step on the career ladder. It makes it the baseline. A developer who cannot design structure is now a developer handing an agent a task it cannot do well.
Agents are the new subcontractors
Systems engineering grew out of a specific problem: the people who designed a system were not the people who built its pieces. Subsystems went to other teams or other companies, so the engineer’s job was to specify each piece well enough that someone else could build it, and then to verify that the pieces fit.
That is now the everyday situation with coding agents. Give an agent a well-scoped component with a clear interface and clear rules, and it will build it. Give it a vague task in a codebase with no clear structure, and it will reach across layers, duplicate rules that already live elsewhere, and wire in whatever dependency is closest. The tests pass and the system gets worse.
The agent is not the problem. It works within the structure it is handed. If nobody designed that structure, there is nothing for it to respect.
The box is not the system
An agent can make every component correct and the system can still fail. Retry storms, inconsistent data, latency that compounds across calls, security that no single module owns: these live between the parts, not inside them. That gap is exactly what systems engineering exists to manage, and it is the part of the work that does not get cheaper when code does.
Structure also used to form on its own. Conway’s law says a system mirrors the communication structure of the team that builds it, so boundaries emerged from who talked to whom. When agents write most of the code, that force weakens. The structure has to be designed on purpose, or it will not exist.
The new baseline
So what used to be a specialist role is now the core of the job. Every developer working with agents needs to do what systems engineers have always done:
- Allocate responsibility. Every rule has exactly one owner.
- Treat interfaces as contracts. Write them down, version them, test against them.
- Record the tradeoffs. Why the boundary is here and not there.
- Verify the whole, not just the parts. Plan for integration, not only unit correctness.
This raises a real question: the judgment to draw good boundaries used to come from years of working inside them. If agents do that work, developers will have to build that judgment some other way, and earlier in their careers than before. I do not have a full answer. But this is no longer optional. Writing the code inside the box is becoming the agent’s job. Designing the box is what is left for us, and it is the part that decides whether the system works.
At least until three months from now, when the agents start doing that better than we do too. Then I will write the next post.