In February 2025, Andrej Karpathy described vibe coding as the practice of describing intent in natural language, accepting an LLM's changes with minimal review, and letting the code grow beyond your usual comprehension. It delivered impressive speed for personal projects and prototypes.
One year later he observed that agent capabilities had advanced, and proposed "agentic engineering" as his preferred name for the evolved practice of orchestrating agents while keeping strong human oversight of architecture and process. The goal, as he framed it, is to claim the leverage of agents without compromising software quality.
The distinction matters. Vibe coding works well for a single user on low-stakes personal work, but it quickly accumulates hidden debt, security gaps, and maintainability problems the moment other people depend on the result. Agentic engineering keeps the speed and leverage of modern agents, but anchors everything in clear structure, traceable artifacts, and human accountability.
The Agentic Engineering Workflow
Start with rough intent and carry on design conversations with the AI while documenting the functionality into design meeting notes describing the functionality into its component parts. Once the design feels solid, capture the high-level view and component map in a design hierarchy (this is what people are showing when they show an obsidian "brain") a navigable structure that gives both you and the agent ready access to surrounding context, related decisions, and dependencies. This is also where design diagrams live, such as UML (universal model language), code or user interaction flows, alongside links to architectural decision records (ADRs) where they clarify how components relate.
For each module or smallest functionality block, create a focused spec.md within the LLD that defines precise behavior, function signatures, edge cases, test expectations, and integration points. Using the whole structure as a design context prompt the AI to build a ticket style hierarchy with direct traceability back to the wiki pages and the specs. Implement ticket by ticket with the agent following the relevant spec.md as its contract. Then you run verification gates, deploy, observe, and update the living artifacts as requirements evolve.
Real Example: Daily Backup Verifier
Consider a small, production-grade CLI tool that verifies daily S3 backups and sends Slack alerts on failure.
Begin with the rough goal: "I need something reliable that checks my backups are healthy every day." Then carry on architectural conversations with the AI to surface requirements and edge cases:
- What are the realistic failure modes for S3 backups in practice?
- What exactly should we verify (age, file count, size, success rate), and what thresholds make sense?
- How should configuration and secrets be handled across local development and production IAM roles?
- What CLI commands and output formats would be useful day to day?
- What non-functional requirements matter most for a scheduled daily tool?
These conversations clarify scope and help decompose the tool into its core components: S3 metadata fetching with retry logic, a verification rules engine, a notification system, a configuration loader, a CLI interface, structured logging, and error handling.
With the design clear, you document the high-level view and component map in the design hierarchy wiki, where every page is versioned and linkable.
The wiki gives future readers the surrounding context that a flat document cannot provide. As part of the same design work, you create a focused spec.md at the sub-LLD level for each module. Here is the contract for the S3 metadata fetcher.
This spec.md is the contract you hand the agent, for example: "Implement exactly per spec.md in the s3_client/ directory, follow project standards, and include comprehensive tests." With the wiki and module specs in place, you then prompt the AI to generate the ticket hierarchy directly from them. Every item traces back to a functional requirement and to the spec that defines its contract.
Implementation then proceeds ticket by ticket, each one handed to the agent with its matching spec.md as the contract. Here is what that produces in practice: a scheduled run catching a short backup set and firing the alert.
The run exits non-zero so the cron job notices, and fires the alert that lands in Slack.
The alert carries the rule context an on-call engineer needs to act: which check failed, what was found, what was expected, and which backup set.
Benefits of This Layered Approach
- Agents handle implementation volume while humans own architecture and quality at every layer.
- The wiki supplies project-level discoverability and decisions, while spec.md files supply precise module-level contracts without bloating the high-level design.
- Requirements and decisions flow directly from wiki pages and specs into tickets and code.
- Changes start from living design artifacts rather than reverse-engineering the codebase.
- Clear separation of concerns supports parallel work, onboarding, and audits.
- T-shaped professionals navigate with breadth and question with precision, and the agent supplies depth on demand without forcing anyone to hold the entire system in their head.
Vibe coding remains an excellent mode for exploration and rapid personal prototyping. Agentic engineering is how you channel that same conversational power into systems that other people can trust and maintain.
The Role of the T-Shaped Professional
This workflow is especially powerful for T-shaped professionals: engineers who maintain broad knowledge across the application space with the capacity for going deep where required.
Because you don't need to hold a complete, up-to-the-minute mental model of how the entire application functions at any moment. The agent can carry that depth and re-explain any part on demand, as long as it has the right context from the wiki, the spec.md files, and the conversation history.
What you do need is the ability to know what to look for and where to look, plus the discipline to keep asking precise questions until you understand the specific item under work. The broad part of the T gives you the map of the system; the AI agent supports the skills required to drill into the exact module, edge case, or integration point that matters right now. The agent supplies the exhaustive detail whenever you ask.
This shifts the human role from "I must understand everything all the time" to "I know how to navigate, question, and validate at the right altitude." That is the real skill of agentic engineering.
