From prompter to engineering manager

The closing lesson. You've learned the tools — subagents, hooks, MCP, skills, scheduled work, the model tiers. The mechanics are settled. What changes from here isn't which feature you use; it's the role you take.

The two ways people use Claude Code

After watching a lot of people work with this kind of tool, two modes stand out clearly.

Mode one: the prompter.Treats Claude Code as a very fast autocomplete. Types a request, watches it work, fixes the bugs, types another request. Stays in the driver's seat for every decision. Productive — much faster than typing all the code themselves — but capped at "how fast can one person think about one task at a time."

Mode two: the manager.Treats Claude Code as a small team they're running. Hands out focused briefs. Spawns multiple agents in parallel. Reviews their output. Builds skills that capture recurring workflows. Spends most of their time framing problems and steering, not typing solutions. Their ceiling isn't how fast they think — it's how many things they can keep in flight without losing the thread.

Mode two is ten times faster than mode one on the right tasks. It's also more demanding. Anyone can prompt; managing well is a skill.

What the shift actually feels like

At first, the natural instinct is to micromanage. You wrote a line; Claude rewrote it; you want it the way you had it. You keep stopping the agent to adjust. The conversation gets long and tactical.

The shift happens when you start trusting Claude with whole tasks rather than individual edits. "Add the contact form" instead of "put a div here, then a label, then an input." "Refactor this module" instead of "extract this function." You set the destination; Claude picks the route.

And then the next shift: you start running more than one task at once. While Claude implements feature A in one worktree, you draft the prompt for feature B in another. While a subagent audits performance, you're reviewing yesterday's completed work. The bottleneck stops being "how fast can Claude type" and becomes "how cleanly can you delegate."

The manager's actual job

If you were a real engineering manager running a real team, your week would look something like this:

• Framing what should get done and what shouldn't.
• Breaking work into pieces that one person can hold in their head.
• Writing those pieces clearly enough that they can be picked up.
• Reviewing output. Approving good work, redirecting bad work.
• Maintaining the shared context — the team docs, the conventions, the "here's how we do this" knowledge.
• Making the calls only you can make.

Substitute "Claude session" for "a person on the team" in each of those, and you have a description of what your week becomes once you're fluent. The skills are the same: clarity of writing, decomposition of problems, good judgment, good taste. None of them are new — they've just been moved into the foreground.

What to keep doing yourself

Delegation is not abdication. Some things you should never hand off to an agent, no matter how confident it gets:

• The decision about what to build.Claude can implement anything; it can't tell you whether the thing is worth implementing.
• The taste calls.Is this design any good? Is this naming any clearer? Is this writing any better? Your taste, not the agent's, is the standard.
• The final review on anything that matters. The diff before a production deploy. The wording of an email to a real person. The decision to merge.
• The relationships. The conversations with customers, teammates, stakeholders that shape what to do next.

Everything in between is fair game for delegation. The skill is knowing which is which.

Building a personal workflow

Over time you'll develop a personal pattern. There's no single right one, but the components that show up in most good workflows:

1. A curated CLAUDE.md per project, updated regularly.
2. A handful of personal skills for the workflows you do over and over.
3. A small library of slash commands for the quick stuff.
4. Hooks that enforcethe rules you don't want to remember.
5. A habit of plan-mode for anything non-trivial.
6. A habit of frequent commits so rollback is always cheap.
7. A habit of reading the diff before accepting.

None of those are exotic. Each one is a five-minute investment you make once and benefit from every day after.

What to study from here

You've finished the curriculum's structured part. The learning that follows is less linear:

• Read other people's skills and CLAUDE.md files. Many teams open-source theirs. Steal good ideas.
• Try uncomfortable workflows.Run an agent unattended overnight on a long task. Try to build something you don't know how to build, and steer rather than type.
• Read the official Claude Code docs. They update faster than any curriculum can; bookmark them.
• Watch experienced users. Live streams, recorded sessions, screen-shares. Watching a fluent delegator at work is the fastest way to absorb the rhythm.

Where this is heading

It is not a stretch to say that the next decade of software will be built mostly this way. The work that used to require a team will be done by a person plus a fleet of agents. The work that used to require a person will be done by the agents directly while the person reviews. The job of "writing software" will look more and more like the job of running software development.

Which means the skills that matter most in this future are the ones managers and senior engineers have always had: knowing what to build, knowing when something is good, knowing how to explain a complex thing simply, and the steady judgment to keep many things in flight without losing the thread.

That's the curriculum, in the end. We started at " what is a computer." We're ending at "how do you direct a small team of them." You have the tools. Now go build something.