AI Companion vs Spec-Driven AI Delivery: Two Ways of Working with AI, and Why We Use Both

When I first brought AI into my daily work as a Solution Architect, it felt like having an exceptionally fast, well-read colleague at my side. I asked, it answered. I challenged, it adapted. Together, we moved faster from question to solution. That is the AI Companion model.

But over the past months, our team has been building something very different: a spec-driven AI delivery pipeline. Here, AI is no longer a colleague in the conversation. It becomes part of the delivery system itself, one set of stations in a controlled production line, with explicit rules, checkpoints, and human accountability.

Working with both has changed the way I think about AI in software engineering. The real question is no longer simply how much AI can help. It is where AI should sit in the delivery process, what it should own, and where humans must stay in control.

The AI Companion: a conversation led by the human

In the companion model, the human is the orchestrator. You give context, pick the next step, judge each answer, and decide when you’re done. As a result, AI speeds up your thinking. It can help you explore an API design, challenge an integration pattern, draft a mapping, or understand an unfamiliar codebase.

Its main strength is flexibility. You do not need to define everything upfront, and you can change direction halfway through the conversation.

However, that flexibility is also its weakness. Quality depends heavily on the person driving the interaction. Context lives mostly in that person’s head, and teams struggle to reproduce or scale the results consistently.

The spec-driven AI delivery pipeline: a process with AI inside it

The pipeline reverses the relationship. The process is the orchestrator, and humans step in at defined checkpoints.

Intake is fully deterministic. User stories are added to the ticketing system. An orchestrator picks up a story only if it isn’t already assigned to someone and doesn’t depend on another story that hasn’t been implemented yet. There’s nothing here that needs AI, so no AI is used.

From there, each story moves through six stages:

• Stage 1: AI spec writing. AI turns the story into an OpenSpec specification on a dedicated spec branch.
• Stage 2: Human spec review. A person validates the intent before any code exists. A rejection or a comment sends the spec back to Stage 1.
• Stage 3: AI development. Code is generated against the approved spec on a dedicated feature branch.
• Stage 4: AI review. An AI reviewer examines the pull request. Any remark sends it back to Stage 3.
• Stage 5: Human code review. A person reviews the pull request. Any remark sends it back to Stage 3.
• Stage 6: Merge to main. Merging requires a green build, exactly as it did before AI was part of the process. The pipeline changes who writes the code, not the rules the code has to pass.

Meanwhile, a build runs on every commit to both the spec and feature branches.

We do not treat the build as another stage. Instead, it acts as a permanent deterministic gate. If the spec branch fails, the work returns to spec writing. If the feature branch fails, it returns to development.

flowchart TD
    T[Ticketing system<br/>User stories are added] –> O[Orchestrator<br/>Picks unassigned stories whose dependencies are implemented]

    subgraph SPEC[spec branch]
        S1[Stage 1: AI spec writing]
        S2[Stage 2: Human spec review]
        B1{{Build on every commit}}
    end

    subgraph FEAT[feature branch]
        S3[Stage 3: AI development]
        S4[Stage 4: AI review]
        S5[Stage 5: Human code review]
        B2{{Build on every commit}}
    end

    O –> S1
    S1 –> S2
    S2 — Rejected or commented –> S1
    S2 — Approved –> S3
    S3 –> S4
    S4 — Remark on the PR –> S3
    S4 — No remarks –> S5
    S5 — Remark on the PR –> S3
    S5 — Approved –> M[Stage 6: Merge to main<br/>Requires a green build]

    S1 -.-> B1
    B1 -. Fail .-> S1
    S3 -.-> B2
    B2 -. Fail .-> S3

    classDef det fill:#ECEFF3,stroke:#5B6573,color:#1F2328
    classDef ai fill:#E3EEFC,stroke:#1D5FBF,color:#1F2328
    classDef human fill:#FFF2DC,stroke:#C26A00,color:#1F2328
    class T,O,M,B1,B2 det
    class S1,S3,S4 ai
    class S2,S5 human

