The Evolution From Software Engineering to Agentic Engineering
Redefining the Software Engineering Profession for AI
Anyone who has been actively following AI space developments for a while, doing so very closely and in a practical way, will recognize the situation described here.
Just in recent days, we went from strong releases of open-weight models (Kimi K3, Alibaba's Qwen3.8-Max, Nvidia Alpamayo 2 Super), closed source models (SpaceXAI's Grok 4.5, Anthropic's Claude Opus 5), a coalition in support of open-source models, the deliberately requests to pace the frontier of automated AI development led by Anthropic, incident reports of AI systems going rogue (e.g., HuggingFace, UK AI Security Institute, OpenAI, Meta) to OpenAI’s Ten advances in mathematics and theoretical computer science. However, these are only the “catchy” headlines; much more is happening, and most people can’t even fathom following what’s going on in the AI space right now.
In different conversations I’m having with tech and non-tech companies of all sizes, both national and international, it is hard not to notice how messy the current environment is. Many companies are completely lost about their AI initiatives, plans, applications, hiring processes from start to finish, day-to-day use, governance, and security. Much of the problem comes down to a lack of knowledge and understanding. As it is quite challenging to follow and process all that is going on, they all need people who can guide them in this journey.
My goals here are two-fold: (a) help shed light on some basic level-set terminology that is permeating conversations and that most people use as synonymous, even though they are not, and (b) pose a reflection on what actually is changing, why this matters, and the importance of education. Worth noting that these are not final definitions for this new era. They will change as the practice continues to change.
Origins of the terminology
Back in the "old days", in February 2025, the vibe coding era began. The pitch: describe what you want in plain language, let an AI model generate the implementation, and worry less about the code underneath. A year later, Karpathy was already retiring the term. He argued that vibe coding described something real but incomplete: a mode that worked for prototypes and throwaway projects, but not a discipline on which anyone could build production software. In its place, he proposed “agentic engineering”, a more structured practice in which AI agents are directed by a human who remains accountable for the specification, architecture, and quality.
The fact that a widely accepted term needed to be replaced within twelve months is worth noticing. As I wrote above, very few people are following these changes closely enough to notice. The vocabulary matters because it affects how organizations assign responsibilities, train engineers, and decide what “done” means.
My argument is this: the interesting change in software engineering right now is not that AI can write code. That has been true, to varying degrees, for several years. The change is that the profession is reorganizing around a different core skill: orchestrating and validating systems whose components you did not personally author. This reorganization is happening faster than companies, training programs, hiring pipelines, and accountability structures are adapting to it.
A spectrum, not a switch
It helps to stop thinking of “AI coding” as one thing. In practice, it spans a spectrum of agency (Figure 1), and most engineering organizations today operate somewhere across all of it at once, often without saying so explicitly.
At one end of the spectrum is traditional computer science software engineering, the model most people have studied. A developer writes and reasons about every line. It is based on the practice of writing explicit instructions for computers, which computer science has taught since its establishment.
That era has a few familiar properties. Given the same input twice, you expect the same output twice. Engineers manually define edge cases, permissions, retries, validation, and execution paths. Each step is predefined and follows a rigid control flow. The developer’s job is to write behavior by explicitly defining workflows, rules, and implementation details. AI might offer assistance through something like IDE autocomplete, but the human remains in control of the architecture and decisions. When traditional software fails, the failure is usually predictable and traceable to a faulty condition, implementation detail, or state transition. At this end of the spectrum, the human has maximum agency and programs behavior directly instead of orchestrating intelligence.
Moving along the spectrum, there is AI-assisted coding: autocomplete, targeted code generation, and an assistant answering questions inside an editor. This has been mainstream for a few years and mostly feels like a faster version of familiar work. The developer still authors and understands the code, with less typing.
Vibe coding sits further along. The developer states an intent and accepts a much larger share of AI-generated output with relatively little line-by-line review. It is useful for prototypes, internal tools, and situations where the cost of being wrong is low. On its own, though, it is a poor foundation for software that has to keep working under real usage, real load, and real adversaries. Nobody is verifying what is actually being shipped.
Then comes agentic coding. Here, the system has a high level of delegation. It can plan tasks and iterate toward a goal, use tools, write and execute code, and debug failures. Unlike the earlier stages of the spectrum, agentic coding operates with limited human supervision. Teams often move into it after starting with vibe coding, where they describe intent in natural language, as the complexity and stakes of a project increase.
At the far end is agentic engineering. One or more AI agents plan, write, test, and revise code with some (or total) autonomy, often in parallel across different parts of a system. A human sets the specification, defines the guardrails, and reviews the output before it ships.
The defining difference between agentic coding and agentic engineering is not how much code the AI produces. It is the disciplined human process around that production: a real specification instead of a loose prompt, a review step that catches problems, and an explicit owner who is accountable when something goes wrong. Human software engineers still design the environments in which these autonomous systems operate, reason, and adapt.
Most public conversations about “AI replacing programmers” ignore this spectrum and argue about the two extremes, full manual coding and full autonomy, as if organizations have to choose one. They do not, and mostly have not. The more consequential question is where a given team, project, or engineer should sit on the spectrum for a given task, and who decides.
The role that’s actually changing
The developer’s job is shifting from writing every line to orchestrating and validating a system whose individual components may be written, tested, or even architected in part by an agent. That is a real change, but it is worth being precise about what kind of change it is. Engineering skill does not become unnecessary. Its point of application moves both upstream and downstream of the code itself: toward specification, system design, and judgment about tradeoffs, then toward review, evaluation, and accountability once code exists.
In practice, this looks less like traditional programming and more like engineering management or technical leadership, except that the team can include non-human agents alongside human collaborators. That changes what a career in software engineering trains you to do well. The traditional path for a junior engineer was to write small, well-scoped tasks under supervision, build intuition for how systems fail, and gradually take on more architectural responsibility. It assumed that writing a large volume of code yourself was how you developed the judgment to review it later.
If agents take over a substantial share of that code-writing, the profession needs a real answer for how the next generation of engineers will build the same judgment without the same apprenticeship. I do not think anyone has that answer yet, and it deserves more attention than it is getting.
Many public-facing people in the industry are not very hands-on, so they have not felt these effects firsthand. They miss that LLMs used in engineering practices across the spectrum above make critical design choices. Those choices have real implications if teams do not carefully review, guide, and consider them. These studies illustrate the point: “A Study of LLM’s Preferences for Libraries and Programming Languages”, ACL 2026; “What Claude Code Actually Chooses” research benchmark by Amplifying.ai.
Why this matters beyond engineering teams
For technology leaders and policymakers, the consequential question is not whether agents can write good code. Under the right conditions, they clearly can. The question is who is responsible when they fail, and whether organizations have established the structures to ensure that accountability is genuine rather than merely symbolic.
“A human reviewed it” is meaningful oversight only when the review process has enough rigor, time, and authority to catch problems. Otherwise, it becomes a rubber stamp on output that is difficult to evaluate fully at the speed it is produced. There is a real risk that oversight becomes theatrical: a human is nominally in the loop and formally accountable, but structurally unable to review the volume and speed that agentic systems generate. That is the direct failure mode of asking a review process to keep pace with a much faster production process without a proportional increase in review capacity or tooling. Any organization adopting agentic workflows at scale should ask whether its review and evaluation processes can keep pace with its generation processes, not simply whether it has adopted the tools.
There is also an access dimension worth naming. Lowering the barrier to building software has real democratizing value. More people, in more places, with less formal training can turn an idea into working software. That benefit should not be dismissed as naive. But democratized creation and professional-grade engineering are different achievements with different requirements. The risk concentrates in the gap between software that appears to work and software that has actually been engineered to hold up under real conditions, adversarial or otherwise.
A reasonable doubt worth stating directly
It is fair to ask whether “agentic engineering” is a substantive discipline or simply the next label in a fast-moving hype cycle. Vibe coding lasted roughly a year before its own coiner moved past it, which is not obviously the pace of a mature engineering discipline settling into place.
I think there is a real distinction underneath the branding, but the terminology is unstable and is being defined in public, in real time, by people with a stake in the tools succeeding. The underlying shift, more software production moving toward AI agents and more of the human role moving toward specification and review, looks durable because it follows directly from what these models are and are not reliably good at. Whether “agentic engineering” is the term that survives or gets replaced again within another year matters less than whether the profession builds the review discipline, training pipelines, and accountability structures that the shift requires.
Where this leaves the profession
The honest version of this argument is not that software engineering is being automated. The profession’s center of gravity is moving from writing code to being responsible for code you did not personally write. That changes what expertise looks like, how junior engineers are supposed to develop it, and who is answerable when a system fails. I recommend reading Mark and Scoot’s perspective on “Redefining the Software Engineering Profession for AI”, Communications of the ACM (Feb, 2026), on how they are thinking about it inside Microsoft.
At this moment, there is a real split and polarization in the field/community (Computer Science) right now that resembles what Linux distributions used to be: either you love it or hate it, and this is the situation with AI in coding right now. To prove the point here, just read Linus Torvald’s recent email to the Linux Kernel Mailing List on his updated stance for the Linux kernel.
“AI is a tool, just like other tools we use. And it’s clearly a useful one.”
— Linus Torvald, July 2026.
One thing is safe to say: as a community, we’re not going back to an era where everyone hand-writes every line of code. The times sure have changed. However, in my opinion, the new technology cannot replace education + experience. Education remains deeply important for everyone. Unfortunately, with all the corporate speak out there in the media, we are starting to see the opposite starting to happen, e.g., CS enrollment is reportedly dropping (source study by Hoover Institution, Stanford University) in places now, and I’m not sure what the future of technical education and learning looks like in a few years. But remember, we already know how learning happens. If you don't remember the basics of how learning happens for humans, here’s a short (5min 22s, watch from 41:15 to 46:28) research-backed neuroscience explanation.
The tools will keep improving, probably faster than most predictions account for. The open question is whether the structures around them, including training, review, evaluation, and accountability, improve at anything close to the same rate, or whether we end up with a generation of engineers fluent in orchestration but thin on the judgment that orchestration is supposed to require.
If you found this useful, please cite this op-ed as:
Müller, Lucas. (Aug 2026). The Evolution From Software Engineering to Agentic Engineering. lucasmuller.com. https://notes.lucasmuller.com/p/the-evolution-from-software-engineering
or
@article{lucasmuller2026default,
title = {The Evolution From Software Engineering to Agentic Engineering},
author = {Müller, Lucas},
journal = {lucasmuller.com},
year = {2026},
month = {Aug},
url = {https://notes.lucasmuller.com/p/the-evolution-from-software-engineering}
}