The shift from software to agentic engineering
Software Engineering required an elaborate scaffolding of rituals, teams, and institutional memory. Agentic Engineering promises to replace much of this machinery, but the reality is more complicated!
Software Engineering required an elaborate scaffolding of rituals, teams, and institutional memory. You gathered engineers familiar with your stack, surrounded them with domain experts, wrapped everything in QA and ops, and created feedback loops through code reviews, daily standups, and sprint planning. You paired junior developers with seniors, rotated activities to avoid single points of failure, and hired scrum masters to groom backlogs. Retention plans mattered because losing a person meant losing project knowledge. None of this was accidental. Software Engineering was difficult, and the entire discipline evolved to manage that complexity.
Agentic Engineering promises to replace much of this machinery. In this model, human developers act as orchestrators, directing autonomous AI agents to plan, write, test, and deploy code rather than writing it themselves. The appeal is obvious. But anyone who has spent time working with agents knows the reality is more complicated than simply prompting an LLM and watching code materialise.
The vibe-coding era is over
Early experimentation with code-generation models created a false impression: that the hard part of software development was syntax and framework knowledge. It wasn’t. The hard part has always been architecture, coordination, and maintaining context across time. Agents excel at syntax but struggle badly with the rest.
For syntax and frameworks, agents outperform most senior engineers. They have absorbed vast amounts of documentation, example code, and best practices. The stack knowledge problem that once required careful hiring and training has effectively disappeared. But this creates a new problem: engineers who assume syntax was the bottleneck underestimate what remains.
Agents are poor architects. They cannot see the big picture. They write code that works locally but fails to account for system-wide constraints, future maintainability, or the subtle interdependencies that experienced engineers learn to anticipate. They have no persistent memory. The stateless nature of LLMs means they cannot reliably recall what they did in previous steps, let alone previous sessions. And whilst they write code quickly, they test it poorly, particularly when manual verification is required.
Context is the new bottleneck
If you are moving towards Agentic Engineering, invest heavily in context management. Every LLM has a limited context window, and on large projects this constraint becomes acute. The most common failure mode is losing long-term context between chat sessions. An agent that performed brilliantly on Monday has no recollection of its decisions on Tuesday.
This forces a structural change in how teams work. Requirements must be specified in a way that multiple agents can execute independently and produce consistent results. Documentation and specifications become more important than the code itself—they are the only mechanism for preserving intent across sessions and agents. This is a significant shift because most engineers are not particularly good at specifications. If you needed one reason why bugs exist, poor specification would be it.
Teams need tools that help agents find relevant context. Semantic search across code and documentation—tools like CK or SuperMemory—become essential infrastructure. Without them, agents repeatedly make the same mistakes, forget established patterns, and produce inconsistent output.
Orchestration is a skill
The final bottleneck is human. Most engineers are not orchestrators. They may become technical leads after years of experience, learning to coordinate other people, but orchestrating a fleet of agents is different. Humans have common sense. Agents have speed. Humans can infer intent from incomplete instructions. Agents execute exactly what they are given, including your mistakes.
The discipline is shifting: writing code becomes specifying what code should do, managing people becomes managing context, debugging syntax becomes debugging orchestration. The engineers who thrive in this new era will be those who can write precise specifications, maintain institutional memory in machine-readable form, and understand both the capabilities and the hard limits of autonomous systems.
Agentic Engineering is not easier than Software Engineering. It concentrates the difficulty into fewer, more consequential decisions.