Article
I still use Necronomicode every day. The reason I built it was pretty simple: I wanted to hand over a piece of work and stop babysitting the terminal.
When I started, I didn't have the agent-team controls I wanted in my coding setup. I wanted to try developers, planners and reviewers that would challenge the work. I also wanted one place to manage what they were doing.
So I built Necro around Codex.
Codex runs in the terminal as the supervisor. Necro gives it tools to start workers, monitor progress, manage handoffs and keep work moving within limits. Codex remains the coding runtime. I'm building an extension around it rather than trying to rebuild it.
The goal is to keep feeding it specs and let a project move forward in the background.
Another agent needs a job
Spawning more agents gives you more work to coordinate. Somebody has to decide what each agent is doing, what it needs from the previous person or agent, and what happens when it gets stuck.
That's what I wanted to explore with different teams.
A planner can work through an approach before development starts. A developer can implement against a spec. A reviewer can inspect the result. An adversarial reviewer has a more pointed assignment: look for the reasons the work should fail review.
Necro supports different arrangements of those roles. I can choose a simpler path for a small job or add planning and adversarial review when I want that scrutiny. Each extra role adds another handoff, so I want a reason for putting it there.
The spec gives that work a boundary. It needs to describe the change, its constraints and how completion will be checked. The handoff needs to leave enough evidence for the next agent, or me, to understand what happened.
Otherwise, I'm back to reconstructing a project from terminal conversations.
Continuing the work is part of the job
A useful supervisor has to do more than launch a worker.
In a development-and-review loop, a reviewer can accept the work, request another pass or report a block. Necro can send work back for repair within a pass limit. Queued specs let the process continue into the next piece of work when the current piece finishes successfully.
That continuation is a big part of why I use it. I want to put the next pieces of work into the system without personally restarting the process after every handoff.
There are limits. A blocked handoff, a failed worker or an exhausted pass limit needs to bring the work back to me. A failed or blocked spec stops new launches. Work already running in isolation may still need to settle.
Stopping is useful behaviour. I don't want an agent to keep inventing its way around a decision that belongs to me.
Why I still use it now that subagents are available
My coding tools have gained subagents since I started this. I still want the control Necro gives me over the operating process: the specs, role choices, handoffs, queue and places where work has to stop.
For the way I work, that control is why I keep using it.
The payoff is personal and practical. I can delegate defined work and walk away while it continues within those boundaries. When it needs my judgment, I have a place to come back to and inspect it.
An AI reviewer can still miss something. A completed run needs appropriate checks; adding another agent doesn't remove my responsibility for what ships.
But Necro has been a lifesaver for how I manage my own projects. It lets me spend more of my attention on what the next spec should say, while the supervisor keeps the current work moving or brings back the decision it can't make.