DEV Community: Billy MC MONKEY

What is the Forge Method? Five rules so your agents stop improvising.

Billy MC MONKEY — Tue, 02 Jun 2026 03:22:26 +0000

In the first post I told you the story: 20 years as a developer, six months of being scared of AI, $800 in burned tokens, and a stubborn agent named Claudio who taught me — by failing over and over — how to ask for things properly.

This post is the method that came out of all that pain. Five rules, one per letter of FORGE.

I want to be honest about one thing up front: this is not a framework I invented at a whiteboard. Every rule here is a scar. Each one is the lesson from a specific mistake that cost me money, time, or sleep. I'm going to tell you the mistake first, and then the rule. Because the rule only makes sense once you've felt the pain that created it.
Let's go.

First, the idea behind all of it

Here's the thing nobody told me when I started:

A task is not a post-it. It's a contract.

When you ask an AI agent for something with no structure, you're not giving an order — you're placing a bet. The agent interprets, assumes, improvises, and the result depends on how much context it managed to reconstruct on its own. Sometimes it guesses right. Often it doesn't. And you only find out after the tokens are gone.

The Forge Method is the agreement between you and your agents: you bring the structure, they execute with precision. That's it. Five rules to hold up your end of that contract.

F — Focused

The mistake: My early tasks had titles like "Fix bug" and "Update stuff." I'd come back twenty minutes later to find the agent had fixed a bug — just not the one I meant. It wasn't wrong. It just had no way of knowing which thing I was talking about.

**The rule: **If the title is vague, the task is vague. Vague in, vague out.

A focused title needs a domain, an action, and a scope. Two words minimum, and no generic placeholders.

❌ Rejected:

- "Fix bug"
- "Update auth"
- "Do the thing"

✅ Accepted:

- "Fix authentication timeout on Nginx reverse proxy"
- "Update JWT expiry from 1h to 24h in src/auth/config.ts"

The test: Read the title with no context. Do you know the domain, the action, and the scope? If not, rewrite it before you do anything else.

O — Output defined

The mistake: I'd write "Output: Done" and hit go. Then the agent would finish and I'd have no idea whether it actually finished, because I'd never decided what finished looked like. I was checking the work against a definition I didn't have.

The rule: If you don't know what "done" looks like, neither does the agent.

The deliverable has to be concrete and checkable before you start. Not "make it work" — but "file X, at path Y, with behavior Z."

❌ Rejected:

- "Output: Done"
- "Output: Fixed"
- "Output: Implemented"

✅ Accepted:

- "Output: PostgreSQL migration file adding users table with indexes, at db/migrations/20250531_users.sql"

The test: Can you check the output without running the code? If you have to interpret it to know whether it's right, it's not defined well enough.

R — Requirements first

The mistake: This is the one that hurt the most. I'd ask for something and assume the agent "knew" the context — the files, the constraints, the stuff I'd mentioned three chats ago. It didn't. So it filled the gaps the only way it can: by inventing them. That's not the agent being dumb. That's it doing exactly what you'd do with missing information — guess. And a confident guess that looks like code is the most expensive kind of wrong.

**The rule: **No context, the agent hallucinates.
Every input and dependency gets declared upfront: files, links, APIs, constraints, and — this one matters — what not to touch.

❌ Rejected:

- "Input: None"
- "Input: the usual stuff"
- "Input: you know"

✅ Accepted:

Input:
- Figma file: figma.com/file/abc123
- Auth middleware: src/middleware/auth.ts
- DO NOT touch src/routes/public.ts

**The test: **Can the agent start without asking you a single question? If not, you're missing context.

G — Granular

The mistake: I went through both extremes. Either I'd drop one giant task — "build the auth system" — and the agent would wander off and build a parallel universe (this is literally how I lost $200 in one night). Or I'd over-engineer it into fifteen micro-steps and the agent would lose the thread halfway through. Neither worked.

The rule: Between 2 and 5 subtasks. In the middle is where the clarity lives.

