batty.sh

Usage limits are the forcing function for smarter agent workflows. When you hit caps on one model, you start thinking about which tasks actually need the expensive model vs which can run on cheaper ones. Constraint breeds architecture.

The harness layer is where all the interesting problems live in AI coding agents — lifecycle management, context rotation detection, structured output parsing. The actual LLM call is the easy part. Everything around it is the hard part.

The best developer tools solve one problem completely. Not five problems partially. Not one problem with twelve config options. Just one thing, done well, composable with everything else. That's why Unix pipes still win.

Running AI coding agents on your machine without isolation is like giving interns root access on day one. Git worktrees solve this: each agent gets its own directory, its own branch. They can't see each other's uncommitted work. Conflicts only appear at merge time — when you want them.

Git worktrees let you check out multiple branches in separate directories. Same repo, shared history. No more stashing. No more WIP commits. No more cloning twice. Wrote a practical guide with 5 use cases: dev.to/battyterm/git-worktrees-the-secret-weapon-youre-not-using-3pdc

Unexpected benefit of AI coding agents: they surface every inconsistency in your codebase. Naming conventions, type mismatches, config drift — a human colleague might fix silently. An agent hits the mismatch and spirals. Agents make you write cleaner code.

The future of AI coding isn't one model doing everything. It's a routing layer. Different models for different roles: planning, execution, review. An orchestration layer that manages handoffs, gates on tests, isolates work. Coordination beats raw capability every time.

This Week in Batty #2 — 100 X replies (33 rounds) — 42 dofollow backlinks audited (DA 75-95) — JSON-LD structured data live on batty.sh — Merge day playbook prepped — 26 Bluesky posts, 56 follows Zero budget. Consistency compounds. github.com/battysh/batty

AI agents declaring their own work 'done' is like a student grading their own exam. 12 times in one week, an agent said a task was complete but the test suite disagreed. Without test gating, those 12 broken branches would have merged to main. Trust but verify. Automatically.

The biggest lesson from running 5 AI coding agents in parallel: the orchestration layer matters more than the model. Same agents, bad decomposition = merge conflicts and wasted tokens. Same agents, good decomposition = 4x throughput. Plan the work, then work the plan.

100 X replies. 33 rounds. 42 backlinks. 14 stars. Zero budget. All from content: 21 Dev.to articles, 18 Hashnode cross-posts, crates.io. 6 more pending from awesome-lists. Building in public with zero paid promotion. github.com/battysh/batty

The question isn't whether AI agents can write code. They can. The question is: who makes sure the code is correct, the work is organized, and the agents aren't stepping on each other? That's the supervision layer.

Agent-driven development in practice: 1. Architect decomposes the feature 2. Manager dispatches to available engineers 3. Each engineer works in its own worktree 4. Tests gate every merge 5. You supervise, not execute https://github.com/battysh/batty

The biggest mistake in multi-agent setups: starting with too many agents. Start with pair (architect + 1 engineer). Get the decomposition right. Then add engineers. More agents amplify good decomposition AND bad decomposition.

Start small. Scale when needed. Solo: 1 agent, focused tasks Pair: architect + engineer Standard: 1 architect + 1 manager + 3 engineers Large: 19 agents across 3 management layers cargo install batty-cli https://github.com/battysh/batty

The difference between vibe coding and agent-driven development: Vibe coding: one agent, one prompt, hope it works. Agent-driven: architect decomposes, multiple agents execute in parallel, test gates verify, merge locks serialize. Structure, not vibes.

We're seeing a new pattern emerge: agent-driven development. Not vibe coding. Not traditional dev. Humans architect. Agents implement. Tests verify. The skill isn't writing code anymore — it's decomposing work and supervising execution.

90 X replies. 30 rounds. 15 Bluesky posts. 30+ articles. 14 stars. All organic. All genuine engagement. Zero ads. The boring answer is the correct answer: show up every day and add value.

Running 5 AI agents in parallel costs 1.5-2x, not 5x. The optimization: scoped tasks, session resets, model mixing, and restricted communication. Full cost breakdown: https://dev.to/battyterm/the-real-cost-of-running-5-ai-coding-agents-in-parallel-1lo

The file-based approach constrains architecture in useful ways: no distributed state, no eventual consistency, no cache invalidation. Just files on one machine, managed by one daemon, tracked by one git repo.

