Software Engineering After Agents
A synthesis of the shift from hand-authoring every line of software toward specifying, steering, auditing, and repeatedly rebuilding systems with agentic tools.
The first mistake is treating coding agents as autocomplete with better vibes. The second mistake is treating them as autonomous engineers. The productive frame is stranger: software engineering becomes the design of loops that make partially reliable code generation useful.
When a model can draft a server, migrate a schema, write a component, or explain a codebase in one pass, the scarce skill changes. It is less about personally typing every implementation detail and more about maintaining the structure that lets generated work be evaluated.
The new loop looks like this:
- Start from a known-good template or existing system.
- Give the agent a concrete objective and the relevant local context.
- Ask for a small number of high-level changes.
- Run the code.
- Read the diff.
- Tighten the interface, tests, and prompt.
- Repeat before the system drifts beyond your ability to inspect it.
This does not remove software engineering. It moves more of it into taste, decomposition, review, and operational judgment.
The strongest teams will not be the ones that "use AI" generically. They will be the ones that make every boundary explicit enough for agents to operate against:
- typed data contracts
- narrow modules
- reproducible local commands
- fast tests
- visible logs
- seeded example data
- task descriptions that mention failure modes
- code review standards that assume plausible-looking wrong answers
This is why old work like Teaching Computers to Use Computers still matters. General computer-use agents were always going to make software environments part of the training and work surface. What changed is that the interface became good enough for ordinary engineers to feel the pressure directly.
The practical advice is not "rewrite your codebase every thirty minutes." It is: keep your codebase in a state where a bounded rewrite is cheap enough to consider. If rewriting a subsystem is terrifying, the problem is not the agent. The problem is that the system has no clean surface for change.
Post-agent software engineering is still engineering. It just has a new failure mode: confusing throughput with control.
Neighborhood