📖 Living glossary (read first — come back whenever you need to)
These are the NEW terms in this module. Since you’ve already seen the core vocabulary (model, agent, prompt, skill, codebase) in Track 1, here we focus on the vocabulary of delegation:
🧩 Design the difficult parts
🧠 Imagine it this way: an architect hires fast, strong bricklayers. But they don't say "build a house" and disappear — they designs the plan first, solving the foundation and the difficult structure on paper. The builders put up the walls. It’s the same with AI: you design the difficult parts; AI builds the rest.
Pocock makes a claim that unlocks everything: "strategic programming hasn't changed with AI — we've just replaced delegating to junior developers with delegating to AI." In other words, delegate has always been a senior programmer’s skill, and that hasn’t changed. What changed was only for whom you delegate. And the first rule of delegating well is: design the hard parts up front — you, the human, before handing off the task.
Why? Because AI, like a junior, it’s excellent at carrying out a decision that’s already been made and terrible at take the difficult decision on its own. The "hard parts" are the architecture choices: how to structure the data, which approach to use, where the risks are. If you skip this and say "solve problem X," the AI will invent some solution — maybe plausible on the surface, but fragile. The common mistake here, speed is confused with delegation: throwing a poorly thought-out problem at AI and assuming “it’ll think for me.” It won’t think strategically for you—that's exactly the work left for you.
The hard decision is yours; repetitive execution goes to AI. Reversing that is mistake #1.
⚠️ Common beginner mistake
Tell the AI to "decide the architecture" of an important system. It will propose something — but the strategic choice is the part that costs you the most if it goes wrong. You decide; let the AI implement the decision.
In one sentence: you design the hard parts; AI handles the easy ones — never the other way around.
Going deeper (optional): why "AI eats tactical, not strategic"?
Pocock says that "AI has basically eaten tactical programming" — the day-to-day work of typing syntax, which AI does better and more cheaply. But the strategic part (what the system should look like, how to divide the tasks) remains human. Designing the hard parts is pure strategy: it’s exactly the work that AI no ate, and that’s why your time is most valuable there.
✂️ Clear scope
🧠 Imagine it this way: asking an intern to “organize the office” is vague — they could spend all day and do the wrong thing. Asking them to “label and file these 30 folders alphabetically by 5 p.m.” has scope. The second request always turns out better, whether you’re working with AI or people.
Pocock’s second lever is scope tasks very well. Scope is the scope: what the task includes, what it excludes, and how big it is. A clearly scoped task has a clear beginning, middle, and end—the AI knows exactly when it’s done and doesn’t wander into areas you didn’t ask for.
Why does this matter so much with AI? Because a fast junior with a loose scope is dangerous: they a lot of things quickly, and much of it misses the mark. Tasks that are too big also overload the AI’s working memory (the context window) and it loses the thread. The rule of thumb: break work into small, verifiable tasks with an explicit "done" criterion. The common mistake is the catchall request (“refactor the entire system”)—without scope or success criteria, the AI delivers a pile of changes you can’t even review.
Quick recall: which of these requests has a clear scope?
In one sentence: small task, with limits and a “done” criterion = the AI gets it right; bucket-list request = the AI gets lost.
🔌 Interfaces between modules
🧠 Imagine it this way: an outlet and a plug. It doesn’t matter who made the iron or who wired the house—as long as both follow the outlet standard, they fit. The interface is the outlet: the contract that lets two separately built parts work together.
Third lever: think through the interfaces between modules. A module is a part of the system with a single responsibility (the payment module, the email module, the login module). The interface is the contract between them: how one calls the other, what it receives, and what it returns.
This is what makes delegation scalable. If you define the interface first, you can hand each module to a different AI “instance” (or a different junior developer), and they can work in parallel without getting in each other’s way — because each one only needs to follow the contract, not know the other’s internals. It’s the same principle that lets a factory assemble separate parts that fit together later. The common mistake: leave the interfaces implicit. Then the AI in module A “assumes” one format, the AI in module B assumes another, and when it’s time to put them together, nothing fits—the classic “it worked in my part.”
In one sentence: define the “contract” (interface) between the parts, and AI can build each part on its own, in parallel.
🧪 Tests and scenarios
🧠 Imagine it this way: you give the junior a checklist before they hand it in: "did you test with a blank name? with a negative age? with the internet going down?". That list is what separates "seems to work" from "actually works." AI needs the same list.
Fourth lever: think through tests and scenarios. A test is a small piece of code that runs and says "passed" or "failed." The scenarios (edge cases) are the nontrivial situations that tend to break everything. Thinking about these scenarios when delegating is half the design—because that’s where most of the bugs live.
Tests play a special role when you delegate to AI: they are the automated quality gate. If you provide the task along with tests (or ask the AI to write the tests first), the AI can run them and tell whether it got things right — without relying on you to review every line. That closes the loop: the AI executes, tests, fixes, and repeats. The common mistake is delegating only the “happy path” and forgetting about failure scenarios; like a junior, AI will happily deliver something that works only in the ideal case and blows up at the first empty field from a real user.
🔬 Worked example: delegating a registration function
Task: "create the function that registers a user". See the difference between delegating with and without scenarios:
No scenarios
"Create the user registration." → AI saves the name and email. It works in the demo. In production: accepts duplicate email addresses, accepts empty fields, breaks with accented characters. Bugs on day 1.
With scenarios + tests
"Create the registration. Cover: duplicate email (reject it), empty field (clear error), name with an accented character (accept it). Write tests for these 3 cases." → AI implements it, runs the tests, and adjusts it on its own. Solid delivery.
The only difference was you having thought through the scenarios when delegating. The AI did the grunt work.
In one sentence: provide the scenarios and tests along with the task—they become the quality gate the AI uses on its own.
🗺️ Sufficient documentation
🧠 Imagine it this way: A treasure map doesn’t describe every grain of sand — it marks where to dig. Sufficient documentation is the map: it points the AI to the right places in the project without turning into a novel no one reads.
Fifth lever: sufficient documentation. Pocock is precise about the word—it’s not documentation exhaustive, it’s documentation enough "to point the AI to the right places." The difference is huge: nobody maintains too much documentation (and it rots, becoming misleading); too little documentation leaves the AI guessing. The sweet spot is the minimum that provides guidance.
In practice, this almost always becomes a context file in the project root (you’ll explore this in depth in Track 3, with the skills). It describes the architecture at a high level, where everything lives, and the project’s patterns. It’s like leaving notes for a junior developer: "components are in /src/ui, tests go next to the file, always run lint before committing." The common mistake is treating documentation as a favor to "someone else" — when, with AI, it’s a productivity multiplier yours: every well-placed note saves ten back-and-forths.
In one sentence: don't document everything — document enough to point the AI to the right places.
🧑🎓 Delegate like you would to a junior
🧠 Imagine it this way: An experienced manager knows exactly how to assign a task to an intern: context, limits, what to check, where to find things. When that same manager uses AI, they simply reuse the instinct they already have. Anyone who’s never delegated to people struggles to delegate to a machine.
Pocock’s big insight is to bring it all together in one sentence: delegating to AI is like delegating to a junior. It’s not a cute metaphor—it’s literal. The AI has the profile of a junior excellent: incredibly fast, tireless, enthusiastic, but without the strategic vision of the whole. Pocock even notes that "AI makes senior developers 10x better" precisely because the senior already has the delegation muscle — they point the AI, it does the work, and the multiplier is huge.
The consequence is liberating: you don’t need to learn a “secret art of prompts.” You need to become a good manager. The five levers in this module are exactly what a good manager does when handing off a task: designs the hard parts, scopes it, defines interfaces, asks for scenarios, and leaves a map. The common mistake The final point is to treat AI like an oracle ("it knows everything") instead of a junior ("it does what I know how to delegate"). People who treat it like an oracle get frustrated; those who treat it like a junior multiply their output. Use the checklist below every time before handing off a task:
Antes de delegar uma tarefa pra IA (= pra um júnior veloz), responda: [ ] DIFÍCIL — eu já decidi a arquitetura / a parte difícil? (não deixe pra IA) [ ] ESCOPO — a tarefa é pequena, com limites e um "pronto" claro? [ ] INTERFACE— o contrato com os outros módulos está definido? [ ] TESTES — listei os cenários ruins (vazio, duplicado, erro) e pedi testes? [ ] DOC — apontei a IA pros lugares certos do projeto (mapa, não romance)? Se um item está em branco, é AÍ que a IA vai errar. Preencha antes de soltar.
Quick retrieval: according to Pocock, what changed in strategic thinking with the arrival of AI?
In one sentence: don't become a "prompt master" — become a good manager; AI is your fastest junior developer.
🧾 Module Summary
Next module:
2.5 — Communication & dictation: why speaking is "overpowered" and how dictating doubles your speed with AI.