Architect first, code second.

$bird

bird · the whole thing in 42 seconds
install

Install

$ curl -fsSL https://raw.githubusercontent.com/srujan375/bird/main/install.sh | sh
$ bird

Needs git and Python 3.11+; Node adds the full-screen TUI. The first bird walks you through keys and picks a model that answers — local Ollama, Ollama Cloud or OpenRouter. Run the same line again to upgrade.

What is bird

It designs before it builds.

Most coding agents start editing on turn one. bird designs first, on a canvas you can see and edit, with a second model arguing against the design while it's being made. Only then does it write code. Three harnesses share one engine, so permissions, sessions and the context engine work the same in all of them. It runs on models you control: local Ollama, Ollama Cloud, or anything on OpenRouter.

Why architect first. An agent that starts editing on turn one makes your architecture decisions for you, badly, while you watch a diff scroll past. Plan-first tools (Claude Code's plan mode, spec-driven workflows) exist because a plan is reviewable and a 400-line diff isn't. Splitting design from implementation also keeps each agent's scope small, which is where most runaway edits come from.

harness
lead
talks, routes, dispatches
dispatch
harness
arch
designs on a live canvas
harness
code
edits, tests, verifies
bundle handoff

one engine · one toolbox · knowledge graph

Comparison

Median per run one task · n=3 bird glm-5.2 bird --no-kg Claude Code Sonnet
Task solved3 / 33 / 32 / 2
Retrieval latency<1 ms7.2 sn/a
Tool calls to the fix566.5
Context at the fix7,8475,69357,577
Total tool calls22218
Wall time51 s48 s37 s
Cost per run~$0~$0$0.36

arch

Don't just plan, Architect.

When most of your code is written by agents, the architecture is the part that still has to be right. bird arch opens a workbench when the work needs one and walks the feature through step by step: components, endpoints, db schemas, infra requirements, and the shortcomings it won't pretend away. Plan mode gives you prose to approve. This gives you a structure to argue with.

arch workbench · localhost
The arch workbench: a canvas of the thinking-trace design, showing the wire adapter, ReAct runner, serve pump, TUI bridge and ThinkingTrace component, with three reviewer objections pinned to it as sticky notes. Each objection proposes an alternative and offers Accept or Overrule. The right panel groups flows into happy path, failure and background, and shows a transcript in which a separate critic model files an objection the architect accepts.

code

Read, plan, edit, verify.

kg_query is the primary search tool for the whole session, and the engine nudges the model back when it drifts into grep. Anything multi-step gets a plan pinned into the conversation, with the current step and its files; done is blocked while steps are open. bash is allowlisted to read-only search, tests, linters and git reads. Everything else is refused loudly. You approve every edit with a real diff.

$ bird code "fix the failing test"
› kg_query: test_pricing.py
› read: src/pricing.py
› plan: 2 steps
› edit: src/pricing.py (diff pending approval)
› bash: pytest -q
✓ 1 passed

lead

Talks, explores, decides where the work goes.

lead has no edit, write, or bash tools. It answers questions, reads and researches, and each turn decides whether to reply or dispatch. New features go through arch first, then code. Localized fixes go straight to code. An agent quietly changing something while answering a question isn't possible here, it's structural.