Manage Your AI Like a Brilliant (and Hasty) Junior Dev

Your AI coding agent — Claude Code, Cursor, Copilot, take your pick — behaves like a brilliant junior developer: it codes faster than anyone, never gets tired, knows every syntax by heart… and charges ahead without asking. The right response isn't to write the code yourself, and it isn't to let it run wild. It's to manage it. That's the core thesis of Steve Yegge and Gene Kim in their book "Vibe Coding" (IT Revolution), and it boils down to two ideas. One: adopt the "Head Chef" posture — you no longer write the syntax; you design the menu (the architecture), delegate the prep work (the tasks), and taste every dish before it leaves the kitchen (you validate). Two: apply their FAAFO framework — Faster, Ambitious, Autonomous, Fun, Optionality — where the highest-leverage item is optionality: ask for several alternative implementations and pick one, instead of accepting the first draft. In practice: small, closed tickets; a plan before any code; reviews focused on risk zones; and architecture decisions that stay human.

Why "brilliant junior" is the right mental model

A good junior developer ships working code fast, with enthusiasm. But they optimize for "it compiles and it renders", not for "it will still hold up in six months". And they almost never say "I don't know" — they always propose something.

AI coding agents are the same, times ten. They won't ask whether your database will survive that query. They won't raise a hand to say "wait, this requirement sounds off". They just go.

Which leads to a simple conclusion: the problem is almost never production speed — it's the lack of framing. A poorly managed junior produces fast chaos. A well-managed one becomes a force multiplier. AI follows the exact same curve.

The Head Chef posture: design the menu, taste every dish

Yegge and Kim reach for a kitchen metaphor. In a brigade, the head chef doesn't chop every onion. They decide the menu, assign the stations, and taste every plate before it leaves the pass.

Translated to your workflow:

  • The menu is the architecture. Which building blocks, which data, which flows: that's your call, not the AI's.
  • The prep work is the tasks. You delegate precise pieces, never the whole meal.
  • Tasting is validating. Nothing ships until you've checked the result — by testing the behavior, not by admiring the code.

The shift: you spend less time typing syntax and more time deciding and verifying. That's real work. It's arguably THE work now.

FAAFO: the habit that changes everything is optionality

The FAAFO framework from "Vibe Coding" sums up what AI gives you: Faster, more Ambitious, more Autonomous, more Fun, and more Optionality.

The last one is the most actionable. When generating an implementation costs a few minutes, there's no reason left for the first draft to be the one you keep. Ask for three.

Give me 3 approaches for handling image uploads:
1. The simplest thing that works
2. The most robust (errors, large files, resumability)
3. The one you'd recommend, with your reasoning
Don't write code yet. Compare them in 5 lines each.

You just turned a gamble into a choice. That's exactly what a lead does with a junior: "show me your options before you lock yourself into the first one".

The four reflexes of a good AI manager

1. Small, closed tickets. "Build me the app" is the fastest route to getting anything at all — random anything. "Add email validation to the signup form, with an error message under the field" is a ticket: clear scope, verifiable outcome. If you can't verify the result in two minutes, your ticket is too big.

2. Plan before code. Make the AI explain what it's about to do before it does it. "Describe your plan in 5 bullet points and wait for my OK." You catch wrong turns when they cost nothing, not after 400 lines.

3. Review like a lead, not like a proofreader. A lead doesn't read every line of a junior's PR. They go straight to the risk zones: anything touching money, passwords, user data, or deletions. The rest gets a skim, and the tests take it from there — a solid test suite is exactly the safety net your AI junior needs.

4. Architecture stays human. The AI can propose, compare, and argue. But the structural decision — which database, how to split the system, what lives where — is yours. It's the most expensive decision to change later, which is precisely why you don't delegate it.

Never coded (or managed) before?

Good news, and it's genuine: this demanding-project-manager role is learned far faster than syntax.

Learning to code "for real" takes years. Learning to split a need into small tickets, demand a plan, verify an outcome, and ask dumb questions until you understand — that's practice, not a degree. And you already have some of these reflexes if you've ever organized a move, a wedding, or a team schedule.

The non-developer's trap isn't a lack of technical skill. It's excessive politeness toward the machine: accepting the first answer, not daring to say "redo it", never asking "why". A good manager isn't rude — but they're never a spectator.

Where to start today

On your very next AI session, apply just this:

  • [ ] Write the ticket before opening the chat. One sentence: what, where, and how you'll verify it's done.
  • [ ] Ask for the plan. "Explain your approach in 5 bullets before writing code." Then actually read it.
  • [ ] Demand 2-3 options for any structural choice. New dependency, new data model, new building block: never a single proposal.
  • [ ] Review risk zones first. Money, authentication, personal data, deletions. Everything else: skim plus tests.
  • [ ] Keep a decision log. A DECISIONS.md file with three lines per architecture choice. Future you (and your future AI) will thank you.
  • [ ] End by tasting the dish. Use the feature like a real user before moving on to the next ticket.

You're not typing the syntax anymore. You're running the kitchen. And that skill comes fast.