Home

2025

2024

Worklog

LETSGO Game

Instructing Claude
🪫

Instructing Claude

Owner
JerkyTreats
Tags
AIVibe Coding

Here’s my current way of vibe coding.

It’s probably not the best way, but its been successful enough for me, so I thought I’d share.

First, put a .agent/ folder at the root. This is where I do most of my design work.

Then generate feature briefs in the .agent folder.

My largest vibe coded project, the polygenic-risk-calculator, has tons of briefs in the .agent folder:

image

Describe the feature/implementation. The more detail you put in the better, usually better to add to the brief directly.

Then refactor the brief, removing the garbage it added, clarifying the bits you care about.

For me it usually means refining folder structure, how each thing will feed into each other, etc.

I almost always use the term using go idiomatic best practices.

Claude responds well to those words.

Then get a new conversation agent to rewrite the whole thing, focusing on being concise and removing duplication.

The refine some more.

The real trick of vibe coding- is not coding.

Refine, refine, refine.

Really force yourself to consider the actual, real architecture you intend to build.

This has always been the trick to building real software. Claude will absolutely punish you for not doing it.

So put your boots on, get in the muck, and really think about the system you intend to build.

The data model you need, the validation required, the responsibility of logic.

All the bits you’ve always needed to do.

Then you build it.

Just kidding, you start another chat, tell it to read the brief and provide a detailed implementation plan.

You give it explicit instructions not to write any code unless authorized.

You review what it intends to build.

Then you tell it to write as a markdown table with todo, in progress, and done.

Then you load another new conversation, tell it to do Step 1 then wait further instructions.

Give it the shortest possible leash.

It’s Your Code

Here’s the thing about doing it this way, the output should be more or less indistinguishable from your own code.

The personality of software isn’t in each line of code, its the thought process around how all the pieces of the puzzle fit together.

Without intervention, the personality of LLM generated code is repetitive, verbose, and often misses the point.

With intervention, it looks like 80% of the code you would have written anyways, just implemented faster.

And I do mean faster.

Being forced to write a design doc of your feature?

That significantly increases the speed of you successfully completing the feature, LLM or not.

The human tendency is to just get coding and hang yourself with poorly thought-out decision making.

Especially on solo projects where the human is enthused.

So being forced to write spec? Before building the thing?

We should be thanking Sam for building such unreliable coders.

And when you finally let the LLM rip, it just does the thing, getting it 80% right.

You tell it to write unit tests, and because the bot is doing it you don’t really have to care if the tests are all that good.

Hell I put the required tests in the brief. I don’t care how it does test, just a reasonable approximation that the function does the thing.

Because then you test, debug, fix the issues, etc.

You know, normal development from here on out.

If your design is sound, it should be pretty easy to spot where the robot confused itself.

And if your design is not sound, you’ll quickly get to that 80% point where you realize:

“Ohhhh riiiiight, yeah this would never work.”

It is unimaginably valuable to get a shortcut to this point. This is where real growth as a human programmer happens.

Net it all out: bugs, bad, and ugly, and I’m seeing a solid 80% increase in working code pushed.

A totally unmeasured, somewhat arbitrarily selected number, and its all relatively greenfield solo projects.

But its an absolutely wild number if even somewhat correct.

Think of all the dead 2012-era SaaS’s out there that would have vested on a measurable 2% productivity gain?

Look, I don’t know if market conditions hold long enough for Moore’s Law to apply to inference cost and context window size.

If it does, we’re frog cooked anyways.

But right now?

Oh shit be wild out here.