AI Vibe Coding Harness Framework: Run Claude Code on a Budget

The problem with vibe coding at scale

Hand an AI agent “build me an app” in one go and it moves fast at first. But as the conversation grows, the agent forgets the rules you set, reshapes the folder structure on its own and piles up code without tests. Part of the cause is that every earlier trial and error keeps accumulating in a single session’s context.

What is a harness framework?

A harness is a device that keeps the agent on a fixed path. It is not a prompt-writing trick but a way of designing the environment and procedurethe agent works in — which is why it is also called “harness engineering.” It comes down to five things.

1. Docs are the source of truth — write the PRD, architecture, technical decisions (ADR) and rules (AGENTS.md) first.
2. Plans broken into small pieces — /harness reads the docs and splits the work into step instructions (phases/{phase}/step{N}.md). A human reviews and approves them.
3. A fresh session per step — scripts/execute.py opens a new Claude session for each step, injects the rule docs every time and passes along only summaries of previous steps, so the context never gets polluted.
4. Self-verification — each step must pass an executable completion check (e.g. npm run check). On failure the error is fed back for up to 3 fix attempts.
5. Safety nets — hooks block dangerous commands and implementations without tests, and /review does one more pass at the end.

The harness workflow

Write docs (PRD · ARCHITECTURE · ADR · specs)
   ↓
/harness ── generate step plan → human approves
   ↓
execute.py ── new session per step: implement → verify → commit
   ↓
/review ── detect & fix rule violations
   ↓
Human tests manually via milestone checklist → PR

The human writes the docs, approves the step plan and tests at the end of each milestone. In between, the harness repeats implement → verify → commit one step at a time.

The hidden cost of a harness: tokens

A harness opens a new session for every step, and each one reads the full rule docs. You get a clean context, but tokens melt. Claude subscriptions have 5-hour and weekly usage limits, so kicking off a phase before bed tends to go like this:

1. Kick off a phase at night and go to sleep.
2. At 3 a.m. the usage limit hits and the step ends as a failure.
3. Wake up, discover it, and wait for the reset all over again.
4. Manually hit “continue.”

A harness for the poor: harness_framework_poor

So instead of paying for extra usage, I (the person behind BitKitTools) built a harness that does the waiting, too. The name is honest: harness_framework_poor. You pay in time instead of money.

⏳ Auto-wait & resume on usage limits

• Runs claude -p with stream-json to check the 5-hour and weekly usage plus reset times on every call.
• At 95% usage or higher it won’t start a new step — it waits until the reset time, then starts on its own.
• If a step is cut off mid-run by the limit, it doesn’t count as a failure. After the reset it uses --resume to continue the same session with its context intact.
• Change the threshold with e.g. --limit-threshold 0.9. On Windows it keeps the PC from sleeping while it waits.

py -3 scripts/execute.py m0-foundation                         # Windows
python3 scripts/execute.py m0-foundation                       # macOS / Linux
py -3 scripts/execute.py m0-foundation --limit-threshold 0.9   # stop earlier

📚 A documentation system that cuts rework

Saving tokens teaches you that getting it right the first time is the cheapest option, so the docs were strengthened.

• docs/progress.md — milestone checklist and a pending-decisions (blockers) table. One checklist item = one step = one commit
• docs/milestone-checklist.md — tests a human runs by hand when a milestone is done
• docs/specs/ — per-system specs; no code before a spec. Only the specs a step needs are injected, to save tokens.
• docs/tech-debt-tracker.md— agents don’t read git log, so known debt is recorded here and passed to every step

🧭 Stronger /harness and /review

• /harness— splits steps by checklist item, keeps the layer order (pure logic & tests → server → client → E2E) and asks first when a spec is missing or a decision is open.
• /review — replaces the eyeball checklist with grep-based detection of any types, layer violations, exposed secrets and missing tests, looping until violations reach zero.

Compared with the original harness

The whole skeleton comes from the original jha0313/harness_framework; the poor version adds budget-friendly features and stronger docs and commands on top.

This site was built with a harness

BitKitTools was built by running 18 phases and 72 steps through a harness between July 3 and August 7, 2026 — from the foundation to 16 tools such as the JSON Formatter and JWT Decoder, deployment automation, and GA4 / Search Console / Clarity data collection with automated weekly reports. The token problems hit along the way are why harness_framework_poor exists.

Quick start

You need the Claude Code CLI, Python 3.10+, Node 20+, git and bash (Git for Windows on Windows).

1. Copy the repository files into a new project folder, run git init and make the first commit.
2. Fill in the { } parts of AGENTS.md, docs/PRD.md, docs/ARCHITECTURE.md and docs/ADR.md.
3. Write a milestone checklist in docs/progress.md and the first milestone spec in docs/specs/.
4. Run /harness in Claude Code, then review and approve the step plan.
5. Run execute.py and go to sleep. When you wake up: /review → test by hand with the milestone checklist → PR.

Before you use it

• Step sessions run with --dangerously-skip-permissions (file edits and commands without permission prompts). Use it only in a repository you trust and keep the hooks on.
• Auto-wait works off Claude subscription usage. With a pay-as-you-go API key you get a bill instead of a limit, so it doesn’t apply.
• If you burn through the weekly limit you may wait for days. Closing the laptop lid defeats the sleep prevention, so keep it plugged in.