Skip to main content
Vibe GuidePart 05

Transmission 05 / 06  //  AUTOMATE

Your Autonomous Twin

NanoClaw + PicoClaw as an always-on PM, bug fixer, feature-brancher, and tester that works while you sleep.

The Vibe Guide, Part 5 of 6 — NanoClaw and PicoClaw as your always-on PM, bug fixer, and test engineer

The Maintenance Problem Nobody Vibe-Codes Their Way Out Of

Parts 2–4 got you a shipped, engineered, deployed app. Congratulations — you now own software, which means you own its future: the issue triage, the dependency bumps, the "it's broken on Android" reports, the small feature requests that are each twenty minutes of work and collectively a part-time job.

Interactive AI (Quests, Claude Code) multiplies you while you're at the keyboard. This part is about the layer that works when you're not: autonomous agents that run continuously, pick up work, do it in isolation, and hand you results for review. The vibes twin. Except it's real, it's open source, and it fits in surprisingly little code.

Meet the Claws

Both emerged in early 2026 as deliberately small, security-first alternatives to sprawling monolithic agent frameworks. The philosophy matches everything in this series: open source, auditable, yours.

NanoClaw — the container-native orchestrator

  • Built on Anthropic's Claude Agent SDK — the same agentic engine as Claude Code, so your CLAUDE.md conventions transfer directly.
  • The orchestrator is roughly 500 lines of TypeScript. You can read the entire thing in a sitting. For something with commit access to your repos, "I have personally read all of it" is not a small feature — it's the whole point.
  • Every agent runs in an isolated Linux container (Docker, or Apple Container on macOS). An agent working on a bugfix has that workspace and nothing else. Blast radius: one container.
  • Messaging-native: built-in WhatsApp support out of the box — your PM channel to the agent is a chat thread on your phone.
  • Persistent memory via per-group SQLite databases plus CLAUDE.md files — the agent remembers project context across sessions.

PicoClaw — the featherweight for the edge

  • Written in Go, ships as a single binary, memory footprint under 10MB, boots in under a second.
  • Runs on hardware as humble as a $10 RISC-V board.
  • Multi-provider: not tied to one LLM vendor; supports multiple providers and messaging channels.
  • The trade: it's a lean agent runtime, not a container orchestrator. Think "agent as a service on tiny hardware" rather than "fleet of sandboxed workers."

Rule of thumb: NanoClaw on your self-hosted box (Part 4 told you to keep one) as the autonomous engineering team; PicoClaw wherever compute is scarce — edge devices, sensors, that drawer of single-board computers. Part 6 takes PicoClaw much further.

What the Twin Actually Does

The realistic, deployable-today job description — using Abyss Drift as the running example:

1. Autonomous PM (triage)

Issues, error reports, and your own late-night "fix the fish spawning" WhatsApp messages land in the queue. The agent reads each against the codebase and CLAUDE.md, labels it, assesses severity, drafts a reproduction, and either schedules itself or flags it for human judgment. The judgment call thresholds are yours to define — in plain English, in the memory files.

2. Bug fixing (in isolation)

For a triaged bug, NanoClaw spins a container, clones the repo, reproduces, fixes, runs the test suite you built in Part 3, and opens a branch with a proper commit message and an explanation. It merges nothing. You review a diff over coffee instead of spending the evening in the debugger.

3. Feature branching

Small, well-specified features — the twenty-minute kind that pile up — get the same treatment: container, branch, implementation per CLAUDE.md conventions, tests, PR-style writeup. You remain the merge authority. The twin does the typing; you keep the taste.

4. Continuous testing

On a schedule or on push: run the suite, run builds, exercise smoke tests against the live deployment (is abyssdrift.pages.dev up? does the bundle build? did a dependency bump break the IMU permission flow?). Failures become triaged issues, which feed loop #1. The system feeds itself.

The Trust Architecture

This is the part that separates a production setup from a demo, and it's where security-first design earns its keep:

  1. Containment first. Agents act inside containers with only the mounts you grant. Worst case is bounded by design, not by hope.
  2. Write access ≠ merge access. Branches and PRs only. main requires a human. Non-negotiable until long trust history says otherwise — and honestly, after that too.
  3. Auditability is a feature you can read. ~500 lines of orchestrator means the security review is an afternoon, not an act of faith.
  4. Memory is inspectable. SQLite and markdown files — you can open the agent's "brain" and see exactly what it believes about your project. Correct it by editing a file.
  5. Escalation is designed, not emergent. Confidence thresholds and "ask a human" paths are explicit configuration.

Notice the continuity: the CLAUDE.md you wrote in Part 3 for interactive sessions is the same document teaching the autonomous layer your conventions. Investment in project memory pays across every phase.

A Realistic Onboarding Path

Don't stand up the full loop on day one. Trust is earned in stages:

  • Week 1 — read-only. Triage and reporting only. Judge the quality of its analysis.
  • Week 2 — test runner. Scheduled suites and smoke tests, filing failures as issues.
  • Week 3 — branch access. Bug fixes on branches for the well-understood, well-tested parts of the codebase.
  • Ongoing — widen slowly. Feature work on branches; expand scope as review after review comes back clean.

At every stage, the deliverable is the same: diffs for human review. The twin never replaces your judgment — it replaces your keyboard time.

The Economics

A brief honest note: an always-on agent consumes model tokens continuously. This is where BYOK flexibility (the same reason we chose Quests in Part 2) matters again — routine triage and test-running can run on cheap or local models, with frontier models reserved for actual code changes. PicoClaw's multi-provider design and NanoClaw's SDK foundation both accommodate this tiering. Autonomy is affordable when you control the model bill; it is not when a platform marks it up.

What You Should Take Away

  1. Interactive AI multiplies your hours; autonomous AI multiplies your calendar.
  2. Small and auditable beats big and magical for anything with repo access — read your orchestrator.
  3. Containers + branch-only access + human merges is the trust architecture. Start read-only, widen slowly.
  4. Your CLAUDE.md is now infrastructure — one memory system serving both interactive and autonomous agents.
  5. Tier your models. Cheap ones for triage, frontier ones for code.

You now have the full loop: bootstrap, engineer, deploy, and an autonomous twin keeping it alive. One frontier left — and it's the reason "open source" has been the drumbeat of every part.

Next: Part 6 — Beyond the Browser, where the same stack leaves the web entirely: IoT, edge devices, and the payoff of owning your tools all the way down.