AI-CICD

Most teams bolted AI onto an existing process. A model writes a function, a human pastes it in, and everything downstream stays the same. We went the other way and rebuilt the process around the models. We call it AI-CICD.

It has three phases. Design, development, revision. A human decides what to build and whether to ship it. Almost everything between those two points is a model.

Some of what follows runs today. Some of it is where we are heading. I have marked which is which, because a process post that hides the gap is not much use to anyone.

  DESIGN                                          who
  product design .......... is it the right thing?  Claude Design + interviews
  system design ........... where do the seams go?  Claude Fable
  document + approval ..... is the plan sound?      Fable AND Codex Sol
        |
        |  the approved document IS the prompt
        v
  DEVELOPMENT
  ssh to a VPS, start the run, walk away (hours)
  implement ............... cheap model
  review .................. strong model
        |
        v
  REVISION
  specialised agents, each with its own tools
        |
        |  each returns: score + suggestions + comment
        v
     all scores >= 8 ? ---- no ---> Fable writes a new plan --+
        |                                                     |
       yes                                                    |
        |                        (back to DEVELOPMENT) <------+
        v
     open the PR

Design phase

Nothing gets implemented until there is a document, and the document is the deliverable of this phase.

Product design. We use Claude Design heavily here, alongside interviews and small tests. The question this phase answers is whether we are building the right thing at all. It is the cheapest place to be wrong.

System design. A long session with a strong model, currently Claude Fable, about the implementation and the system shape. This is not the model writing code. It is an argument about where a boundary goes and what it costs.

The side effect matters as much as the output. A developer who sits through that session comes out knowing more about the theory and the services involved than they did going in. Using a strong model as a design partner is the fastest way I have found to learn a part of the stack you have not touched.

Documentation and approval. The plan becomes a standard document with a fixed set of sections. Then two different models review it: Claude Fable, and Codex Sol at extra-high reasoning. Two models from two labs disagree in different ways, which is the whole point of asking both.

The document only passes when both approve it.

Development phase

The approved document becomes the initial prompt. That is the handoff. No summary, no restating, no lossy translation from plan to instruction. The plan was written to be executed.

The developer opens an ssh session to a VPS and starts the run. It goes for hours. That is expected, and it is why it runs on a box rather than a laptop: nobody wants their machine pinned for an afternoon, and nobody wants a run to die because a lid closed.

Implementation runs on a cheaper model and gets reviewed by a stronger one. The economics are the argument. Most implementation is mechanical once the design is settled, and mechanical work does not need the expensive model. Judgement does. Splitting the two by cost, rather than using one model for everything, is the single biggest lever on what a run costs.

When implementation finishes, the revision flow starts automatically unless it was explicitly skipped.

Revision phase

This is the phase with the most room left in it.

What runs today. We ask Claude to run the revision. One agent, general purpose, reading the diff. It works, and it catches real problems. It is also obviously not the right shape.

Where it is going. Specialised agents, one per concern, each with the tools and the system knowledge that concern needs. Penetration testing with Chrome and devtools attached. Database review with AWS CLI access. Folder-specific review that knows the conventions of the directory it is reading and runs the tests that cover it. The VPS carries all of that tooling so an agent can actually use it rather than reason about it from a diff.

A general agent reading a diff can tell you the code looks wrong. An agent with devtools open can tell you the page is broken.

Reports. Each agent returns a score, a set of suggestions, and a general comment. The score is the part that makes the loop work, because a number is something you can gate on.

Self improvement. A fresh Fable session reads every report and writes a new implementation plan. That plan re-enters the development phase. The loop runs until every score clears the bar, currently a target of 8.

Then the PR opens.

What we have learned so far

The plan is the artifact. Everything else is derived from it. When a run goes wrong, the plan is almost always where it went wrong, and it is cheap to fix at that stage.

Two reviewers from two labs beat one reviewer. They fail differently. A model reviewing its own work agrees with itself too often.

Cheap for mechanical, expensive for judgement. Treating model choice as a per-phase decision rather than a global one changed our costs more than any prompt we have written.

A score turns review into a loop. Prose feedback is something a human triages. A number is something a pipeline can act on. That one change is what makes the revision phase automatable at all.

The honest summary is that the design and development phases are real, and the revision phase is half-built. We are working on the other half.