Four design choices make this work.

The spec is the contract. In the companion model, intent is implied in the conversation. Here, intent is written down, validated, reviewed, and versioned before any code is written. It’s the same discipline we’ve always applied to API design, now applied to how we instruct AI.

Every AI stage runs with a fresh context. The AI that writes the code isn’t the AI that reviews it. Each stage sees only what it needs: the spec, the diff, the review comments. No accumulated conversation, no drift, and no model grading its own homework.

Every checkpoint can say no. Builds catch what a build can catch. AI review catches deviations from the spec and our standards. Humans catch what only humans can judge. Each has an explicit path back to the stage it’s checking.

Loops are bounded. Every task has a limit on the number of runs. A story that can’t converge doesn’t cycle forever; it stops and comes back to people.

When each one fits

The companion is the right tool when the problem isn’t yet understood. That covers designing a new integration architecture, investigating a production issue, evaluating a technology choice, or any situation where the question itself is still moving. Forcing that work through a pipeline just produces a precise spec for the wrong thing.

By contrast, the pipeline works best when the problem is understood and the work repeats.

Examples include adding endpoints that follow established conventions, building connectors based on known patterns, or implementing user stories on a mature codebase.

In those cases, variability becomes a cost rather than a source of creativity. Therefore, a defined process with explicit checkpoints usually beats a clever conversation.

If you can’t write the spec yet, you need a companion. If you can, the story belongs in the pipeline.

Using the companion and pipeline together

In practice, the two models aren’t competitors. The companion lives at the edges of the pipeline:

• Before intake
  The companion helps turn unclear requirements into user stories that are precise enough to enter the pipeline. This is important because the pipeline performs best when it receives bounded, well-understood work.
• At human checkpoints
  During spec review and code review, the companion can help the reviewer challenge a specification, explore edge cases, or understand generated code faster. However, the human still makes the decision.
• When a story cannot converge
  A story that reaches its run limit tells us something useful: the problem was less deterministic than we thought.
  At that point, the team switches back to companion mode, works through the ambiguity, and then sends the story into the pipeline again once the problem is understood.

Over time, this creates a healthy pattern. Work starts as companion-based exploration. Once the team understands it, they standardize it and move it into the pipeline.
As a result, the pipeline absorbs what has become repeatable, while the companion remains focused on genuinely open problems.

The trade-offs: companion alone, pipeline alone, or both

Choosing between the two models isn’t only about the type of problem. Each option has a different cost profile, and the combination isn’t free either.

Read as a whole, the table tells a simple story. The companion alone optimizes for getting started: it’s cheap, fast, and excellent with ambiguity, but its speed and quality are capped by the person using it, and very little of what it produces is traceable.

The pipeline alone optimizes for throughput and consistency. It pays for that with real upfront effort and a higher AI cost per task, since every stage starts from a fresh context and every loop is another run. Its weak spot is ambiguity: a story that isn’t understood doesn’t fail fast, it cycles until it reaches its run limit.

The combination gets the best of both, but it asks for something the other two don’t: discipline in routing. Someone has to decide which path a story takes, and the team has to resist the temptation to skip the pipeline when a deadline is close. Our routing rule is the one above. If you can’t write the spec yet, the story isn’t ready for the pipeline.

A first real data point

On a pilot project, we migrated a jBPM process flow to Spring State Machine while keeping the existing UI unchanged.

The pilot setup

We ran it twice from the same technical analysis, each time with one engineer: once with the companion alone, and once with the companion and the pipeline together.

The difference was the backlog. With the companion, the engineer wrote 6 user stories. For the combined run, an AI agent generated the backlog from the same analysis, following directives designed to make each story pipeline-ready. It produced 13 smaller stories.

Before (companion alone): 6 stories, 12 working days, about 96 hours of human effort.

After (companion + pipeline): 13 stories, 15.2 hours of AI execution costing about $180, and 30 hours of human effort: at most 4 hours to onboard the project plus 26 hours of review. Onboarding covers the repository, the two build pipelines (one for the spec branch, one for the feature branch) and the project’s setup in the pipeline’s administration.

