agentic engineering / part 1
The disciplined loop, part 1
Goals, specs, and the work you can't delegate
view: full · tl;dr
Part 1, compressed. The full essay walks all of this slowly, with the stories and the caveats.
Andrej Karpathy asks AI models a trick question: the car wash is 50 meters away, should I drive or walk? They said walk, and they were wrong, because the car is the whole point of the trip. That context lived in your head, and the model can't derive it. Every time an agent builds you something technically correct and completely wrong, this is what happened: you gave it a task and kept the point. This post is a workflow for closing that gap, built on a frame Karpathy laid out in 2026: a spec layer, a verifier layer, and an environment layer.
Why "just prompt better" stopped being the answer
The models write good code now, so the failures moved upstream: the wrong abstraction chosen confidently, features that pass every test and miss the point, work that looks done because nobody defined done. Karpathy's reframe: traditional computers automate what you can specify; these machines automate what you can verify. Your job is two artifacts the model can't produce for itself, a statement of what you actually want and a way to check whether you got it. And the series thesis, a kache line Karpathy popularized: you can outsource your thinking, but you can't outsource your understanding.
The hierarchy: goal, spec, plan
The goal is the why (the car wash, not the driving), one sentence, and it can only come from you. Don't write it; get interviewed for it: tell the agent to ask you three to six questions before building anything. The spec is the what: a file in the repository, not a conversation, holding the goal, non-goals, invariants, key decisions, and numbered acceptance criteria written before any code. The key-decisions list guards against the most expensive failure mode there is: the agent presents every decision it's about to make on your behalf, and you say yes or no before implementation, when a wrong assumption costs a sentence instead of a rewrite. The plan is the how, right now, and it's disposable; anything in it worth keeping gets promoted into the spec. When something goes wrong, the hierarchy routes the failure: a failed test means redo the work; criteria failing wholesale means fix the spec; a satisfied spec that still feels wrong means the goal was wrong. A repo organized this way also makes models interchangeable: the spec defines the job, and whichever model is best this quarter slots in.
The loop
Once per effort: goal, spec, slices. Per slice: the agent plans, builds, and runs the gates; then a fresh agent with no memory of the implementation grades the diff against the criteria; a fresh-eyes review reads it for what the criteria missed; the slice commits small and working. Arrive with a brain dump: the agent's job is catching every thread and silently dropping none. Keep slices small: you're steering short hops, not launching one long-range missile. Verify against reality, not reasoning: real test output, real responses, real logs. Hard rules go in hooks, not prose, because a sentence in a config file is a request. Spend your smartest model on anything that authors; cheap models fetch, never decide. And have the workflow police you too: one gentle pushback when you skip your own process saves more rework than any tool.
What this actually buys you
Try the smallest version on one real feature: the interview, the decision list, five acceptance criteria in a file, a fresh grader. The "wait, that's not what I meant" moment moves from the end of the work to day one. Then code stops being your bottleneck, and the whole constraint slides upstream: knowing what you want, saying it precisely, verifying you got it.
The part you can't outsource
The loop's real danger is the fugue state: the agent does so well that you ease off, approve one more piece, and wake up a rubber stamp with anxiety. Understanding is the entire reason a human is still in the loop. For a team this is an earthquake (review at volume, merge queues as the constraint, planning as the slowest thing in the building), and that story comes later in this track.