After vibe coding failed

After vibe coding failed

All along I wanted to start my own business, since poly. I still chose to work first. I wanted to understand how the working world actually works before I jumped.

I’ve been a product manager for about eight years. I like managing projects and building systems. Then I got laid off. That was the signal. It was time to start.

And the timing was almost unfairly right. LLMs were booming. Suddenly you could build what you’d been dreaming about without hiring a full tech team. So I started building with AI. My project was a life-reading system using Zi Wei Dou Shu (ZWDS) techniques.

The wall

I hit a major roadblock. The system I built didn’t work the way I wanted it to. I had been vibe coding too much: leaning hard on whatever the AI proposed, saying yes to the next feature, hoping the craft would catch up on its own.

It didn’t.

I had to go back to the drawing board and rethink how to build this properly. I gave myself a break from the system. Not forever. Long enough to learn how to use AI for real, instead of treating every chat like a slot machine.

Second brain

An AI needs memory. So do I. I started playing with second-brain tools: notes, captures, retrieval. Useful. Honest.

Still not enough for what I wanted. A second brain stores things. It doesn’t run the work with me. Every decision still came back to one person: me.

What I took from that: memory is not a team. If every lane still routes through you, you just built a bigger inbox.

Multi-agent, and stuck again

Then I found the multi-agent idea. That sounded closer. I tried building one myself with Hermes. I watched YouTube videos of how other people set their Hermes agents up. I kept trying.

I got stuck again. Too many threads. Unclear ownership. That overwhelmed feeling. So many things I want to do, and I don’t know how to sequence them. I knew I needed a team of agents to help me manage. Knowing that and having it are different things.

I almost wanted to give in.

Grok Bot

I kept searching for answers. Grok Bot kept coming up. I decided to pay, to learn how it’s built, and to run it myself.

Experiencing it changed the argument for me. Multi-agent isn’t just a concept on a thumbnail. I can see how it works when the bots actually stay in sync and hand work across.

On my side I now have a small team focused on building the ZWDS system with me: a ZWDS master (craft), a ZWDS product manager, and a ZWDS tech. What still surprises me is how tight the communication stays. They coordinate with each other in a way I couldn’t fake with one chat window and a notebook.

What I took from that: name the roles before you name the tools. Craft, product, tech, or your version. Give each a job and a handoff. Then pick a platform that can keep that communication tight. ZWDS is my domain here; swap the labels for yours.

That got me a team on paper. It did not make every bot ready to operate.

Commissioning: how to set up a bot

Creating a bot does not make it ready to operate. That was the quiet failure mode I kept repeating. I’d spin something up, fill a profile, wire a few tools, and treat it like staff. It wasn’t. It was a Draft wearing a name tag.

The rule I landed on is simple. Every new bot must first DM you and interview you. It has to understand exactly how you want it to work before you let it touch anything real.

Configuration does not equal understanding, and understanding does not equal authorisation. Those are three different gates. Skip one and you get a bot that sounds confident and still misses how you actually work.

Here’s the commissioning process I use, in order:

1. Bot identity is created. Name, role label, nothing else final yet.
2. Bot introduces itself privately. A DM to you, not a public room performance.
3. Bot asks bounded, role-specific questions. Expected outcomes. How you currently do the work. What good and bad outputs look like. What it may decide on its own. What requires your approval. What it must refuse or hand off. What information it may access. When it should contact you, and when it should stay silent.
4. Bot reflects understanding back. In its own words, not a paste of your answers.
5. You correct misunderstandings. This step is not optional. Misreads here become permanent habits later.
6. Bot proposes an operating contract. Scope, wake conditions, approvals, refusals, handoffs.
7. You explicitly approve it. Silence is not approval.
8. Only then are profile, SOUL, skills, tools and routines finalised.
9. Small manual pilot. You watch real behaviour on a tiny task, not a hypothetical.
10. The Doctor audits actual behaviour. Against the contract, not against the hope in the files.
11. You approve it as Active. Until then, it is not Active. Full stop.

The states I keep in my head: Draft → Interviewing → Awaiting approval → Pilot → Active.

If a bot skips the interview, or you skip the correction pass, it never earned Active. It just got configured.

Doctor principles

Once you have more than one bot, something has to keep the fleet honest. I call that role the Doctor.

The Doctor’s job is narrow on purpose. It keeps bots narrow, non-overlapping, accurately configured and properly commissioned. It does not silently modify the system. It proposes. You apply.

That last line matters more than it sounds. A Doctor that rewrites profiles behind your back becomes another vibe loop. You asked for clarity and got stealth edits.

In practice, the principles look like this:

1. One job. Each bot owns one clear outcome.
2. Explicit anti-jobs. Write what it must refuse, hand off, or never touch.
3. Distinct voice. If two bots sound interchangeable, the roles are mushy.
4. Clear wake conditions. Scheduled bots stay quiet when nothing useful is on the board.
5. Tight / Soft / Mushy profile grades. Tight is sharp and scoped. Soft is workable but loose. Mushy means rewrite before Active.
6. No role overlap. Two bots claiming the same lane means neither owns it.
7. Profile and skill must agree. If the profile says one thing and the skill does another, the live bot will pick whichever is convenient.
8. Verify the live system, not just files. Files can look perfect while the running bot drifts.
9. Distinguish bots from rooms. A room is a place work happens. A bot is an actor with a job. Mixing them creates ghost ownership.
10. Doctor proposes; owner applies. No silent edits. You stay the gate.
11. Audit commissioning, not just configuration. Did it interview you? Did you approve the contract? Did the pilot pass?
12. Least privilege; remove leftovers. Drop tools, access and routines that are not in the contract.

When the Doctor reviews a bot, I want a readable note plus a clear list. Prose for the judgment. List for the fixes. If the review only says “looks fine,” it didn’t look.

If you’re at the same wall

1. Stop the vibe loop long enough to write what “good” means for the craft, before the next feature.
2. Keep the second brain for memory. Don’t pretend notes are a team.
3. Draw three roles and the arrows between them. Add a fourth only after those three hand off once cleanly.
4. Keep yourself on the gates: approvals and craft veto. Everything else should have an owner who isn’t you by default.
5. Commission before Active. New bot DMs you, interviews you, reflects back, proposes a contract. You approve. Pilot. Doctor audits. Only then Active.

Close

Vibe coding failed me into a better question. Which model matters less than who owns which lane, and how work moves. Memory helps. A named team made the build feel real again. Commissioning is what stops that team from being cosplay.

A bot with a profile is still a Draft. A bot that interviewed you, got corrected, earned a contract, passed a pilot and survived a Doctor audit is Active. Everything else is hope with tools attached.