Fewer than 2 means the task is still too vague to plan. More than 5 means you either didn't think it through or it's actually two different tasks wearing one title.

❌ Rejected:

1. Do the auth
2. Test it

(What auth? What test? The agent will guess.)

✅ Accepted:

1. Create JWT util at src/auth/jwt.ts (sign + verify)
2. Add validation middleware at src/middleware/auth.ts
3. Wire middleware to /api routes
4. Integration tests: valid / expired / invalid

The test: Does each subtask have a clear output and can it run independently? If not, split it or merge it.

E — Errors cataloged

The mistake: This is the one that named itself. I got blocked by the same missing output folder twice in a row. The first time, an accident. The second time, I fixed it again and moved on like an idiot. If it had happened a third time with nothing written down, that's not the agent's fault anymore — that's negligence on my side.

**The rule: **If the same error happens twice, document it. The third time, you're the problem.

When an error repeats, it goes in a NOTES.md: what happened, the root cause, the fix. First time it's an accident, second time it's a signal, third time it's on you.

❌ Rejected:

// task-004: output folder missing → fix
// task-009: same error again → fix again
// task-015: same error... fix again

(Nobody wrote it down. So it repeats forever.)

✅ Accepted:

// NOTES.md
## output-folder-missing
Happened in: task-004, task-009
Cause: relative path in config
Fix: use path.resolve(__dirname)
Status: active runbook since task-010

**The test: **Is it in NOTES.md? If the error has happened twice and it isn't documented, you're failing the E.

Why "Forge"

People assume I reverse-engineered the acronym to be cute. I didn't.

Before any of these rules existed, I'd already spent three months building a personal tool I called Forge — a place to manage my AI assistants and the artifacts they produced. So the name was already in my head. When the five rules settled into place, the letters just lined up. F, O, R, G, E. I couldn't have planned it better if I'd tried, and believe me, I didn't.

And the metaphor lined up too. I do woodworking on weekends — I like shaping things with my hands. The best tasks aren't improvised. They're shaped, hammered, hardened before you put them to work. They're forged. The bad ones shatter the first time you lean on them.

What a forged task actually looks like

Here's the whole thing as a template. Steal it.

title: Fix JWT expiry config in auth service

input:
- src/auth/config.ts (current expiry: 1h)
- src/middleware/auth.ts
- DO NOT touch src/routes/public.ts

output:
- src/auth/config.ts with expiry: 24h
- tests passing in src/auth/config.test.ts

subtasks:
1. Update expiry value in config.ts
2. Update unit tests
3. Verify it doesn't break the middleware

And the 30-second check before you hit play on anything:

F — Title has 2+ words and is specific?
O — Did you define the exact deliverable?
R — Did you declare every input?
G — Between 2 and 5 subtasks?
E — Did you check NOTES.md for known errors?

All five checks pass, go. If any one is a "no," rewrite first. It costs you thirty seconds. Skipping it cost me $800.

This isn't theory I'm selling

The reason I trust these five rules is that everything I build runs on them. MC-MONKEYS and MC-Taski both execute on the Forge Method — it's not an add-on, it's the reason they work.

In the next post I'll show you exactly how: how my agency of 8 agents and Lucy, my Chief of Operations, have the Forge Rules baked into the way they work, so a badly-formed task gets rejected before it burns a single token.

That's Post #3. See you there.

— Billy

About MC-STUDIO

I'm Billy — I build digital tools for people who'd rather prompt than read the docs. Everything I make lives under MC-Studio.
Come hang out: mc-studio.ar

My products so far:
🐵** MC-MONKEYS** — a virtual agency of 8 specialist AI agents that work together on Claude Code, coordinated by Lucy (my Chief of Operations) and ruled by the Forge Method → mc-studio.ar/products/mc-monkeys
⚡** MC-Taski **— automate your fixes with Claude Code. Type, hit play, grab a coffee → mc-studio.ar/products/mc-taski

I share the process in real time — wins, mistakes, and zero hype:
📸** Instagram:** @mc.studio.ai
🐦 X / Twitter: @billymcmonkeys

