Every post on this blog so far has described Develosaur from the outside: a feature, a bug, a decision. This one is from the inside. The board that plans this company's own engineering is a Develosaur board, running on the same desktop host anyone can download, and a large share of the fixes I have written about here were not done by me at a keyboard. They were done by AI agents claiming tasks off that exact board.

What a working session actually looks like

An agent starts, reads the ranked list the way the priority order is described, and either finds real work at the top or reports honestly that the head is empty or stale. It claims a task the way several agents avoid colliding: a lease, not a hand-applied tag, refused if someone else already holds it. It does the work. It closes the task with a resolution line naming what changed and where it is visible, a file, a test, a deployed build, because a board that lets "done" mean nothing rots exactly the way an unattended to-do list does, just faster, since agents move faster than people do.

Relay poison, the claim system, the priority engine itself: none of these were designed on paper and demoed once. They were built, broken, and fixed on this board, by agents working this board, which means the product had to be good enough to survive using it on itself before it was good enough to sell.

Why an AI-heavy process needs different guardrails

A solo developer accumulates judgment over years and mostly does not need it written down. A codebase where agents pick up whatever is next on the list, session after session, with no memory of the last one, needs the judgment written down explicitly or it gets re-litigated, and sometimes re-broken, every time.

That is what a short, named list of enforcement rules is for. A few of them:

• Restore, do not re-derive. If something was visible before a refresh, it is saved state, not a value to recompute from scratch. Recomputing it invites two code paths to disagree about the same fact.
• One readiness signal, no new timers. Anything that needs to know whether the board is ready asks the one authority that tracks that, instead of adding its own setTimeout and hoping it lines up with everyone else's guess.
• Enforce at the boundary, not at the call site. A rule that is only checked where two things were once caught colliding will get violated again from a third place nobody thought to check. It has to be structurally impossible to violate, not just checked in the spot that broke last time.

A PR that violates one of these gets rejected by pointing at the rule. No re-arguing the same debate from zero, whether the PR came from an agent or from me.

The ugly code that is not debt

The other side of that discipline is a list of things that look like cleanup targets and are not: guards that exist because an earlier, well-intentioned simplification broke something real, written down so the next well-intentioned cleanup, agent or human, does not repeat it.

One example: the code deliberately does not double-check the document against the server on every load, only when something specific looks wrong. The obvious version, check every time, is what actually caused a real egress cost spike once, and that restraint is now enforced as a shipping requirement, not a setting someone could quietly loosen back to "just always check."

Another: dragging a node on the canvas does not write to the shared document on every frame. Position lives outside the CRDT on purpose. Putting it back in, in the name of having one clean source of truth, caused a real incident before, and reads as an obvious improvement to anyone seeing it for the first time.

Neither of those looks like a decision from the outside. Both are decisions, and both have an incident behind them that made the decision non-negotiable.

What dogfooding actually buys

It does not mean the product is bug-free. Relay poison happened. The backpressure limits exist because writers overwhelmed the board before they were added. Dogfooding means those were found on our own board, by our own process, before they were something a customer had to report. The same claim system, the same priority engine, and the same small set of rules that keep an agent from re-breaking what an earlier one fixed are exactly what is described elsewhere on this blog, because none of it is aspirational. It is what this company already runs on.

More on how the pieces fit together is on the how-it-works page, and the incidents themselves are on the blog.