Free resource

The AI Engineer's Production Workflow

grill → slices → build → ship — the workflow behind every project in the Claude Code Masterclass.

Johannes HayerThe AI Engineer

Most developers open Claude Code and start typing. Claude writes something, they tweak it, it drifts. Two hours later the code "works" but nobody can explain why — or where it's going next. An AI that isn't steered fills the gaps with its own best guess — and by the time you notice it drifted, hours of work sit on the wrong assumption. A workflow isn't process for its own sake: it's the guardrail that keeps the AI pointed at what you actually want. Here's the one I use.

The whole pipeline

Idea → PRD → slices → orchestrated build

full-workflow-diagram.png

Diagram: an idea for a SaaS goes through a grill loop between you and Claude via /grill-me — analyse, ask, reply — reaching a shared understanding and producing a PRD. The PRD splits into vertical slices (Slice 1, 2, 3), each running Implementation then Verification, routed to opus/high or sonnet/low effort depending on difficulty. The /implement orchestrator prepares branches, spawns implementation and verification agents per slice, and tracks status across all of them.

The exact system below is what builds every slice of the Claude Code Masterclass — and this site.

Before any of this

A codebase built for TDD

None of the four steps below work without solid ground under them. The precondition is a codebase set up well enough to actually run test-driven development on — and that starts with CLAUDE.md and path-scoped rules in .claude/rules/: the conventions for HOW code gets written, separate from the WHAT of the workflow itself.

What it is: Commands, stack decisions, scope, coding rules, current focus
What it's not: A to-do list, a summary of today's session, a place for "nice to have" ideas
Rule of thumb: if you've said the same instruction to Claude 3 times, it belongs in CLAUDE.md or .claude/rules/

Covered in full depth later in the Masterclass — here, it's just the foundation everything else stands on.

Grill the idea into a shared understanding

Every project starts as a raw idea — "a SaaS for X." Before any code exists, you and Claude run a loop: it analyses the idea and grills you on it via /grill-me — questions from every side — until the business logic and the real-world constraints are actually captured, not assumed.

What comes out:

A PRD (Product Requirement Document) — the full picture of what you want to achieve
Every assumption, dependency, and edge case surfaced before it becomes code
A plan you and Claude actually agree on — not just your first draft of the idea

Why: Skip this loop and Claude builds against its own guess of what you meant — not what you actually need.

PRD → vertical slices, via /prd-to-slices

A PRD is the full picture — and a full picture is exactly what breaks agents. A single agent can't reliably work off a big plan in one pass. My own /prd-to-slices skill splits it into vertical, testable slices instead: thin cuts through the full stack, not "frontend layer" or "backend layer" — each with a tight feedback loop, so you (and the AI) can tell if it's heading the right direction before too much gets built on the wrong assumption.

What /prd-to-slices produces:

Vertical, testable slices — each independently shippable with one clear verify condition
Slices ordered by risk (unknowns first); later slices can build on earlier ones, but the dependency stays explicit
A proposed model + effort level per slice, based on complexity — simple slice → Sonnet at low effort, gnarly slice → Opus at high effort
A named Implementation agent and a separate Verification agent for that slice — so the one that writes the code never grades it

Bad slice

"Build the database schema"

Good slice

"User can upload a photo and see it in their dashboard"

Gnarly slice

opus · high effort

Simple slice

sonnet · low effort

Why: A single agent can't reliably work off a big plan — and if the same agent both builds and verifies, it's just grading its own homework.

/implement drives each slice

My own /implement skill runs the slices end-to-end: it prepares a branch, checks it out, and spawns the implementation agent at the model and effort /prd-to-slices already assigned — none of it hand-managed.

It knows the current status of every slice throughout the run — what's shipped, what's in progress, what's next to invoke — so nothing gets lost between sessions.

What /implement does:

Prepares and checks out a branch per slice
Spawns the implementation agent at the assigned model/effort
Merges finished slices into the main feature branch
Always knows what to invoke next

Why: This is the same skill this exact site is built with — every slice of it, this page included.

The Verification agent closes the loop

Once a slice is done, the Verification agent runs the real end-to-end checks — does it actually behave as specified, not just compile? If it passes, the slice ships and the pipeline moves to the next one: no adjacent cleanup, no mid-flight refactors — noticed improvements get written down for later, not bolted onto the current diff.

If it doesn't pass, it goes back to implementation and gets fixed. The loop doesn't advance until a separate agent — not the one that wrote the code — actually confirms it's right.

Why: A slice isn't done because an agent says so. It's done because a second, independent check confirms it.

quick-reference.md

CLAUDE.md + .claude/rules/ → the HOW: coding conventions, the foundation underneath
/grill-me              → loop with Claude until idea → shared PRD
/prd-to-slices         → PRD into vertical slices + a proposed model per slice
/implement             → runs each slice at the assigned model, tracks status
Verification agent     → separate from Implementation — checks end-to-end, loops back if it fails

Watch this in action

In the free Claude Code Masterclass, I apply this workflow live — building a real AI SaaS (headshot generator + Stripe payments) from an empty folder.

Get the free Masterclass