AI Software Factory: Specs In, Verified Code Out | yaab
yaab
Service · AI Software Factory

An AI software factory, built for your architecture.

Product writes the spec. The factory produces the code, the tests, and the evidence. An engineer approves what merges.

We build and operate a production line on your codebase. It takes specifications written by product, produces the change in the right layer of your system, generates functional and visual tests derived from the acceptance criteria, verifies its own work with an independent check, and stops for human approval. The output lands in your repository and runs in your CI.

The cost per change is the problem

Each change still costs what it cost last year.

Your team adopted AI coding assistants and each developer got faster. Every change still needs someone to interpret the requirement, place it in the codebase, write the tests and review all of it, so the cost per change stayed flat.

A factory changes that. The pipeline produces the code, the tests and the first round of verification, and engineering time goes to deciding what to build and approving what lands.

Tricentis found in June 2026 that 30% of organizations say AI-generated code has grown too large for their teams to test fully.

How it works

What goes in, what comes out, and who approves.

The input is a specification the way product writes it: what should happen, the acceptance criteria, and the scenarios. It describes behavior, and the factory decides the implementation.

For each spec, the factory produces
The change, in the right layer of your system

The pipeline reads your architecture before touching it, so the code lands where your team would have put it, following your conventions.

Functional tests derived from the acceptance criteria

Each criterion maps to a test that exercises real behavior, including the failure paths.

Visual tests where the change touches the interface

On desktop and mobile, with evidence you can inspect.

A traceability record

Which requirement produced which file, and which test covers it.

The run log

What was produced, what was verified, what failed and was corrected along the way.

Trustworthy output
An independent check against weakened tests

The fastest way to make a test pass is to make it check less. Every test the factory produces is reviewed by a verifier that did not write it, looking for assertions loosened, steps skipped, and validations emptied. What looks like that gets blocked, and this applies to visual baselines too.

Trustworthy output
A human gate before anything merges

The factory produces a pull request with the reasoning, the diff, the tests and the evidence, and stops. An engineer approves what enters your codebase, every time.

Ambiguity
And when the spec is ambiguous, it asks

A spec with a hole produces a precise question, and that task waits until someone answers it.

Getting started

From your backlog to a running line.

1
Read

We study your architecture, your conventions and your CI. The factory is built on our harness and adapted to your project: your layers, your test stack, your pipeline.

2
Calibrate

The first specs run with your team watching. Your engineers see where the code lands and how the tests are derived, and correct the line before trusting it.

3
Produce

Specs flow monthly. Each one comes out as a pull request with tests and evidence, and your team, or ours, approves.

4
Extend

New spec types widen the line without rebuilding it. The same pipeline keeps producing as the backlog grows.

What lands

What lands, and how you check it.

The changes, shipped: code in your repository, in your conventions, merged through your review.

The test suites, functional and visual, running in your CI on every change, with evidence attached to every run.

The traceability record per spec: requirement to file to test, auditable without asking anyone.

The pipeline logs: what ran, what was verified, what was blocked and why.

Done means

Every spec's acceptance criteria pass in your CI, functional and visual, and every change entered through a pull request with human approval recorded.

Where it runs

Your codebase, your CI, your conventions.

Inside your existing system

The factory produces changes in a codebase your team already maintains: real architectures, with history.

Your CI

GitHub Actions, GitLab CI, Jenkins, Azure Pipelines, CircleCI.

GitHub ActionsGitLab CIJenkinsAzure PipelinesCircleCI
Mainstream stacks

The line is adapted to your language, framework and test tooling as part of setup.

Your review flow

The human gate runs inside your existing pull request process.

Everything the factory produces is readable code, tests and records in your repository, under your version control. If you stop working with us, everything it produced keeps running.

One family, three entry points

Three ways in, depending on who produces.

The two engagements share foundations and differ in who operates afterward. Codebase is an enablement: it transfers the capability and ends. The factory is a service: it produces every month. Teams move between them in both directions, and a factory client keeps everything needed to take the line's output in house.

Security and access

What we touch.

Everything runs in your infrastructure

Your repository, your CI, your environments.

Least access

And it ends when the engagement does.

Secrets stay out of the repository

Through your secret manager and environment variables, and run evidence is checked so it does not leak them.

FAQ

Questions we get.

QHow is this different from giving my developers AI assistants?

Assistants make each developer faster inside the same process, where a person still interprets, places, writes and reviews every change. The factory takes the spec end to end and produces the change with its tests, traceability and evidence, and your engineers define and approve.

QWho reviews the code?

An engineer, on every change, through a pull request with the diff, the tests and the evidence. The factory never merges its own work.

QHow do I know the tests actually test?

An independent verifier that did not write them reviews every test for weakened assertions, skipped steps and emptied validations, and blocks what it finds. The same check covers visual baselines.

QDoes it work on a legacy codebase?

The factory needs a codebase it can read and a CI to run in. If yours needs modernizing first, that is Legacy Software Modernization.

QWhat size of change goes through the line?

The unit is a product spec: a feature, a rule, an integration, a replacement. Large initiatives enter as a sequence of specs.

QWhat do we keep?

Everything the factory produces: the code, the tests, the traceability records, the evidence. It is in your repository from the first commit.

QWhat does our team have to do?

Define and approve. Your team writes specs with acceptance criteria, answers the questions the pipeline raises, and approves pull requests. Producing the code, the tests and the evidence is our job, which is the difference with AI-Ready Codebase, where your team is the one producing.

Bring three specs from your backlog.

One working session: we take three real changes your team has pending, write them as specs, and walk you through exactly what the line would produce for each. You leave with the specs written and the setup plan.

Everything the factory learns about your system stays as an engineering brain you keep. If you later grow a Company Brain, this is already a module of it.