AI Coding Crash Course

You let the agent off the leash. It builds, it ships, it builds, it ships — and it feels incredible. Until the morning you open a pull request you "wrote" and don't recognize a single line of it.

You've lost control of the flow. Then you lose your understanding of it.

Here's the part the doomers miss: that's not an AI problem, and the fix isn't a better model.

Your engineering fundamentals aren't obsolete. They're your biggest advantage. You just need to know how to apply them.

Think about your work in two layers — this is Ousterhout's distinction, from A Philosophy of Software Design:

• Tactical programming — the local, get-it-working move. The actual lines.
• Strategic programming — where the product and the codebase are going.

AI ate tactical programming. It can't touch strategic programming. Strategy is the part it can't see — and that's your job. You hold the strategy; the agent supplies the tactics.

So the real work was never typing the code. The agent will write it.

Will it write the right thing?

The beginner's trap

You reach for the exciting framework, expecting to do great work with it. Instead you build a big ball of mud — because you don't yet know how to use it, and the framework quietly takes the wheel. You lose control of the flow. Then you lose your understanding of it.

That's not an AI problem. It's an alignment problem, and AI just makes it faster.

Most people don't do enough alignment work. They forget the agent has no memory — they drop it cold into their codebase, so it makes assumptions and gets to work too eagerly, too sycophantically. The fix is simple: make it align with you before it starts.

Picture the other version of your week: you open the PR your agent built overnight, read it top to bottom, and understand every line — because you designed the structure it filled in. The tests are green because you decided what "correct" means. You ship before lunch, and the codebase is easier to work in than it was the day before.

That's not a faster typist. That's you, still the engineer — with a tool that finally pulls its weight.

"No one really knows what they want"

That line is from The Pragmatic Programmer, and the whole discipline grows out of it. Nobody hands you the requirements on a plate. So the real skill isn't writing the code — it's discovering what the code should be, and staying aligned with the agent while you do.

This workshop is that discipline, broken into skills you run by name — the exact agent skills I use every day. Small, readable markdown files you can open, edit, and understand. Nothing hidden behind scaffolding:

• grill-with-docs — interrogate the idea until the requirements survive questioning
• prototype — answer "how should this look?" with throwaway code instead of an argument
• to-prd — turn the resolved context into a real product requirements document
• to-issues — break that PRD into vertical slices an agent can grab independently
• tdd — implement one behavior at a time, red, green, refactor
• review — check a diff against your standards and your spec, not just "does it run"
• handoff — carry context between sessions so you stop re-explaining your project every morning
• improve-codebase-architecture — deepen modules instead of widening the mess

The agent shouldn't feel magical. Magic is just control you can't see. I want you fully in control — editing these skills as you go, understanding every part of the flow.

Grill the idea before you build it

Interrogate it. Don't let the agent — or yourself — off the hook with the first plausible answer. An alignment discussion has a fidelity, and the skill is matching the fidelity to the question:

When the question is "how should this look?", stop talking and build

Vibe-code a throwaway. Edit the prototype, not the spec. Don't care about the code yet — a prototype is just an alignment discussion held at higher fidelity. The hard part isn't the first prototype. It's holding it together across sessions — managing the context window as you go. That craft is the part this workshop actually teaches.

Steering isn't steering the agent. It's steering yourself.

It's the ability to keep the wheel — and not let the agent grab it. That's the whole game.

And here's the reassuring part: none of this is new. Everything here I learned from 20- and 30-year-old books. We're taking what already worked — Agile (not by the book, just the parts that earn their place), a sprinkle of DDD — and converting it for a world where the AI is the tactical coder.

You're not delegating to another developer anymore. You're delegating to the agent. The discipline is the same discipline. You stay in strategic control; you keep shaping how the codebase is structured.

What you walk away with:

• One process that scales from a single feature to a whole greenfield app — you learn the method, not a different trick for every situation
• A concrete set of reusable skills you can use on your own work, share with your team, and trust
• And — crucially — skills that are yours to edit and modify for your own needs

Real results from engineers using these workflows

8,564 linting errors down to ZERO thanks to careful planning and a Ralph loop.

@fedeeeeeev

I don't often buy courses, but Claude Code for Real Engineers from @mattpocockuk is a godsend. I'm not a dev, but I built a full Google Ads management system on top of Claude Code.

@AlfredSimon

It's not only about the code that comes out. It's about staying in control of it.

"But the skills are free on GitHub. Why pay for this?"

Fair question. You should ask it.

Yes — the catalog is open source. Two dozen skills, with more than 173,000 installs on skills.sh, free to read and fork right now. Go look. I mean it.

But installing the files doesn't install the judgment: matching the fidelity of an alignment discussion to the question in front of you, knowing when to grill and when to prototype, what a good PRD actually looks like, and how to hold context together across sessions on a codebase that has real users and real consequences.

The skills are the notation. The discipline is what makes them work — and that's what this workshop teaches.

Every company needs its own Matt Pocock.

shadcn

Who this is for

This is for anyone who cares about the code they ship. Two audiences, opposite ends of the same line:

• People who have written tons of code, believe good code matters, and aren't convinced AI is the way to get it
• People who have barely written a line — but refuse to ship a black box they don't understand

If you're a senior engineer, think of this as a conversion course: the same fundamentals you already trust, applied to an agent instead of a junior dev.

You don't need to be an AI expert. You need to be an engineer who wants to stay one.

Frequently Asked Questions

Is this self-paced or live?

Self-paced. Work through it on your own schedule, in your own codebase, and revisit whenever the skills get an update.

Do I need a specific AI coding tool?

The skills are markdown any Claude-compatible agent can read (Claude Code is the obvious one). The practice transfers to any capable agent — the workflow is the durable part, not the tool.

I'm new to agent coding. Will I keep up?

Yes. You need to be a working engineer, not an AI specialist. Each skill is small enough to read in one sitting, and the method builds up one piece at a time.

What's your refund policy?

30-day refund policy. Contact team@aihero.dev.

More questions?

For pricing, PPP, team seats, invoices, gifting, and platform questions, see aihero.dev/faq. Or email team@aihero.dev.