Pilot before and after: 96 hours of human effort with the companion versus 30 hours with the companion and the pipeline, 12 working days versus under 6, $180 of AI cost.

That’s more than two thirds less human time. Even if onboarding, every AI run and every review had happened one after the other, the project would have taken about 45 hours: under six working days instead of twelve.

The AI side cost about $180, or roughly $14 per story. To cancel out the gain, it would have had to cost more than the 66 hours of engineering time it saved.

Because the work was cut differently, story counts can’t be compared directly. Both backlogs covered the same scope, though, so we can normalize to the pipeline’s story size: the companion approach cost about 7.4 hours per story, against 2 hours of human review in the pipeline.

The finer split isn’t a detail. Small, well-defined stories are what make each stage of the pipeline fast to run and quick to review, and producing them was the backlog agent’s job.

One pilot isn’t a benchmark. The figures above don’t include the effort of generating the backlog, and a migration with a solid technical analysis is close to the ideal case for a pipeline. But that is also the lesson. The pilot is the combined approach described above: the technical analysis and the backlog agent did the shaping upfront, and that is precisely what makes the pipeline effective.

Putting numbers on it: a model at scale

One project tells you what happened once. To reason about a whole portfolio, here is a simple model.

The assumptions behind the model

Two values come from the pilot:

• approximately 7.4 hours per well-bounded story with the companion;
• approximately 2 hours of human review per story in the pipeline.

Everything else is an assumption. The model counts human hours only; AI cost is small enough next to them that leaving it out doesn’t change the picture.

Now take 100 user stories:

• 70% well-bounded, similar to the pilot;
• 30% ambiguous.

Where the pipeline pays off: cumulative human hours by number of stories, where both pipeline options break even within the first two stories and the gap then widens with every story.

Two things stand out. First, onboarding a project takes at most 4 hours, so both pipeline options pay for themselves within the first two stories. The break-even point hardly matters; the slope does. The companion costs about 8.8 hours for every additional story, forever. The combination costs about 3.2. Second, the pipeline alone captures only part of the gain: at 5.9 hours per story, forcing ambiguous work through it costs more than handling that work with a companion first.

That’s how we measure the value of this work: not by what the pipeline delivers today, but by how much each improvement to it lowers the cost of every story that follows. A better spec template, a sharper review standard, or better backlog directives isn’t a one-off gain; it reduces the slope.

What’s next

The next evolution of the pipeline is about keeping the spec honest. Sometimes a remark during code review isn’t really about the code: it reveals something the spec missed, like an edge case or an intent that wasn’t captured precisely. We’re now working on routing those spec-level findings back to spec writing, so the spec remains the single source of truth throughout the story’s lifecycle, not just at the start.

It’s also a good reminder that a pipeline like this is never finished; it evolves with what it teaches you.

The architecture lesson

This approach connects to a principle I keep coming back to: AI should handle what is genuinely non-deterministic, while everything deterministic should stay deterministic.

The pipeline itself follows that rule.

Story selection, branching, builds, run limits, stage transitions, and merge are conventional, predictable engineering.

By contrast, we use AI only where interpretation or generation adds value: writing the specification, generating code, and reviewing implementation against intent.

Finally, humans sit exactly where accountability matters.

That is the real shift from Companion to Pipeline.

It is not about using more AI. It is about being deliberate about where AI sits, what we trust it to do, and who ultimately owns the result.

Ready to move from AI-assisted development to AI-powered software delivery?

The spec-driven model described in this article isn’t just a concept. It’s the approach behind Sofya, CBTW’s AI Software Factory.

With Sofya, developers no longer need to manually code every ticket. They specify, challenge and validate, while a specialized chain of AI agents generates code, tests and documentation according to your engineering standards.

The result: faster delivery, less manual production and greater control at every stage of the software lifecycle.

Ready to industrialize AI-powered software delivery? → Discover Sofya, our AI Software Factory