FaberSEP

Software Engineering Platform · for agencies

AI speed, without the spaghetti code.

Vibe coding is fast until someone has to maintain it. FaberSEP holds AI-written code to the standards of a senior engineering team: the architecture is designed before the code, every change is reviewed against your coding rules, and the code health of every merge is measured.

Join the waiting list See what is enforced

Pilots with a small group of agencies start in early 2027.

01 — The problem

Vibe coding ships fast. Then someone pays for it.

Coding agents produce code in minutes. Left to themselves, they also produce thousand-line files, logic copied into five places, tangled dependencies, and conventions that change from one session to the next.

Agencies sell maintainable software at a fixed price or on a retainer, so that debt comes out of the margin: in rework, in review time, in bugs the client finds, and in a codebase nobody wants to pick up a year later. FaberSEP makes engineering discipline part of the pipeline, so speed does not cost you the codebase.

02 — Standards

Standards are enforced, not suggested.

A rule in a prompt is a wish. In FaberSEP, standards are built into the pipeline: checked by its gates, measured on every change, and in front of the person who merges.

Architecture first
Designed before it is built.

An architect step writes the blueprint, and you approve it before any code is written. The code follows the design, not the other way round.

Coding rules
Every change reviewed twice, plus a security review.

Reviews check naming, structure, function and file size, duplication and error handling against your project’s rules and the code around the change. Blocking findings go back to the coder until they are fixed.

Code health
Measured on every merge.

Long files, long functions, deep nesting, duplicated blocks and import cycles are counted before and after each change, against limits you set. You see which change made the codebase better and which made it worse.

Tests
Behaviour specified, then proven.

Each feature has BDD scenarios before it has code. A feature is accepted only when the full test run passes and every scenario has a test.

Building blocks
Proven recipes instead of improvisation.

Common capabilities come from checked recipes, each one applied to a fresh project, built and tested before it is released.

Memory
Mistakes are made once.

Lessons from rejected work become project rules that later reviews check against, once a person approves them.

03 — How it works

One path for every change.

The process is not a suggestion to the model. It is the only path a change can take, and a person decides at every gate.

  1. 01

    Refine

    A vague request becomes a precise one. The model asks its questions with a recommended answer for each.

    Approve the idea
  2. 02

    Specify

    A product requirements document and BDD scenarios that later become the tests.

    Approve the spec
  3. 03

    Design

    An architecture blueprint. Small features get the complete code; large ones get a task plan.

    Approve the design
  4. 04

    Deliver

    One job per task, in its own git worktree. Failures go back with structured findings until the gates pass, or a person is asked.

    1. baseline
    2. code
    3. build gate
    4. review
    5. QA tests
    6. test gate
    7. second review
    8. security review
    Merge, or reject with a critique
  5. 05

    Accept

    A full test run, and a check that every BDD scenario has a test.

    Accept the feature
  6. 06

    Learn

    Lessons from rejected work become project knowledge, and a behaviour change proposes a spec update.

    Approve each entry

04 — Cost

A lower cost per feature, and the receipts.

Rework

Problems caught before the client sees them.

Builds, tests and reviews run on every change, so defects are fixed at the gate instead of after delivery, when they cost the most.

Tokens

Only the code that matters goes to the model.

A map of the codebase gives each step the files around the change, within a token budget, instead of the whole repository.

Models

The right model for each role.

Choose a model per role with your own provider keys, so routine steps run on cheaper models, with failover when a provider is down.

Visibility

Every model call has a price.

The cost of each call is recorded and added up per task, next to the human time it took. You know what a delivered feature cost.

05 — Specification

The details.

Built for
Software agencies and in-house teams delivering for clients
Stacks today
Flutter · Node.js with TypeScript · React · ASP.NET Core
Runner
Your code stays on your machines: one docker run command on macOS, Linux or WindowsOpens no port on your machine; the tunnel connects out.
Models
Your own provider keys, a model per role, failover, cost per call
Version control
GitHub · GitLab · Azure DevOps
Agents
An MCP server connects the coding agents your developers already use to the same specs, tasks and gates
Open source
Recipe Catalog and Code Intelligence, Apache-2.0

Pilot programme · 2027

Join the waiting list.

We are starting with a small number of agencies. Tell us about your team and your stack, and we will be in touch when a place opens.

Join the waiting list