My Agents Don't Get to Vibe 🤖

Hey tech adventurers! 👋

I use coding agents a lot. Probably an irresponsible amount.

My current favorite is Grok Build. 🤖❤️

But I don’t want my workflow tied to one agent. Models change, shiny new robots appear, benchmarks go brrrr, and everyone changes their mind by Tuesday. 😂

So my setup is intentionally boring and agent agnostic:

Skills describe the workflow. Hooks enforce it.

Plan before you cook 🏛️

I don’t like giving an agent:

“Build feature X.”

That’s how you get 2,000 lines of beautifully implemented misunderstanding. 🫠

Instead, I use a council skill. Multiple agents independently look at the problem, challenge the architecture, and turn the result into a technical issue.

And I mean technical:

SQL schemas • migrations • structs • types • classes • APIs • files • edge cases • acceptance criteria

If we need a table, put the schema in the issue.

CREATE TABLE pizzas (
    id UUID PRIMARY KEY,
    topping TEXT NOT NULL,
    delicious BOOLEAN NOT NULL DEFAULT true
);

Enter fullscreen mode Exit fullscreen mode

No:

“Build a robust and scalable pizza management solution.”

Ah yes. Robust and scalable. Now I know exactly what to build. 😂

Let the agents argue while changing the architecture is still cheap.

Then let the robot cook 👨‍🍳🤖

Once the issue is sharp, I hand it to the builder.

Right now that’s usually Grok Build.

The architecture is there. The types are there. The acceptance criteria are there.

Go cook. 🍕

After implementation comes autoreview:

review → findings → fix → review

Much better than letting the same robot write the code, review itself, congratulate itself, and ship.

I use variations of this across things I’m building like acpbot.app, gegenlesen.app, and barkvisor.dev.

Different projects. Same little robot factory. 🏭🤖

No receipt, no ship 🧾🚢

This is probably the most useful thing I’ve added lately.

Agents love saying:

Tests pass. Should work. ✅

Should. 🫠

So I stopped asking them to verify.

I enforce proof before they can push.

Each project has a verification skill that knows how to prove the real thing works:

run it • click it • call it • query it • screenshot it • show evidence

Tests are great.

But “tests pass” and “I used the thing and here is proof it works” are not the same thing.

Then a hook enforces it.

No proof?

No push. 🚫🤖

Preflight runs before pushing or opening the PR too.

The robot can be creative while working. When it approaches the exit, we check the luggage. 🛂

That’s basically my loop 🔁

💡 Idea → 🏛️ Council → 📝 Technical issue → 👨‍🍳 Build → 🛡️ Review + fix → 🧾 Verify + proof → 🛂 Preflight → 🚀 PR

That’s it.

I’m not trying to build the perfect mega-agent.

I’m trying to make the process around the agent reliable.

Agents are replaceable. Skills are portable. Hooks keep the minions honest. 🤖

Credit where credit is due 🙌

A lot of this workflow is inspired by Lauren Tan, Peter Steinberger, and Matt Pocock.

Lauren’s work around skills and agent workflows, Peter’s autoreview approach, and Matt’s work around planning, specs, and engineering skills all heavily influenced my setup.

I mostly mixed the parts I liked with my own questionable engineering decisions and added the rule that’s been most useful lately:

No proof? No push. 🧾🚫