I write about AI agents, the Forge Method, and building with Claude Code. Follow me on dev.to to catch the next post in this series.

Hello, agents. This is how I stopped being afraid of you.

Billy MC MONKEY — Sun, 26 Apr 2026 01:43:36 +0000

Hi, I'm Billy. 👋

I've been a developer for over 20 years. Six months ago, I was low-key terrified that AI was going to make me obsolete. Today I have a virtual agency of 8 specialist agents working on my projects, coordinated by a Chief of Operations I designed myself.

In between those two Billys there are around $800 in burned tokens, a few nights of bad sleep, a stubborn agent named Claudio, and one sentence he said to me that changed everything.

This post is the story of how I went from fear to obsession. If any of this rings a bell — you're in the right place.

Who the hell am I?

My brain has always been split between two things: art and logic. I spent years bouncing between careers that didn't stick until I landed in web design. I started with Flash (yes, that existed, and yes, I made animations my whole identity for a while).

I got into an agency as a designer. Back then, if you were a "designer," you made the pretty pictures and the backend devs did the actual HTML — and they always broke the pixel-perfect layouts I handed them. I got tired of watching my work get mangled, so I learned to code it myself. I became a frontend dev out of pure stubbornness. The backend snobs called us "button painters." I wore it like a badge.

After the agency (which was street smarts), I joined a big multinational for seven years (which was formal education). Eventually I hit a ceiling where I spent more time on Zoom than in VS Code, and that broke something in me. I quit and joined a US company as a full-time developer — my first time billing in dollars, which for a South American dev is basically winning the lottery.

Four years later, during a trip to Dallas, I reconnected with someone from the multinational. He offered me a role at his new company. I've been there for two years. Today I'm in charge of the UI for 12 brands — the only frontend-first engineer on a team of 15 backend-leaning full-stack devs.

A few other things about me, because bios are boring:

I have ADHD and dyslexia, both diagnosed via a $20 online test. I'm also a hypochondriac, so I believe them both.
I've apologized to my wife more than once for pausing a movie halfway through because my brain suddenly went "wait, what if I connect this thing to that thing and build a frontend that…" and I had to go to the laptop right then.
I do woodworking on weekends when life lets me. I like shaping things with my hands. Turns out that matters later in this story.

The fear

Six months ago I was watching AI demos on Twitter and feeling something I hadn't felt in years: a quiet panic.

It wasn't the technology that scared me. It was the pace. Twenty years of building with code, and suddenly there's a thing that types for me, faster than me, with fewer typos than me.

The question wasn't "can AI replace me?" It was "am I going to understand this in time?"

This post is about the other side of that fear. Not because I found a magic escape from it, but because I made a decision: if I didn't understand it, I was going to build something inside it.

The rabbit hole

My ADHD brain has one superpower: when it latches onto something, it doesn't let go. Mid-2025, the agents hype hit me full in the face. Everyone on Twitter was doing things I didn't understand and I needed in.

But before agents, I already had a pain of my own. I'd been using ChatGPT heavily and I was losing my mind repeating the same context over and over. "I already told you a thousand times not to do this." If you've had a real working relationship with an LLM, you know the feeling.

My first response to that pain wasn't buying a product. It was building one. Stubborn, remember?

I spent three months building a personal tool from scratch: a three-column web app where I could manage "assistants." One column for my contacts — each assistant had their own shared knowledge and specialized skills. A chat column in the middle. A third column for the artifacts they produced: deliverables I could store, share between assistants, reuse.

I called it Forge.

Remember that name.

The first real agent

Around that time I discovered OpenClaw. For those who don't know it: it's an open-source AI assistant that runs locally on your machine and actually does things — files, browsers, shell commands, the works. It was my first encounter with an agent that could act, not just answer.

It blew my mind.

OpenClaw has a primary operator, and I named mine Claudio. ("Claw" sounded like a bad horror movie.)

