I have been doing agentic engineering this whole time. Sort of.
Andrej Karpathy drew a line between vibe coding and agentic engineering. Here is why that distinction matters, where I land, and what it means for the software we build.
Andrej Karpathy gave a talk at Sequoia Ascent 2026 where he said something that stuck with me. Vibe coding raises the floor. Agentic engineering raises the ceiling.
They sound similar. They are not.
The difference
Vibe coding is describing what you want and accepting what comes back. It works for prototypes. It works for personal tools nobody else touches.
Agentic engineering is the discipline of coordinating agents while preserving correctness, taste, and maintainability. You design the spec. You supervise the plan. You inspect the diff. You write the eval. You keep the quality bar where it needs to be.
Karpathy gives a concrete example. He had an agent build a payment flow that matched Stripe purchases to Google accounts using email addresses. The code was plausible. The system design was wrong. Stripe email and Google login email can differ. A human with product judgment would have caught that. The agent did not.
That gap is where agentic engineering lives.
Where I land
I do not accept generated code without reading it. I write specs before pasting prompts into Claude Code. I use planning mode before any multi-file change. I review diffs. I run builds before committing. When something feels off I stop and think before I let Claude keep going.
That is not vibe coding. That is what Karpathy is calling agentic engineering.
The research digest agent I built is the clearest example. The agent does the research. I defined the sources, the output format, the memory structure, the rubric for what a good digest looks like. I decided when to ship and when to rebuild. The agent executed. I directed.
The trust question nobody has answered yet
At what point do we trust AI enough that we no longer need a human in the loop?
Right now the honest answer is: we are not there yet for anything that matters. Most agentic systems in production still have human sign-off built in. Agents are capable. They are not yet accountable on their own.
But the direction is clear. The question for every software platform is not whether to remove the human. It is how to build infrastructure that makes the human's role smaller over time without losing accountability along the way.
From what I observe as a practitioner, the companies getting this right share a few things. Audit trails on every agent action. Structured APIs with explicit schemas. Documentation written for machines, not just humans. Permissioning that tells the agent exactly what it is and is not allowed to do.
Not as features bolted on. As foundational design decisions made before the agent even shows up.
What building on agent-native infrastructure actually feels like
I notice this directly in my own work. The reason the digest agent works is not just because the model is capable. It is because the platforms underneath it are structured enough for an agent to reason about.
Resend has a predictable email API. GitHub Actions has a clear permission model. When I push Field Notes to Contentful, the agent works with typed content fields and a management API. It does not have to guess. It does not have to scrape a UI. It writes to a schema it already understands.
I am seeing more developers ask for exactly this kind of structure upfront. Not just good documentation, but agent-readable documentation. A CLAUDE.md that encodes how to work with a content model, which APIs to call, which fields matter, what the conventions are. Something a new agent session can load and immediately work from.
That is a real shift. When developers start treating agent context files as first-class deliverables alongside READMEs and API docs, the infrastructure conversation has already moved.
What Karpathy gets right (IMHO)
His line about understanding is the one worth keeping. You can outsource your thinking, but you cannot outsource your understanding.
Even when agents do more of the work, you still need to know what is worth building, what result looks wrong, and what tradeoff is acceptable. That judgment does not delegate. It is what separates someone using agents as leverage from someone producing slop at scale.
What is next
Most software is still built for humans clicking through screens. Docs say go to this URL, click this button, open this panel. But increasingly the user acting on those instructions is not the human directly. It is the human's agent.
Products that want to stay relevant need agent-native surfaces. Structured APIs. Machine-readable schemas. Explicit permissioning. Auditable actions. Not as add-ons. As the default.
The developers asking for agent context files today are the early signal. More will follow.