From solo agent to agent team — a progressive migration guide. Stage 1: git worktrees (5 min) Stage 2: tmux visibility (10 min) Stage 3: test gating (5 min) Stage 4: architect role (15 min) Stage 5: full automation https://dev.to/battyterm/from-solo-agent-to-agent-team-a-migration-guide-474c

This Week in Batty — Week 4 10 → 14 stars 30+ articles published Bluesky launched 12-part series created 80+ X replies GSC verified Zero budget. Consistency compounds. https://github.com/battysh/batty

If I had to choose between 1 architect agent + 2 engineers or 0 architects + 5 engineers, I'd take the architect every time. Task decomposition quality > agent count.

47 tasks. 12 test gate catches. $45 in tokens. What actually happened when we ran 5 AI agents on a real Rust project for a week. https://dev.to/battyterm/what-i-learned-supervising-5-ai-agents-on-a-real-project-cl8

Backups = cp -r Version control = git add Debugging = cat Monitoring = watch ls When everything is a file, every Unix tool becomes an agent management tool.

When your AI agent breaks at 2am, how fast can you figure out what happened? With files: ls and cat. With a database: SQL client + schema knowledge. Why we built everything on files, not databases. https://dev.to/battyterm/how-file-based-architecture-makes-ai-agents-debuggable-4e4i

Two retries on a medium-complexity task can exhaust a 200K context window. That's why test gating matters — if the first attempt passes, you never enter the retry loop that causes context exhaustion. Prevention beats rotation every time.

We wrote a 12-part series on building an AI agent supervisor in Rust. Architecture, patterns, and lessons — from sync daemons to git worktree isolation to context rotation. Full index: https://dev.to/battyterm/building-an-ai-agent-supervisor-series-index-m4p

Hot take: the biggest productivity gain from AI agents isn't faster code generation. It's the ability to supervise five parallel workstreams instead of executing one. The skill shift is from writing code to knowing when code is wrong.

Context rotation: what happens when your AI agent runs out of memory mid-task. Early signs, detection patterns, and how to scope tasks to avoid exhaustion entirely. https://dev.to/battyterm/context-rotation-for-ai-coding-agents-what-happens-when-they-run-out-of-memory-17f6

14 stars and growing. Every star from organic discovery. No ads, no influencers. Just articles, conversations, and building in public. https://github.com/battysh/batty

Choosing an AI agent orchestrator in 2026? Honest comparison of Batty, vibe-kanban, CrewAI, AutoGen, and raw tmux scripts. https://dev.to/battyterm/choosing-an-ai-agent-orchestrator-in-2026-a-practical-comparison-i0k

Zero budget, 4 weeks, 14 stars. Here's exactly what worked for our open-source Rust CLI. https://dev.to/battyterm/open-source-marketing-with-zero-budget-how-we-got-14-stars-in-4-weeks-45m2

How Batty works: 1. Define a team in YAML 2. Each agent runs in its own tmux pane 3. Work isolated in git worktrees 4. Tasks from a Markdown kanban board 5. Nothing merges until tests pass Synchronous daemon. No async runtime.

Your AI agents need a boss. Batty is a terminal-native supervisor for AI coding agent teams. Define roles in YAML, launch agents in tmux panes, isolate work in git worktrees, gate everything on test results. Open source, built in Rust. https://github.com/battysh/batty

Your AI agents need a boss. Batty supervises coding agent teams in tmux — git worktree isolation, test-gated merges, Markdown kanban dispatch. Open source, built in Rust. github.com/battysh/batty

Your AI agents need a boss. Batty is a terminal-native supervisor — runs multiple coding agents in tmux, isolates work in git worktrees, gates everything on test results. Open source, built in Rust. 14 stars and growing. github.com/battysh/batty

Context degradation is real but the bigger gap: nobody verifies output. Run the full test suite after every agent task — not the tests the agent picks. An exit code catches what reasoning misses. What's your verification step?

Key word: "supervised." Unsupervised AI code has 1.7x bug rate vs human. But supervised AI code (test-gated, reviewed) beats unsupervised human code. The verification step matters, not who wrote it.

Supervision is the underrated section. Real productivity isn't "faster code" — it's catching bad output before it hits main. Test suite as quality gate: exit code 0 or the branch stays. Which pattern are you using?

You're onto it. The gap isn't more AI coding — it's orchestration between human intent and agent execution. Task breakdown, visibility, quality gates. How much should the human stay in the loop?

"Team of 1" is real. The unlock: separate planning from execution. One agent decomposes work, others execute in parallel on isolated branches. Tests gate everything before merge. How do you handle two agents touching the same files?