I Replaced Scrum, Jira, and Our Wiki With 12 AI Agents on a Mac Mini

A survey last week put it at 54%. More than half the code shipped today is AI-generated.

In my own work the number is probably higher. AI writes the first draft. AI estimates the work. AI generates the tests. I've written before about

Your whole org as a grove. Each repo is a tree, each feature a branch, each teammate present in the world. More on this below — but yes, that's the actual dashboard.

The thing that finally broke me: the wiki

Here's the moment it clicked.

A new feature needed context. I opened our wiki. The page was six months old. It described an architecture we'd refactored twice since. The "source of truth" was confidently, completely wrong — and three engineers had made decisions based on it that week.

Documentation lies the moment you stop maintaining it. And nobody maintains it, because maintaining it is the busywork we all silently agree to skip.

Source code doesn't lie. It can't. It's the thing that actually runs.

So the first rule of the system I built: the code is the wiki. Knowledge is extracted from the repository — the call graph, the module boundaries, the patterns, the history — and indexed continuously. When an agent or a human asks "how does settlement work?", the answer is reconstructed from what's true right now, not from a page someone wrote last quarter and abandoned.

No Confluence. No Notion graveyard. The only document that's allowed to be authoritative is the one that compiles.

The same emoji-react, thread-reply Slack you already live in — except the answers come from the source of truth, not from memory.

So "the code is the wiki" isn't a slogan — it's an architecture. Knowledge lives in four layers that stay in sync on their own:

1. 
   The repos themselves — source code plus a per-repo CLAUDE.md, synced on every PR merge to main.


2. 
   Agent skills — org standards, design guidelines, API patterns; synced on change.


3. 
   The central store — BUDs, enterprise rules, architecture decisions; real-time.


4. 
   Vector search — semantic search across all of it, auto-indexed.

Two things make this more than a fancy grep. It indexes code locations, so any knowledge captured during development points back to the exact file and symbol it came from — and it links across repos, so a frontend call is connected to the backend handler it actually hits, not left as two disconnected facts in two different wikis. And it never goes stale: after every PR merge, the affected feature is updated with the new commit history and the new code locations automatically, so the next agent that touches it inherits the current truth, not last month's.

That's the whole pitch against Confluence — auto-synced from source instead of hand-maintained, semantically searchable instead of keyword-matched, always current with daily staleness detection, and wired straight into the agents' prompts so they're never reasoning from a stale page.

Agent-Driven Development, in one table

I call the methodology Agent-Driven Development (ADD). The simplest way to explain it is to put it next to the thing it replaces.

The pattern underneath all six rows is the same: let the machines handle the noise, so humans spend their judgment where judgment actually matters.

The 12 agents

Here's the whole cycle on one diagram before I break it down — twelve agents around a loop, with a human reviewing at the centre and at every gate.

"Change the notification icon to modern design?" → the agent checks for duplicates, then interrogates the intent before a single line is written.

From there, every feature moves through the same seven-phase lifecycle, each phase a tab on its BUD:

Slack idea → Intake → Requirements → Design → Tech Spec

   → Development → Code Review → Testing → Prod

        ↑ estimation, status, learning and skills run alongside ↑

Five developers, eighteen modules, scored from real commits. This is what feeds estimation and routing — not a manager's hunch about who "knows the auth code."

Is the skill-score input perfect? No. It's derived from who happened to touch what, so it can encode bias. That's one of the two things I most want feedback on.

And the loop closes itself. When a BUD ships, the Learning Agent writes the retrospective from the actual diffs — including an estimated-vs-actual table that tells you exactly where the model was wrong, so the next estimate is better.

Your team, present. Move, sprint, wave, cheer, invite. The status bar is real controls, not decoration.

It started as a visualisation. It became the most honest org chart I've ever had — because it's drawn from the code, not from a slide.

Read the numbers: a production bug costs you more than shipping earns. That's the whole point. In a world where AI can churn out code that passes tests, the scoreboard has to reward what AI is bad at — code that holds up.

That ties straight back to where I started. AI nails the 80%. The 20% — the part that doesn't blow up in production — is what we actually want to incentivise. So that's what the game scores.

It runs on a Mac mini, and your data never leaves it

This is the part I care about most, and the part most "AI dev platform" pitches skip.

Bodhiorchard is self-hosted by design. Postgres with pgvector, your repositories, the embeddings, and the full audit log live on your hardware. For me, that hardware is a Mac mini. No repo content is shipped to anyone's cloud. For a regulated shop — and I lead engineering at an FCA-authorised fintech, so this is not theoretical for me — that's the difference between "interesting demo" and "allowed to exist."

Inference is your choice. It runs on Claude Code today; Ollama and OpenAI are on the roadmap for fully air-gapped setups. The agent layer is engine-independent — swapping the model is API rewiring, not a redeploy.

The stack, for the curious:

Backend   FastAPI · Python 3.12

Frontend  Vue 3 · PlayCanvas (the 3D world)

Data      Postgres + pgvector · Redis

Agents    Local MCP server (read + bounded write tools)

License   Apache 2.0

It's also built for real orgs, not just a solo demo: detailed roles and permissions, multi-org support out of the box, and capacity planning baked into triage and assignment — the Triage Agent defers work when the team is full, and Smart Assignment balances by real-time utilisation rather than who shouts loudest. So the "self-hosted toy" worry doesn't really hold; it'll sit inside an org's access model on day one.

Honest status, because HN will ask anyway

I'd rather tell you this up front than have you find it.

What's live today: the platform, the BUD lifecycle, the MCP write-path, repository and code-graph indexing, skill profiling, and the 3D living-tree dashboard. The agents are real and they work with a human in the loop at every gate.

What I'm still building: the fully autonomous execution loop. The direction I'm taking it is deliberately narrow — auto mode first for small, low-risk BUDs, where one agent chain runs tech spec → code → code review → test → deploy end to end, then stops and waits for a human to approve the release. Not "point the swarm at production and walk away." Lights-out on the small stuff, a human gate where it counts. That's the active work, not a shipped claim. So today this is agents-assisted, human-in-the-loop, and anyone who tells you their agent swarm ships production code fully unattended is selling something.

This is an independent project. I built it solo, on my own time, not affiliated with any employer — the fintech is where I felt the pain, not the thing that owns the code.

You don't have to start from zero

If you're on Jira today, you don't throw your backlog away. Connect Jira Cloud and import your existing issues straight into BUDs — point Bodhiorchard at the work you already have and watch the grove fill in.

— the twelve agents, the manifesto, the Agile-vs-ADD table, all of it. The repo has six demo videos and four sample repositories you can point it at: .