Athena

The problem

Coding agents are good at writing code and bad at knowing when to stop. Give one a feature request and it will happily produce a thousand lines that compile, pass nothing, and answer a question nobody asked. The failure is rarely the code itself — it is that no one decided what should be built before something was.

Athena is my answer to that. It is a development system, not a coding assistant: a request enters through Telegram and comes out the other side as reviewed, tested, committed code, having passed through nine stages and stopped five times to ask me whether it should continue.

Nine stages, five gates

The pipeline is deliberately slower than a single agent writing code. Each stage produces a document that the next stage consumes, so a bad assumption surfaces as a bad requirements doc rather than as bad code three hours later.

1. Ideation — turn a loose request into a defined problem
2. Requirements — a product requirements document
3. Technical planning — how it will be approached
4. Architecture — a system architecture document
5. Coding standards — the conventions this build will hold to
6. Development — orchestrated, split across parallel tasks
7. Review — an independent agent that did not write the code
8. Test — an independent agent that did not write the code or the review
9. Deploy

Five of the boundaries between those stages are human approval gates. Nothing proceeds past them without me. This is the part that makes the system usable: I am reading a two-page requirements document, not auditing a diff, and I can kill a bad direction at the point where killing it costs minutes.

Review and test are separate agents from development on purpose. An agent asked to check its own work will find it satisfactory almost every time.

Seventeen roles, two lanes

Athena runs seventeen distinct agent roles. They are not seventeen copies of one model with different prompts — they split across two routing lanes chosen for what the work actually needs.

The reasoning lane handles orchestration, planning, architecture and review. This work is judgement-heavy and comparatively low-volume, so it runs Claude-class models through a self-hosted gateway that aggregates around 350 models.

The code generation lane handles the writing. It runs NVIDIA Nemotron models directly, where throughput matters more than nuance.

Each lane has its own automatic fallback chain. That was not in the original design — it exists because live testing kept hitting providers that were slow, rate-limited, or quietly returning degraded output. I built a routing layer of my own to sit in front of them, and reliability stopped being the thing I thought about.

Keeping it contained

An agent system that can write and commit code needs boundaries that hold when something misbehaves.

• Isolated git worktrees. Every development task gets its own worktree, so parallel tasks cannot corrupt each other's working tree and a bad run is discarded by deleting a directory.
• Least-privilege delegation. Most roles are unreachable directly; they are only addressable through a central orchestrator. There is one place where control flow can be reasoned about.
• Two-tier logging. Per-task and per-phase, so a failure can be traced to a stage rather than to a wall of interleaved output.
• Rate-limit and concurrency guardrails, because seventeen roles across two providers will find your quota ceiling immediately otherwise.

Does it actually work

The honest test of a system like this is not the architecture diagram. It is whether anything came out of it.

I gave Athena a single request: build a scientific calculator. What came back was a complete React application — unit and currency conversion, history, animations, theming — with an ESLint and Prettier standard, a CI workflow, and a production build, committed to my self-hosted Gitea across eight conventional commits.

Alongside the code it left its own paper trail:

• a 13 KB product requirements document
• a 47 KB system architecture document
• a 22 KB technical implementation plan
• a task distribution plan, a gated-workflow specification, and per-commit module documentation

That artifact trail is the part I find most useful. The code is ordinary; plenty of things can write a calculator. What is unusual is being able to open the architecture document that was agreed before any of it was written, and see the decisions it was built from.

What I would change

The pipeline is heavy for small work. A one-line fix does not need nine stages, and I currently have no lighter path for it — every request pays full freight. The next version needs a triage step at the front that routes trivial changes around most of the pipeline.

The approval gates are also all-or-nothing: I approve a stage or I stop it. What I actually want most of the time is to amend a document and continue, which the current design has no way to express.