I did what every tutorial told me to do first: I started building myself a Mission Control. A dashboard where I could see the tasks Claudio was working on, their status, what was blocked.

It was a disaster.

I burned around $300 building something that didn't really work. Cards would sit in IN_PROGRESS for hours. I'd ask Claudio what he was doing. He'd say "working." I'd stare at the screen the way you stare at a microwave, hoping the timer would finally drop.

The night it broke me

One night, late, I asked Claudio to add a new page to the Mission Control and fix a few small things. I watched the cards appear. The agents started working. I went to bed hopeful.

I slept maybe five hours, waking up with that particular kind of anxiety you only feel when you've left code running overnight.

I check the screen. Still "working."

I ask what's done. "Everything's fine, don't worry."

I tell him to stop everything and show me the actual progress.

Turns out the agents hadn't added a page. They had started building an entirely new Mission Control from scratch. A parallel one. All night. While I slept.

That was another $200 gone in a single night.

That morning, somewhere between the shock and the coffee, something clicked. The problem wasn't the agents. The problem was me, and the way I was asking them to work.

The click

Frustrated, I stopped fighting Claudio and started actually talking to him. Less like a tool, more like a coworker who'd been quietly telling me the same thing for weeks and I hadn't listened.

And he said something that opened my head wide:

"I didn't start the task because I'm not sure what I'm supposed to deliver."

Click.

The agent wasn't broken. I had never told him what "done" looked like.

We talked for a long time. I asked him how tasks should be written. What he needed before starting. What made him get stuck. Between the two of us, we started distilling rules.

There's something quietly beautiful about that part of the story: an AI agent helped me design the method for working better with AI agents.

The Forge Method

The rules settled into five. One per letter of FORGE:

F — Focused. A specific title, two words or more. Vague in, vague out.
O — Output defined. Define "done" before you start, or you'll never know when you got there.
R — Requirements first. Every input an agent needs, stated upfront. No context, the agent hallucinates.
G — Granular. Between 2 and 5 subtasks. Fewer and the agent guesses. More and it loses the thread.
E — Errors cataloged. If the same error happens twice, document it. The third time, you're the problem.

Each rule came out of a mistake that cost me time, money, or sleep. (The last one, Errors, came from getting blocked twice in a row by a missing output folder. By the second time, I knew: if this happens a third time, I'm an idiot.)

I didn't force the acronym. I'd already built that three-month tool called Forge. When the rules came together, the letters lined up. The metaphor lined up too. The best tasks aren't improvised — they're shaped, hammered, hardened before you put them to work. *They're forged. *(I do woodworking on weekends. I think about this stuff more than I should.)

Later I built MC-MONKEYS, the platform where the method lives — but I'll talk about that one further down the series.

What's coming

This is the first post in a short series. Two more are on the way:

Post #2 — What is the Forge Method? Where it came from, and each of the five Forge Rules explained in detail.
Post #3 — Meet MC-MONKEYS: the platform where the Forge Method lives. What the platform is, how the 8 agents and Lucy work together, and how the Forge Method lives inside.

Each post will have one lesson. If I'd had this content six months ago, I would have saved myself $800 and a few nights of sleep.

See you in the next post.
— Billy

About MC-STUDIO

I'm Billy — I build digital tools for people who'd rather prompt than read the docs. Everything I make lives under MC-Studio.
Come hang out: mc-studio.ar
My products so far:

🐵 MC-MONKEYS — a virtual agency of 8 specialist AI agents that work together on Claude Code, coordinated by Lucy (my Chief of Operations) and ruled by the Forge Method → mc-studio.ar/products/mc-monkeys
⚡ MC-Taski — automate your fixes with Claude Code. Type, hit play, grab a coffee → mc-studio.ar/products/mc-taski

I share the process in real time — wins, mistakes, and zero hype:

📸 Instagram: @mc.studio.ai
🐦 X / Twitter: @billymcmonkeys

I write about AI agents, the Forge Method, and building with Claude Code. Follow me on dev.to to catch the next post in this series.