One evening my agent told me I had hit my usage limit.
I had a music-video pipeline running in the background at the time: generations, edits, uploads to YouTube, descriptions. So I asked myself the obvious questions. Which clips are live? Which are queued? Which are finished and only need the publish button? Where are their descriptions?
The answers existed. They were on my own disk, spread across logs, scripts and half-finished files. The only thing that could read that state back to me was the model that had just been switched off.
Limits are the loud version of this problem. The quiet version happens every week. A session gets compacted, restarted or updated. Yesterday we built a content plan for twenty clips. Today I say “let’s publish the next one”, and the session replies that it will search the disk to find out how publishing works.
A working tool can’t behave like that.
The rule I took from it
Since September I ask agents for a different deliverable. When an agent explores a problem, the result it hands back is the rails: script one, script two, script three, a map of the steps, and the current state in a file I can open without asking anyone. The published clip comes out of the rails.
Every recipe that worked once became a tool with a status page. Publishing now goes through one gated path. When a session forgets everything overnight, the next one reads the same files and carries on.
What Karpathy calls Software 3.0
In his fireside chat at Sequoia’s AI Ascent, Andrej Karpathy lays out the three eras again. Software 1.0 is code you write. Software 2.0 is weights you train. Software 3.0 is the context window: you program a language model by what you put in front of it. His examples are good ones. An installer becomes a block of text you paste to your agent. An app he built to illustrate restaurant menus turns out to be unnecessary, because an image model can draw the dishes straight onto the photo of the menu.
He also separates vibe coding from agentic engineering. Vibe coding raises the floor: anyone can now build software. Agentic engineering is about keeping the quality bar of professional work while moving much faster with agents.
I agree with most of it. I disagree in three places, and each one comes from running agents every day.
The model as the computer. If the LLM is your runtime, its outage is your outage. The internet drops, a limit gets cut, a subscription lapses, a model version changes its behaviour. With hosting you have alternatives: move to another provider, keep a second region. With a model as the runtime, you have none at the moment it fails, unless you buy a machine that can run open models locally or operate your own cloud. For one-off work that risk is acceptable. For anything that repeats, it isn’t.
Which gives a simple test. If a piece of work will be done twice, the second run should not need the model. The demos that say “Claude Code can edit video now” show the first run. A weekly publishing schedule is the second run, fifty times a year.
Deployment as the hard part. Karpathy says the worst part of building that menu app was deploying it: wiring services together, settings pages, DNS. I believe him, and I read it as the strongest argument for engineers. On Cloudflare, with a prepared structure, that job takes us about twenty minutes. The difference is the rails someone built beforehand.
The car wash. His favourite puzzle: the car wash is fifty metres away, should I drive or walk? Frontier models say walk. The question leaves out the one fact that matters, that the car has to be at the car wash. A person fills that in without noticing. The model has nowhere to take it from. I read this as an incomplete specification, and it leads straight to Karpathy’s own conclusion: humans own the spec and the oversight.
Where this takes a business
Domain owners will vibe-code. Risk analysts and managers will build their own reports, documents and small tools with an agent. That shrinks the classic application programmer’s job, the one that starts with “here is my idea, build it for me”. It is shrinking already.
The people who come to engineers will bring something that works. “I built this report, publish it.” “Run it every month.” “Add these two columns.”
The engineering work that remains sits around the analyst:
- Access to data. Read-only MCP servers over the warehouse, identity from single sign-on, row and column permissions taken from the user’s role, every query logged.
- Publishing with provenance. Who built the report, when, on which version of the data, with which queries.
- Repetition without the model. The model helps while the analyst explores and while the recipe gets written: datasets, filters, period, columns, charts. Scheduled runs re-execute the stored queries and re-render the report. No number passes through the model. If the model writes commentary, every figure it cites has to match the result set, or the report doesn’t go out.
If the model provider is down tonight, tomorrow morning’s reports still arrive. Only the sandbox for new exploration waits.
Understanding stays with you
Near the end of the talk Karpathy quotes a line he keeps coming back to: you can outsource your thinking, but you can’t outsource your understanding.
For engineers I would add one practical consequence. Let the model do the work the first time. Make sure it can happen again without the model in the room.
Which part of your team’s work runs only because a model remembers how?
Talk: Andrej Karpathy, “From Vibe Coding to Agentic Engineering”, Sequoia AI Ascent 2026.
Also published on LinkedIn.