Andrej Karpathy introduced the term “agentic engineering” at Sequoia Ascent 2026, drawing a line between two practices the broader conversation had been treating as the same thing. His summary of the talk is worth reading in full. The core distinction: vibe coding raises the floor — it makes AI-assisted development accessible and fast. Agentic engineering raises the ceiling — it is the professional discipline of coordinating AI agents while maintaining correctness, security, and maintainability over time.
For enterprise teams selecting AI models, that distinction reframes which capabilities actually matter for production use.
quadrantChart title Enterprise AI Task Allocation x-axis Low Process Complexity --> High Process Complexity y-axis Low Organizational Risk --> High Organizational Risk quadrant-1 Agentic engineering required quadrant-2 Supervised automation with human review quadrant-3 Automate freely quadrant-4 Evaluate carefully first Document drafting: [0.38, 0.28] Contract redlining: [0.72, 0.85] Data entry processing: [0.28, 0.18] Financial reconciliation: [0.65, 0.72] Code diff review: [0.78, 0.52] Escalation routing: [0.48, 0.62]
Vibe Coding Is a Floor, Not a Ceiling
Vibe coding is not going away — and it should not. For prototypes, internal tools, and low-stakes workflows, the ability to describe what you want and generate a working implementation quickly is genuinely useful. The issue is when organizations treat vibe coding as the production capability and scale from there without the discipline that makes AI-generated code reliable in production systems.
Karpathy’s framing clarifies what gets lost: spec design, diff review, eval loop construction, security oversight, and quality judgment. These are not the same as prompting for an output. They require understanding what the system is supposed to do well enough to catch it when it drifts — and the ability to build feedback mechanisms that surface drift before it becomes a production problem.
Most enterprise organizations have developers who can prompt. Fewer have developers who can design agentic systems reliable enough to run in production without constant human intervention.
What This Changes About Model Selection
The shift to agentic engineering changes the evaluation criteria for AI models in a specific way.
Single-turn output quality — the typical benchmark — measures something real but incomplete. A model that produces excellent code in response to a single prompt may behave inconsistently when that prompt is one of twenty steps in an agentic pipeline, where context has accumulated errors, where previous tool calls have returned partial results, and where the instruction needs to be followed despite noise in the surrounding context.
The criteria that matter for agentic enterprise use weight differently. How does the model perform across long contexts without degrading? Does it follow constraints reliably as the conversation extends, or does it drift? Can it use tools consistently within a prescribed structure? Does it signal uncertainty rather than producing a confident wrong answer?
I ran into a version of this framing early in my career at Ceridian, building a prepaid debit card financial management system from scratch. The team faced a choice between storing financial data in CSV files — familiar, fast to implement — and relational data models, which required more upfront discipline. The argument for CSV was velocity. The argument for the relational approach was that the architecture would compound over time while the CSV approach would accumulate fragility as the system scaled. We went with the relational model, and it defined the platform’s long-term reliability.
The same argument applies to model selection in agentic systems. The model that produces impressive single-turn outputs may not be the one that maintains consistent behavior across a fifty-step pipeline with accumulated context and error recovery requirements. Choosing based on demo quality rather than systemic reliability is the 2026 equivalent of choosing CSV files because they are faster to set up.
What Enterprise Teams Should Actually Evaluate
The practical implication for enterprise leaders selecting AI models for agentic workflows is a change in evaluation method.
Single-turn benchmarks matter, but they should not be the primary criterion. Run the model in the actual multi-step workflow it will be asked to perform. Observe how it behaves when context accumulates, when tool calls return partial results, and when instructions conflict with earlier context. Evaluate whether it flags uncertainty or produces confident output regardless of its actual confidence level.
Build evaluation loops before deployment. Karpathy’s agentic engineering framework is explicit about this: without verifiable feedback mechanisms, you do not know whether the agent is doing what you think it is doing. An agentic system without evals is one you cannot trust at scale, regardless of which model runs underneath it.
Evaluate your team’s capability alongside the model’s. The limiting factor in most enterprise AI deployments in 2026 is not model capability — it is the organizational capability to design, supervise, and maintain agentic systems. That capability is a professional skill, and it needs to be developed deliberately, not assumed to be present because the organization uses AI tools.
The organizations that get the most out of enterprise AI models in the next two years will not be the ones with the most powerful models. They will be the ones that built the supervision discipline to use them reliably.
