What Building a CFO Agent Taught Us About Spec-Driven Development

My previous employer was a publisher. We built translation models, and whenever we shipped a new version, the check was simple: same input, two models, outputs side by side. You looked at both and formed a judgment.

When we needed the same kind of check on the CFO agent, I started there.

What Spec Kit Is and How We Used It

Spec kit is a set of commands that live in your repository and guide you through a structured requirements process before you write any code. You start with /speckit.constitution, which produces a concept document for the project. After that, every time a new feature comes up, you run /speckit.specify and it walks you through a conversation: what do you want, what are the edge cases, what does done look like. The output is a markdown file in a specs/ folder, enumerated, with an implementation plan attached.

The enumeration turns out to matter more than it initially looks like it would.

The Numbering Problem

My colleague Gabi and I were each generating new specs without checking what numbers the other had already taken. When you're working alone, the numbers increment cleanly. Working in parallel, you get collisions — two different specs sharing the same number, cross-references becoming ambiguous.

What helped was committing specs before they were finished, so Gabi's tooling would pick up the current highest number before she started a new one. We hadn't thought about this until we hit the problem.

The Devil's Loop

Somewhere in the middle of the project I caught myself editing a spec while I was implementing it. The implementation had revealed something I hadn't thought through, so I updated the spec. Which meant the plan no longer matched what I'd built, so I updated the plan. Which surfaced something else I hadn't anticipated.

We ended up calling it the devil's loop — the spec and the implementation chasing each other, each change invalidating work already done. The way out was to stop modifying the original spec once implementation had started and open a new one instead. If something had changed from what I'd originally committed to, it became its own spec. The original stayed as a record.

Planning One Epic at a Time

In the early sessions I went long — two extended conversations with spec kit, trying to map out everything I could see coming. By the time I reached specs from those sessions, the context was gone. I re-read my own specifications and barely recognised what I'd been thinking. Sometimes I ended up re-speccing things I'd already specced.

Keeping to one epic at a time helped — one coherent set of work I could hold in my head from start to finish. Beyond that, I kept changing my mind about what I wanted once I'd finished a set of features, which made everything I'd planned for next out of date.

This pattern is familiar from regular backlog management: detail the next week, sketch the week after, leave everything further out as rough bullet points. The timeline compresses when you're working this way, but the underlying logic is the same.

Specs as Somewhere to Put Unfinished Thinking

One thing that changed how the project felt was treating specs as a place to drop ideas that weren't ready to build yet. When something occurred to me while coding — a possible feature, a question I didn't have time to investigate — I'd write it up as a draft spec, attach a rough issue, mark it stale, and push it.

When Gabi and I wanted to explore the observability work together, I could put my current work on stale, go in that direction, and come back without losing track of where I'd been. The ideas sat in the specs folder until we needed them.

The Sync Overhead

Keeping specs, GitHub issues, and pull requests aligned took more time than I expected. Every time the project shifted in a direction I hadn't planned for, I had to reconcile: does this spec still describe what we're building, do these open issues still make sense? I used the GitHub CLI to generate issues from specs and keep them loosely connected, but the alignment was manual and ongoing.

Looking back, I'd set aside time at the end of each epic to do that reconciliation — specs, open issues, PRs all at once — rather than catching up continuously.

How Fast This Can Move

Our colleague Michael had a working CFO agent — authentication through Clerk, a Firestore backend, Cloud Run deployment, tools registered against the Unicontas API — in under a week. At that development pace, a bad spec workflow doesn't stay a small problem for long.

What I'd Do Differently

If I were starting again, I'd push specs to the shared repository from day one, plan one epic at a time, and treat the stale-issue workflow as a default from the first session.

The CFO agent is an internal project at re:cinq. More from the team at re-cinq.com/blog.