Karpathy at Sequoia Ascent 2026: Agentic Engineering vs Vibe Coding
At Sequoia Ascent 2026, Andrej Karpathy delivered a fireside chat that crystallized several frameworks for thinking about the current wave of AI agents — frameworks that are already reshaping how engineering teams are structured and what software gets built. The talk has circulated widely, and the blog post summary Karpathy published is worth working through carefully.
The central claim is that we are entering Software 3.0 — a third era following Software 1.0 (explicit code) and Software 2.0 (learned neural weights). In Software 3.0, the primary programming medium is natural language instructions operating inside a context window. The context window becomes the key lever: what you load into it, how you structure it, and what you ask the model to do with it determines the outcome. This is not a metaphor — it is literally how Claude Code, Codex, and Cursor are architected. The prompt is the program.
Karpathy draws a sharp distinction between vibe coding and agentic engineering. Vibe coding democratizes creation: anyone can describe a goal and have a model produce working software. Agentic engineering maintains quality standards. Professional teams must write specifications before the agent starts, supervise implementation plans, review outputs, and maintain security boundaries — treating agents as powerful but fallible interns rather than autonomous co-engineers. The risk of vibe coding at scale is gradual codebase degradation: agents optimize for completing the described task, not for maintaining architectural coherence or long-term maintainability. The MenuGen example he uses makes this concrete — a multimodal model can overlay dish images on menus directly, making the scaffolding app that would previously have been built to do the same thing unnecessary. Entire categories of glue code and integration software simply stop needing to exist.
The infrastructure implication that deserves attention from platform teams: existing products and internal tools need to be redesigned for agent consumption. CLIs, machine-readable APIs, structured logs, auditable action trails — these are no longer nice-to-haves but prerequisites for an agent-first workflow. Documentation that tells a human "click here" is useless to an agent. Teams building internal developer platforms should be asking: can an agent drive this without human intervention, and if not, why not?
Safe & Secure AI Agent Practices
AWS Four Security Principles for Agentic AI Systems
AWS published a prescriptive security guide authored by Mark Ryland, Riggs Goodman III, and Todd MacDermid, laying out four foundational principles for teams deploying agentic AI in production. The guide is notable for its practical orientation — it avoids abstract threat taxonomy and instead maps directly to architecture decisions teams face when moving from proof-of-concept to production agentic systems.
Principle 1 — Apply the Secure Development Lifecycle across all components. Traditional SDL practices (code review, dependency scanning, threat modeling) must extend to AI components: foundation model selection, prompt engineering, and tool definitions. For the AI-specific layer, the guide calls for behavioral assessments and adversarial evaluations in addition to functional testing, because AI components can fail in ways that traditional testing won't surface — unexpected generalization, prompt injection paths, and edge-case behavior under distribution shift.
Principle 2 — Traditional security controls remain fully applicable. Agentic AI doesn't create a new security domain; it intensifies existing ones. Privilege escalation, code injection, and supply chain vulnerabilities are all present and operate at machine speed. The guide's message is that teams should not treat AI security as a replacement for existing controls — it is additive. A prompt injection guard is not a substitute for proper IAM scoping.
Principle 3 — Enforce security through deterministic external controls. The core architectural guidance: do not rely on the model's internal reasoning to enforce security constraints. LLMs cannot reliably uphold access control boundaries, permission scopes, or data handling rules on their own — these must be implemented as infrastructure-level controls external to the agent's reasoning loop. Concretely, tool access allowlists, network egress rules, and data boundary enforcement should be implemented in the infrastructure (API gateways, service meshes, IAM policies) that wraps the agent's tool-calling surface, not in the system prompt.
Principle 4 — Earn greater autonomy through ongoing evaluation. Start with human approval for high-consequence operations. Expand autonomy progressively based on documented evidence: track agent recommendations, human decisions, and outcomes systematically to build the evidence base that justifies moving specific operation categories to autonomous execution. This is a process, not a one-time risk assessment. Teams that skip this ramp tend to discover failures in production rather than in evaluation, which is both more costly and harder to diagnose.
