Claw Coding for Beginners

How to delegate software work to an AI agent without building slop.

Vibe coding helped people build by feel.

You can sit in Cursor, VS Code, Claude Code, Codex, etc., describe what you want, react to what appears, and nudge the result until it looks kinda close to whatever is in your head.

That bar continues to be lowered. You don’t need a code editor to be functional anymore. Just as the step down from coding was vibe coding, the step down from that is claw coding.

Claw coding is different because now the real work is delegation. You are giving an AI agent a software job and letting it go do pieces of the work.

That sounds great until you ask for too much and it proudly hands you a pile of shiny nonsense.

Claw coding enters the ring.

Claw coding is delegating software work to an agent that can act.

It can create files, edit files, run commands, inspect errors, and report back with findings. You never open an IDE and rarely sign up on your own for any sort of services.

But please, don’t be fooled. This is not magic. It’s very easy to screw it up. And if you don’t understand anything about what you’re doing, you don’t know where it screwed up until the end. So let’s change that.

If you want to be successful as a beginner, you don’t need to understand code. You need to understand fundamentals. You need to give the agent one clear job, make it stop, make it show what changed, and then decide on the next step.

Otherwise you will get slop.

Slop is what happens when the agent builds more than it understands.

When it starts guessing what you want. When you, as the Pragmatic Programmer describes, “outrun your headlights”.

For beginner coding agents, slop becomes

• fake buttons

• extra screens nobody asked for

• dashboard before the first workflow works

• confusing setup steps

• files you and the agent don’t understand

• “done” messages with no receipts

• a pretty app that doesn’t actually do the thing you wanted it to do

This is not because you or the agent are dumb. It’s because what you’ve asked for is a vague idea. Vague assignments create vague software.

There is too much slop on the internet.

Please don’t contribute to it.

My goal here is not to sound preachy. You may be thinking “but who cares if my to do list app is slop?”. You will. Eventually.

Eventually buttons will break, scope will explode, and neither you nor your agent will have the first idea how to fix it. God forbid you ever try to sell it and get users for it.

Do not let your agent build until both you and your agent can explain what you are building, why it matters, and how you will know it worked.

Before your agent touches anything, you should answer

• Who is this for? (me or the public)

• What problem are we solving first?

• What is the smallest version I can make to test?

• What are we ignoring for now?

• What should I be able to test when this step works?

The practical guide on getting started

When you sit down and pull up Telegram or Discord, you should start by having a conversation with your agent.

Describe your idea in normal words. Make sure you and your agent are using the same words. You should share a vocabulary. If you don’t know how to code, make your agent explains thing to you in a different way.

Next, make your agent ask you questions. Agents in general are really good at being sycophants, and will happily go along with whatever plan you lay out, regardless of whether or not the plan is any good.

Then, shrink the idea to on useful first version. This is called a minimum viable product. If it doesn’t hurt to make this, your idea isn’t any good.

Now, approve one tiny build step. Lay the foundation before you try to build the house. Where is your thing going to be hosted? How are you going to get to it? It needs to be written down somewhere.

Make your agent show receipts. This is how you steer away from hallucination or going down a rabbit hole you don’t want to chase. The agent should always be able to show it’s work.

Test it for yourself. Does the page come up? Is there a button? When you click it, what happens?

Finally, decide the next tiny step. You have to lay the railroad one stake a time here. Otherwise, you will end up in slopsville.

The big takeaway here is don’t say “Build my app”. Start with “Help me turn this idea into the smallest useful first version. Ask me one question at a time until we both understand the plan.”

The No Slop Skill Pack

I’ve created some skills that have been useful for me and I’m hoping they’ll be useful for you too. If you don’t know how to make a skill, just tell your agent you want to make one. They should know how. They are just simple markdown files.

I’ve named the first one /say-the-thing, but feel free to rename as you want.

/say-the-thing

You are helping me explain my idea clearly before we build anything.

Do not build yet.

Ask me one simple question at a time.

Your job is to help me say:
- who this is for
- what annoying problem it solves
- what the person does today without this
- what the first useful version should do
- what would be too much for version one

Keep your questions plain. No coding words unless you explain them.
Do not stop until all questions are answered enough to start a PRD. 

You should use this first skill when you’re getting a plan together with your agent. This will get you and your agent speaking the same language.

Next is /useful-thing . This one is helps me keep that alignment that the first skill starts.

Take my idea and find the first useful thing we should build.

Do not pick the most impressive thing.

Pick the smallest thing that would make someone say, “Okay, that helps.”

Give me:
- the first user
- the first job this should help with
- the first screen or action
- what we should ignore for now
- what I should be able to test when it works

If I am asking for too much, say so plainly.

Okay. now you and your agent should be on the same page. The next most important skill to run is /no-fake-buttons

Before you build or continue, follow the no-fake-buttons rule.

Anything visible should either:
- work,
- clearly say it is a placeholder,
- or not be shown yet.

Do not create buttons, menus, forms, dashboards, settings, or links that look real but do nothing.

If you want to add something unfinished, ask me first.

The next one I use is /one-brick. This will help you start the build process. You will run this skill many, many times, depending on how thorough you are.

Build the first or next smallest piece of our app or idea.

For this step:
- change as little as possible
- do not add extra features
- do not redesign unrelated parts
- stop when this one piece works
- tell me exactly what changed
- tell me how I can test it

Wait for my approval before starting the next piece.

Following my order, the next step is /show-your-work. Even if you can’t understand everything the agent is doing, forcing it show it’s work often creates better code than not. Just like when you skipped math class in school.

Before we continue, show me the work.

Explain in plain English:
- what you changed
- why you changed it
- what works now
- what does not work yet
- how I can test it
- what you recommend next

Do not continue building until I approve.

The next one is to make sure your agent doesn’t go crazy polishing things that aren’t going to last through your mvp anyway.

For this version, make it usable before making it pretty.

Focus on:
- the main action working
- clear labels
- simple navigation
- obvious next steps
- no fake features

Avoid:
- fancy animations
- dashboards we do not need
- extra settings
- placeholder sections
- visual polish that hides broken behavior

After you have the first section built, you need to debug. If you do not know what debugging means, run this skill.

Before I trust this, tell me where it might break.

Look for:
- confusing user steps
- missing error messages
- data that might not save
- buttons or forms that might fail
- setup steps I might not understand
- anything that only works in the happy path

Give me the top 3 risks in plain English and the smallest fix for each.

And then finally, when you come to a stopping point (ideally at the end of each /one-brick session), have your agent stop and clean up. A clean workspace is important and keeps you both sane.

Stop building and clean up the current state.

Do not add new features.

Tell me:
- what files or parts matter
- what can be removed
- what is unfinished
- what is safe to leave alone
- what the next smallest useful step should be

If there are fake or unused pieces, ask before deleting them.

This will get you on the way to building your first thing that is not actually slop.

You should also find Matt Pocock.

His work has helped me a ton and has inspired this essay.

I’ve been poking around Matt Pocock’s excellent skills repo, especially his /grill-me skill, which tells an agent to interrogate a plan before building. His version is aimed at engineers, but the beginner lesson is huge. Agents do better when you give them reusable behaviors, not vague wishes.

Coding is becoming delegation.

Claw coding is delegation. Delegation gets better when the job is smaller, clearer, and easier to inspect.

You do not need to become a developer overnight. You do need to stop handing the agent a giant dream and expecting it to return a clean product.

Make it ask.

Make it shrink.

Make it build one piece.

Make it show the work.

Then decide what comes next.

Until tomorrow,

Robby