Karpathy drew a line recently.
Vibe coding → agentic coding → agentic engineering.
Vibe coding: you tell AI "build me an app," it builds something you don't fully understand, but it runs.
Agentic coding: you give AI a clear task, it executes autonomously.
Agentic engineering: you manage a team of AI agents the way a tech lead manages developers.
I'd been doing the first two for months. Shipped three iOS apps in January. Distilled 53 MBA courses with a 6-agent pipeline. But it was always one agent at a time, serial, maxing out at whatever fits in a single context window.
Then Anthropic shipped Agent Teams inside Claude Code. Multiple agents, parallel execution, shared codebase, independent contexts, one lead coordinating. A real team topology — except the team members are AI.
I tested it on something real.
The Setup
2 PM. Three people on a video call.
A sales training consultant with frontline pain points. My engineer partner with technical instincts. Me with a vague idea: build an AI sales coach for FMCG field teams.
Ninety minutes of unstructured conversation. Recording: 29KB. Meeting over.
By 10 PM, the project directory looked like this: 73 source files, 52 dev specs, 15 planning documents, 26 knowledge base assets, one 24KB project constitution. A working monorepo. Type definitions complete. LLM abstraction layer with three providers. RAG service skeleton in place. Database migrations written. Mobile app with four tab shells ready.
4 days later, fully delivered: 2,716 tests passing, 105,000 lines of code.
Eight hours to skeleton. Zero hiring. Zero sprint planning.
One person, one terminal, one swarm.
The Part Nobody Wants to Do
After the meeting, the first thing I did was not write code.
I wrote documentation.
Not the kind you write to satisfy a process. The kind where you actually think.
PRD first. Three MVP features — talk track generation, objection training, client relationship management. Explicitly excluded: GPS check-ins, shelf photo capture, order management. The client said something that stuck: "It has to go beyond generic AI, or why would I pay?" The differentiator was never conversational ability. It was industry knowledge depth, client memory, and embedded sales workflows.
Then three layers of knowledge distillation. Sales methodology. Competitive analysis. Business templates.
Then a 16KB system prompt draft. Role locking, guardrails, objection classification, refusal templates.
Then a dev checklist. 10 tasks, SQL schema, API inventory, milestones.
120KB of documentation. Every word written for agents to consume.
This is the part most people skip. Writing specs is boring. Thinking is boring. It's much more satisfying to open a terminal and start hacking.
But here's the thing I've learned the hard way: agents don't think for you. They execute what you've thought through. The clearer the input, the better the output. The fuzzier the input, the more they "helpfully fill gaps" — and what they fill in is almost always garbage dressed up as productivity.
The Inversion
The old ratio of thinking to building was roughly 1:5. One day thinking, one week coding.
Now it's 5:1.
I spent most of the afternoon on documentation, knowledge distillation, architecture decisions. The agents turned all of it into 73 source files in under two hours.
Thinking clearly is the output. Documentation is the code — it's just in pre-compiled form.
How Agent Teams Actually Work
One lead agent reads the project constitution, breaks down the work, assigns tasks. Specialist agents each pick up a piece — frontend, backend, RAG service, type definitions — and execute in parallel. They share the codebase but each operates within its own context window. When they finish, they report back to the lead, who handles integration.
It's a real team topology. Tech lead, frontend engineer, backend engineer, infra. Except no one needs a standup. No one has opinions about tabs vs spaces. No one leaves for another company mid-sprint.
I'd tested this pattern before. When I distilled 53 MBA courses from PKU Guanghua, I ran 6 agents in parallel — one data fetcher, three distillers, one auditor, me as coordinator. 53 courses, two weeks, 173 reusable Concepts extracted.
The SFA project was faster because I'd learned something from that experience: what agents need isn't a task description. It's a constitution.
The Constitution
CLAUDE.md. 24KB. Not a README. A constitution.
It defines everything an agent needs to know to write code in your project:
Identity — you're the architect. Deadline is physical, not aspirational.
Code standards — functions under 20 lines, files under 800 lines, three levels of nesting means a design error. SSE streaming uses EventSource format. API responses use a unified envelope. Type imports use the type keyword.
Documentation protocol — three layers. L1 is the constitution itself. L2 is module documentation. L3 is file header comments. Every source file header specifies INPUT, OUTPUT, POS. If code changes but docs don't update, the task isn't done.
Quality gates — Phase Gate at every milestone. Zero lint errors, type checking passes, all tests green, new files must have L3 headers.
A good constitution for agents is like a three-day onboarding for a new hire.
The difference: agents actually follow it.
52 Specs
The constitution is the operating system. Specs are the task queue.
I broke the project into 52 specs. From 001-environment-setup to 052-final-delivery. Every four feature specs, I inserted a tech-debt spec. That rhythm matters — it keeps technical debt from compounding until the final explosion.
Each spec is self-contained: objective, acceptance criteria, dependencies, estimated effort.
An agent doesn't need the big picture. It picks up the current spec, reads the constitution, executes. Done. Next.
This is the core of agentic engineering: you don't write code. You write specs. Good specs produce good output. Bad specs produce agents working very hard to build beautiful garbage.
The Engineer's New Job
Old world: PM writes PRD, engineer builds from scratch.
New world: I used Agent Teams to turn a PRD into a running monorepo. When my engineer partner picks it up, architecture is decided, types are defined, abstraction layers are built, migrations are written, specs are broken down.
His job shifts from "build from zero" to "fill in business logic, polish UI, add tests, do code review."
From builder to reviewer.
That's not a demotion. That's the most efficient division of labor possible. An engineer's happiest state is receiving a project with clean architecture, complete types, thorough documentation — and jumping straight into the interesting parts.
Agent Teams handle the part that "should have been thought through before anyone started coding, but nobody ever does." Because thinking things through is tedious. Most teams choose to figure it out as they go. Figuring it out as you go means refactoring three times.
The Real Shift
It's not AI replacing engineers.
It's that the form of human output has changed.
Before: PM produces a PRD in Word. Engineer produces code in an IDE. Designer produces prototypes in Figma. Three outputs, three tools, three translations.
Now: I produce what I call "agent-executable instruction assets" — constitution, knowledge base, specs, type definitions, guardrail rules. Agent Teams turn these into code. One translation.
The engineer's core competency shifted from writing code to writing constitutions.
A constitution is taste, encoded. Taste can't be taught, but it can be encoded. Once encoded, it can be replicated.
If your CLAUDE.md is good enough, any agent can write code in your project that's consistent in style, architecture, and quality. That's not automation. That's organizational design — applied to silicon.
The Symmetry
Here's the part I find most interesting.
I came from HR. I spent years studying organizations — how to design structures that minimize internal friction, how to transmit information without distortion, how to build organizational capability.
Now I apply the exact same principles to Agent Teams. Role separation. Document-driven collaboration. Quality gates. Human adjudication at critical junctures.
Organizational theory hasn't changed. The members of the organization went from humans to agents.
The best management practices — clear roles, documented standards, quality checkpoints, escalation protocols — turn out to be exactly what makes AI agent teams productive.
If you were a bad manager of humans, you'll be a bad manager of agents. If you were good at building systems that let people do their best work, you already know how to write a constitution.
One Line
Someone in the meeting said: "Start light. Take off hard."
They meant product strategy.
I turned it into an engineering methodology.
One afternoon. From a meeting recording to a running project. One person, one terminal, a swarm of agents.
Done. Shipped.
I'm @UncleJAI. I build products with AI agent teams and document what I learn. If you're interested in the space between managing humans and managing agents, you might find something useful here.
