It's only been about a year and a half since Andrej Karpathy coined the term "vibe coding":
What has materialized in the last year has been nothing short of remarkable. Entire applications, websites, and even video games are being fully developed in single Claude Code sessions. What was once (poorly) coined "vibe coding" has grown up, and taken on a more grandiose name to match: agentic engineering.
The shape of agentic engineering is a bit different from vibe coding as well: whereas vibe coding, at the time of Andrej's tweet, was akin to a founder riffing with his first engineering hire, agentic engineering looks a bit more like running an entire company. In fact, many now describe their work as building, orchestrating, and managing "software factories." (Entire companies exist for this purpose!)
But agentic engineering, as with its predecessor vibe coding, has not been adopted equally among the class formerly known as software engineers. Many refuse to use AI entirely, many haven't written a line of code in a year, and the majority likely fall somewhere in the middle.
The adoption of agentic engineering is therefore a spectrum, which I hope to document a bit in this post. If not a spectrum, then a "process" that an engineer goes through as their role shifts from writing code to directing it. For some, it's a reluctant process, as most of us engineers chose the profession to be hands-on, write code, and think of novel or efficient solutions.
Self-driving cars
A helpful parallel is the SAE Levels of Driving Automation — a taxonomy published by SAE International that grades cars from Level 0 (you do all the driving) to Level 5 (no steering wheel required).
| Steering and speed | Monitors the road | Fallback when automation fails | System in control | ||
|---|---|---|---|---|---|
| The human monitors the road | |||||
| 0 | No Automation1885–1999 · Eyes on, hands on | Human | Human | Human | Never |
| 1 | Driver Assistance2000–2009 · Eyes on, hands on | Human + system | Human | Human | Some driving modes |
| 2 | Partial Automation2000–today · Temporarily hands off | System | Human | Human | Some driving modes |
| The system monitors the road | |||||
| 3 | Conditional AutomationCurrent stage · Temporarily hands off | System | System | Human | Some driving modes |
| 4 | High AutomationEst. by 2025 · Eyes off, hands off | System | System | System | Some driving modes |
| 5 | Full AutomationEst. by 2050 · Eyes off, hands off | System | System | System | Always |
I’m not the first to make the comparison (h/t to Dash0), but most of those frameworks describe organizations. I’m more interested in the driver rather than the system.
Self-driving coders
And what the SAE provides for cars nicely maps to our human software engineers. Perhaps I'm trying to force the parallel, but we can split engineers into 6 levels as well:
| Writes the code | Watches each change | Catches mistakes | Agent works unattended | ||
|---|---|---|---|---|---|
| You see every change | |||||
| 0 | Hands on keyboardNo AI, or AI as a search engine | You | You | You | Never |
| 1 | AutocompleteCursor-style tab completion | You + AI | You | You | Never |
| 2 | Chat and approveAsk for code, approve every line | AI | You | You | Never |
| 3 | Agent in the loopWatch, approve diffs, steer | AI | You | You | Between approvals |
| You see the result | |||||
| 4 | DelegationHand off tasks, review the PR | AI | AI | You | Whole tasks |
| 5 | The factoryMany agents in parallel | AI | AI | AI | Always |
A bit more vocabulary for each, to be thorough.
Level 0: Hands on keyboard
What it is: You write all of the code. You are responsible for planning, authoring the code, ensuring it is robust, and matching it to the rest of the codebase. Imagine that!
Adoption: Up until ~2022, essentially everyone was at this point. Some still are. I would find it remarkable and inefficient to never use AI to speed up the act of creating software, but some, usually due to political or environmental objections, have done so!
Level 1: Autocomplete
What it is: Here, the act of writing software typically looks like your standard act of pre-AI programming: navigating around from file-to-file, writing application code, etc. — but a model will preemptively suggest what it thinks you are going to write. Copilot was the first mover in this space but has since been dethroned by Cursor Tab.
Adoption: Some are still stuck here. From my conversations with friends that work in large enterprises, sometimes Microsoft is their company's corporate partner and so Copilot is the extent of the AI in their workflow.
Level 2: Chat and approve
What it is: This can be thought of as the Cursor sidebar, or the result of claude in the terminal, depending on your flavor. This practically looks like asking for some change, refactor, or new feature, and having an agent show you each change it is going to make, with you accepting (either via UI or the Enter key) or rejecting. (An earlier version of this involved asking ChatGPT or Claude in a chat thread for some boilerplate code, and pasting it into your codebase. Those days are long gone though!)
Adoption: Probably the largest group of engineers today, in part because it's the default. Also because many are unaware of the possibility of full delegation, or are intimidated by it.
Level 3: Agent in the loop
What it is: The agent stops asking permission for each edit. You toggle "Accept All Changes" and let your agent read files, make changes, and run commands on its own, while you sit in the session and watch. You may have your own dev server running, watch the changes in real time, and click around the app as usual after every agent-driven change.
Adoption: Alongside Level 2, this is where most engineers I know sit. The jump from 2 to 3 is mostly a matter of trust (after you've accepted enough changes, you realize these models are pretty dang trustable!).
Level 4: Delegation
What it is: You hand off a whole task and come back to a finished result. You might assign some issue to a Cloud agent or kick off a long-running session in another terminal and moving on to something else. Rather than watching the agent, you review what it produced. If the work is visual in nature, you can either visually verify its changes yourself, or you can ask the agent for screenshots.
Adoption: Growing quickly, especially at startups and among engineers who already lived in Level 3. The bottleneck here is review: you can hand off tasks much faster than you can read the PRs that come back.
Level 5: The factory
What it is: Many agents run in parallel, and you no longer review most of what they produce. Instead, you design the system that produces software: the specs agents work from, the tests and review agents that catch their mistakes, and the pipeline that decides what ships. Contrasted with Level 4, you no longer even ask for screenshots; you have designed the system by which agents can review one another's work (e.g. pixel diffs) and the standards (e.g. acceptable pixel diff amount) for the factory to operate without your direct oversight.
Adoption: This is a small frontier, and one that is probably overstated depending on your information digest. (The folks that do this are loudest on Twitter.)
Put together, the spectrum comprises all engineers. The distribution in my read (subject to change rapidly, as all things in AI do) looks a lot like a bell curve:
| Level | Share |
|---|---|
| 0: Hands on keyboard | 5% |
| 1: Autocomplete | 15% |
| 2: Chat and approve | 30% |
| 3: Agent in the loop | 30% |
| 4: Delegation | 15% |
| 5: The factory | 5% |
Where should you live?
Should an engineer be actively in every loop, reviewing every line of code? Or should an engineer be merely an operator at this point, doing no more supervision than is necessary when the factory fails?
The answer depends on two questions. First, how much of the work is still undecided? If the architecture or the feel of the thing hasn’t been settled, it's the job of an engineer to settle it. Second, can a machine tell when it’s right? If automated tests or a pixel diff cannot verify the result, a human needs to be in the loop to verify outputs.
That answers the question in the immediate sense, but in the long term what it suggests is a recasting of an engineer's job description. An engineer's role in the future will be to resolve both of these questions: to make decisions that resolve ambiguity in work, and create systems that allow agents to verify their own work moving forward.
What's left to do if everything hits Level 5?
Then there is an interesting, if somewhat existential, question: what is an engineer to do if all code becomes produced by software factories?
Generate more code
Already we are beginning to see how the decreasing cost of code generation is enabling an explosion of new apps, websites, and games. People are decompiling Halo to C++ and then recompiling it to run in a web browser. Can you imagine the cost (in terms of time, effort, and expense) of doing so before AI?
Velocity enables volume. What we have been able to do at my design studio, specifically with regards to internal products, is a good example: shipping more and more to make all parts of our agency run smoother. One should expect that if software becomes factory-developed, the next question should be: what else can the factory build?
Decide what’s worth building
If the above option is to produce more, the other option is to build less. That is, to be surgical and decisive about what's worth building. This has always been the role of engineers (specifically engineering leadership), but its importance is arguably greater as code gets cheaper: a factory will happily produce whatever you point it at, including the wrong thing, at scale.
Be the human in the loop
And no matter how well a factory runs, I still think there needs to be competent humans in the fold. This may be for some on-call emergency that an agent in the factory hasn't encountered, or some attack on the agent architecture itself! To be fair, the number of competent engineers needed necessarily drops in this future, but I don't think it drops to zero.
Do it for the love of the game
And finally, there will be those who revert to level 0. Despite machinery making mass production possible, handcraftedness remains something we treasure. Some folks will drive cars for fun despite mass availability of self-driving technology. Many engineers will be no different.