Skip to content
Little Lab Rats
Delivery platform

How a Slack message becomes shipped software

We built an AI-augmented delivery platform and we run our own projects through it. Eight modules take a request from someone typing a command in Slack all the way to a deployed release, with a schema contract enforced at every handoff.

Modules
8, plus telemetry
Review agents
6 per specification
Schema contracts
16 enforced
Status
Running in production
The problem

Going faster should not mean earning less

In a lot of software contracting, work is billed by time and materials. The uncomfortable arithmetic of AI-assisted delivery is that under that model, productivity is a liability: if a team delivers in six person-months what used to take ten, the invoice drops by forty percent for the same delivered software.

That is a bad incentive to build a company on. So we built for the opposite model. Under fixed-price delivery, the same compression is margin rather than lost revenue, and the client gets working software sooner. But fixed price only works if you can define scope accurately and defend the result — which is an evidence problem, not a speed problem.

Nearly everything below exists to produce that evidence: typed requirements traced to their sources, specifications reviewed by independent models, test cases written before implementation, and an audit trail emitted at every module boundary.

The pipeline

Six stages, eight modules

  1. 01Intakemodule-01

    Someone types one command in Slack. The platform gathers every source that mentions the keywords and acknowledges in under three seconds.

  2. 02Extractmodule-01

    Gemini reads every source and returns typed requirements with confidence scores. Anything it is unsure about becomes an open question rather than a guess.

  3. 03Assemblemodule-02

    Six agents turn requirements into a specification, a work breakdown, a MoSCoW split, and executable test cases. Two of them exist only to review the other four.

  4. 04Buildmodule-03

    Work is routed by type to the model that handles it best, each with a fallback chain. Every task arrives pre-sized: nothing larger than a two-hour change.

  5. 05Reviewmodules 04 + 05

    Security runs before code review, not after. A failing scan blocks the pull request outright, and the fix loop gets three attempts before a human is called.

  6. 06Shipmodules 06 + 08

    Deploy, close the ticket, notify the channel. Every module boundary emits a completion event, so the whole run is auditable after the fact.

The review layer

Four agents write. Two only review.

A single model marking its own homework is not a review. The two reviewers run on different model families and return an explicit verdict, and a block stops the package from moving downstream.

A1

Spec author

Turns extracted requirements into a specification with acceptance criteria, and flags every ambiguity it had to resolve.

A2

Work breakdown

Splits the specification into items sized xs (under thirty minutes) or s (under two hours). Anything still medium gets split again.

A3

MoSCoW classifier

Sorts the work into must, should, could, and won't, so scope conversations happen before code rather than during it.

A4

Test-spec generator

Writes executable test cases against the acceptance criteria, before any implementation exists to bias them.

A5

Spec reviewer

Reads the whole package and returns pass, warn, or block. It produces nothing else — reviewing is its only job.

A6

Independent reviewer

The same review from a different model family, checking executability, security, and determinism. Two families rarely share a blind spot.

330

Test functions across the two core modules

84.39%

Median token reduction on paired live runs

≤120s

Meeting to draft requirements, p95

16

JSON schemas enforced between stages

On the numbers

Where these figures come from

The token reduction figure is a median across paired runs measured internally: the same task executed with and without our context retrieval layer, 44,669 tokens against 6,971. It is a real measurement on our own workload, not a benchmark, and your codebase will differ.

The 120-second figure is a p95 target for the intake stage — from the Slack command to a draft set of requirements — with the acknowledgement itself returning in under three seconds. The test count is literal: test functions in the two modules that carry the specification and implementation logic.

We would rather publish a number we can source than a rounder one we cannot. If you want the methodology behind any of these, ask and we will walk you through it.

Want to see it run on your problem?

The most useful version of this conversation starts with a real requirement of yours. Send us one and we will show you what comes out the other end.

hello@littlelabrats.com