The Hamster Method

A ticket says “implement dark mode.” A brief explains why users need it, what constraints exist, how it should behave, and what done looks like.

Tickets are placeholders for future conversation. Briefs are the conversation — captured once, referenced forever.

The Hamster way is to align and approve on a brief before any work begins. The brief becomes the definition of ready and the definition of done. Once approved, the tasks lock in — whether they're flowing to a human engineer or an agentic workflow.

This is the unlock. When coding agents became capable of real work, we discovered that the specs that work for AI are the same specs that work for humans. Both need context. Both need clear acceptance criteria. Both fail when requirements are ambiguous. The difference is that AI fails loudly and immediately. Humans fail quietly over weeks.

An approved brief isn't just documentation. It's a contract. The team has agreed: this is what we're building, this is what done looks like, these are the tasks required to get there. No scope drift. No mid-flight reinterpretation. The brief is the source of truth, and the work flows from it.

Every tool makes creating work easy. Few make approving work meaningful.

The hard problem in 2026 isn't getting AI to write code. It's orchestration — coordinating what gets built, in what order, by whom or what, and making sure it all fits together. When half your output comes from autonomous agents, approval becomes the orchestration primitive. Someone needs to validate that the brief is correct before an agent spins up and writes a thousand lines of code. Someone needs to verify that the output matches the intent.

Approval in Hamster isn't a gate or a meeting. It's a visible commitment. You're not asking for permission — you're asking for partnership. Someone else looks at your brief and says: “Yes, this is ready. I'll share accountability for what happens next.”

This only works in teams. Solo operators can use Hamster, but the method requires at least two people: one to propose, one to approve. That's the minimum viable structure for reliable orchestration when execution is automated.

Approval catches problems before they become expensive. It's faster to fix a brief than to fix a pull request. It's faster to align on intent than to argue about implementation. And it's the only way to keep humans in control when the agents are doing the building.

Coding agents are only as good as their context. Feed an agent a brief with no codebase awareness, no design references, no understanding of existing patterns — and you'll get code that compiles but doesn't fit.

Most teams treat context as something that lives in people's heads. It leaks out during meetings, gets repeated in Slack, and evaporates when someone leaves.

The Hamster Method treats context as infrastructure. Your codebase, your documentation, your past decisions, your design files — all of it should be connected, searchable, and available to whoever (or whatever) needs it.

When you write a brief in Hamster, it automatically links to relevant context: related briefs, connected code, referenced docs. When an agent picks up that brief, it sees the full picture. When a human reviews the output, they can trace exactly what inputs produced it.

Build your context graph deliberately. Every brief you write, every decision you document, every connection you make — it compounds. Six months from now, your agents will be dramatically more effective because they'll have six months of structured context to draw from.

The goal isn't to remove humans from the loop. The goal is to move humans to where they add the most value.

Humans are good at judgment: deciding what to build, why it matters, whether the output is correct. Humans are expensive at execution: writing boilerplate, implementing specs, grinding through routine work.

AI is good at execution: fast, tireless, consistent (within its context). AI is unreliable at judgment: it will confidently build the wrong thing if you let it.

The Hamster Method keeps humans in control of decisions and lets AI handle execution. You write the brief. You approve it. An agent builds it. You review the result. The human judgment happens at the beginning and end — the expensive middle is automated.

This isn't about trusting AI less. It's about using each capability where it's strongest.

Here's the paradox: the clearer you write for machines, the easier it is for humans to review.

A brief that's detailed enough for a coding agent to execute is also detailed enough for a teammate to validate. There's no ambiguity to argue about. The acceptance criteria are explicit. The constraints are documented.

Most review cycles are slow because the reviewer has to reconstruct context and infer intent. When the brief is complete, review becomes verification: does the output match the spec?

Write briefs like you're handing them to a capable but literal-minded contractor who won't ask clarifying questions. That's what a coding agent is. It's also, honestly, what most async collaboration is.

Coding agents make it easy to generate a lot of code quickly. This is a trap.

The same discipline that makes human teams effective applies to AI-assisted teams: small scopes, frequent shipping, fast feedback. A brief that takes an agent thirty minutes to execute is better than a brief that takes three hours — not because time matters, but because smaller scopes mean faster learning.

Break work into pieces that can be reviewed in one sitting. Ship increments that can be validated independently. Treat each brief as a bet you're testing, not a commitment you're locked into.

The speed advantage of AI isn't that you can build bigger things. It's that you can iterate faster on smaller things.

The most valuable artifact isn't the code — it's the record of why the code exists.

Every brief in Hamster captures intent. Every approval captures agreement. Every execution captures outcome. Over time, you build a searchable history of product decisions: what was built, why, by whom, and how it went.

When something breaks, you can trace it back to the brief. When a stakeholder asks why you built something, the answer is documented. When a new team member joins, they can read the history instead of scheduling archaeology meetings.

This visibility is expensive to create manually. In Hamster, it's automatic. The brief is the spec, the approval is the sign-off, the agent's output is the implementation. The record assembles itself.

In the old model, quality depended on individual diligence. Careful engineers caught bugs. Thorough PMs wrote good specs. When people were tired or rushed, quality dropped.

The Hamster Method makes quality systematic. Briefs enforce clarity at the start. Approval enforces review before execution. Context ensures agents have what they need. The output is traceable to its inputs.

This doesn't mean quality is automatic — you still need good judgment about what to build and how to evaluate results. But the system catches the routine failures: the unclear spec, the missing context, the unchecked output.

Build the system. Trust the system. Improve the system when it fails.