Boondoggling

The Art of Conducting Claude

Anyone can use Claude Code. Boondogglers conduct it.

What Just Happened

A moderately complex website — six routes, a hybrid filesystem/database architecture, an admin dashboard, a community upload pipeline, a sandboxed iframe viewer, and a full prompt library — went from idea to live in roughly three hours.

Two hours of conversation with Gru. One hour with Claude Code.

Nearly all the time was spent talking. Not coding. Not debugging. Not googling. Talking — precisely, in the right order, about what the site was, who it was for, what it would and wouldn’t do, and what each piece needed to be true before the next piece began.

Every prompt worked. Not because the prompts were magic. Because the conversation that produced them was structured.

That is boondoggling.

Gru and the Minions

The mental model comes from the movie. Gru does not build the rocket. Gru designs the mission, assigns the minions, checks their work, decides what the mission IS, and takes responsibility for the outcome.

The minions are excellent. They are enthusiastic. They will execute exactly what they understood you to mean.

That gap — between what you meant and what they understood — is where all the damage lives.

Claude is the minions. Fast, capable, tireless, and completely dependent on the quality of the instruction they receive. Give them a vague prompt and they will produce a confident, plausible, wrong answer. Give them a complete specification — with context inline, output format named, negative constraints stated, and a testable handoff condition — and they will produce exactly what you needed.

Your job is not to type less. Your job is to be Gru.

The Vocabulary of Waiting

Anthropic’s Claude interface has a gift for anyone who works with AI: a collection of words for what Claude is doing while it thinks.

They are not progress indicators. They are tiny moments of delight.

Frick-fracking — the iterative work. Claude Code running, making changes, testing, adjusting. The thing that happens while you are doing something else. Frick-fracking is productive and it does not require your attention. This is where the actual build lives — iterative refinement, the real world testing the app, things needing to change, Claude making them change. Fast. Without drama.

Perambulating — wandering through the problem space. What Claude does when it is exploring before it commits.

Discombobulating — the moment before clarity. Useful to name. It means something real is being worked out.

Confabulating — the danger word. When Claude is producing plausible output that is not grounded in reality. This is why the human supervisory capacities exist. Confabulation sounds correct. It often reads correctly. Only domain knowledge catches it.

Ruminating — turning something over. Slow and deliberate. Good for complex reasoning steps.

Cogitating — working it out. Formal, a little stiff, which makes it funnier.

Noodling — dreaming. The lightest touch. This is where new features come from — not a spec, not a requirement, just a thought that something could be interesting. Noodling is the beginning of the next build.

Pontificating — holding forth at length. Occasionally useful. Occasionally what Claude does when a shorter answer would have served.

Gallivanting — going off in a direction that was not requested. A risk. Also occasionally where the best ideas come from.

Whoever picked those words at Anthropic has good taste. They turn “waiting for AI to think” from an annoyance into a small moment of delight. And naming a platform after one of them — boondoggling, the productive messing-around that happens when you are learning to conduct AI properly — is exactly right.

The Five Things Only You Can Do

Boondoggling makes five supervisory capacities explicit. These are not skills you develop. They are roles you exercise at specific moments in a build.

[PA] Plausibility Auditing
Hearing the wrong note before you recompute it. Knowing an output is wrong because of what you know about the domain — not because you checked. This is the capacity that catches confabulation. Claude cannot do this for itself. It does not know what it does not know.

[PF] Problem Formulation
Deciding what the mission is before Claude sees it. Not reframing after — before. The quality of the output is determined here, before any prompt is written. A poorly formulated problem produces a confidently wrong solution.

[TO] Tool Orchestration
Choosing which Claude task, in what order, with what context, and how to verify it. Deciding when to trust the output and when to run another check. This is the capacity that turns a collection of prompts into a build sequence.

[IJ] Interpretive Judgment
Supplying meaning, accountability, and domain reality to Claude’s output. Deciding which of Claude’s variations is correct for this context. Signing your name to the decision. Claude cannot be accountable for what it produces. You can.

[EI] Executive Integration
Holding all four simultaneously toward a unified goal. Recognizing when one Claude output requires another task to re-engage. Knowing when the build is done.

None of these are things a better model will eventually do. They are structural features of what statistical pattern matching is. The gap between what Claude produces and what is true in your specific domain will not close. Your job is to stand in that gap with judgment.

The Boondoggle Score

After a Software Design Document is complete, /claude generates the Boondoggle Score.

It is a conductor’s score with two simultaneous parts: the Minion Part (exact prompts for Claude, in dependency order) and the Gru Part (precise human actions, labeled by supervisory capacity, in the same dependency order).

Every Claude task has:

• Context required (what Claude needs in its window for the prompt to work)
• A complete, copy-pasteable prompt (context inline, format specified, negative constraints named)
• An expected output (specific enough to know whether you got it)
• A handoff condition (exactly what must be true before the next step begins)

Every human task has:

• A supervisory capacity label
• A specific action (not “review the output” but “verify that every entity in the schema maps to a documented need and flag any that exists only to serve another entity”)

The score is ordered by dependency, not by phase. A Claude task with no upstream dependencies can begin immediately. A human task that requires multiple inputs does not begin until all inputs are confirmed.

The handoff condition is the most important element. A minion who does not know when to stop will stop at the wrong place or not stop at all. The handoff condition is the conductor’s downbeat.

What Comes Next: Frick-Fracking

The site is live. That is version one.

Version one is not the product. Version one is the thing you learn from.

The real world will test the site. Users will find paths you did not design for. Features will feel different in production than they did in the SDD. Something will be missing that nobody thought to specify.

This is where frick-fracking becomes the primary mode.

Frick-fracking is iterative refinement. Claude Code running while you are doing something else — boondoggling, in the original sense. Small changes, fast. A layout that needs adjusting. An edge case that surfaced. A feature that was IMPORTANT that is now clearly MUST-HAVE because three people asked for it in the same week.

The process for frick-fracking is lighter than the full SDD build. It is:

1. Name what needs to change and why (one sentence)
2. Check whether the change contradicts anything in the SDD (one minute)
3. Write the prompt (precise, context inline, handoff condition named)
4. Verify the output
5. Ship

The SDD is what makes frick-fracking safe. Because the architecture is documented, small changes do not accidentally become large ones. Because the principles are locked, feature creep has a name and a date when it is caught. Because the domain model has a ubiquitous language, every prompt uses the same terms and every output is legible.

What Comes After That: Noodling

Noodling is dreaming. It has no deliverable. It is the lightest touch — a thought that something could be interesting, a feature that might exist, a direction the platform could go.

Noodling is where the next SDD begins.

The discipline is knowing which noodle is worth developing and which is a gallivant — an appealing direction that does not serve the person the site is built for. The SDD’s problem statement is the filter. Every noodle that survives the “what problem does this solve for whom?” test becomes a candidate for the next build cycle.

The ones that don’t survive get written in P2 with a date on them.

The Practice

Boondoggling is not a tool. It is a practice.

The practice is this: before Claude sees the problem, you decide what the problem is. Before Claude produces output, you specify what done looks like. After Claude produces output, you verify it against domain reality before the next step begins.

You are not saving time by skipping those steps. You are borrowing it, at interest, from the moment when the wrong thing ships and has to be unwound.

The minions are excellent. The mission is yours.

Anyone can use Claude Code. Boondogglers conduct it.

Built with Gru. Documented with the methodology it teaches.
boondoggling.ai