About us

Output should scale. Headcount should not

We build ForgeCode because every team we know has more worth building than people to build it.

The problem

Developers got faster. Delivery didn't

Three 2026 reports, three ways of measuring it.

79%agree
“individual developer productivity has improved with AI, but the overall software delivery process has not accelerated at the same pace”
GitLab, AI Accountability Report, June 2026Harris Poll, 1,528 developers and tech buyers
+15%feature branches−7%main branch
“Throughput on the main branch, however, declined 7% from last year”
CircleCI, 2026 State of Software Delivery, Feb 202628M+ CI workflows, median team
+65%AI usage+7.76%PR throughput
“AI adoption is up 65%. Throughput moved less than 8%.”
DX, AI and Engineering Velocity, April 2026400+ companies, median PR throughput

Why we build

For decades the only way to ship more software was to hire more engineers. Each hire adds output, and also meetings, handoffs and on call rotations. Output grows slower than the team, and the team grows slower than the backlog.

We built a coding assistant ourselves and saw this from the inside: faster typing does not shorten the queue of reviews, releases and incidents. We think that queue can be cleared without adding people to it.

Our answer: hand the rest of the SDLC (testing, releases, incident response, upgrades) to a factory that runs continuously, while people decide what is worth building and own the outcome.

What we believe

Four beliefs we hold about engineering work.

  1. 01

    Humans set goals and stay accountable

    Software can do the work; it cannot own the result. People choose the goals, weigh the trade-offs and make the final call, including on the guardrails that follow a post-mortem.

  2. 02

    Coordination is the real cost

    Handoffs, waiting and status meetings eat more time than writing code. Work that needs no meeting should not wait for one.

  3. 03

    Passing tests are not proof

    CI shows the code does what its tests say, not what was asked. Every change should be checked against a written spec, its tests reviewed for whether they prove anything, and critical logic verified formally where it can be.

  4. 04

    Tools should get better with use

    Every run should leave something behind: a procedure, a memory of the codebase, a sharper check. The hundredth task should go better than the first.

How we work

use it first

We run on what we build

Our own changes are planned, built, reviewed and deployed with ForgeCode. If something annoys us, it gets fixed before it reaches you.

small batches

Ship to main, every day

One reviewed commit per change, landed on trunk and deployed on push. Small changes are easy to review and easy to undo.

write it down

Decisions live in the repo

Designs, trade-offs and post-mortems sit next to the code, so anyone can see why something is the way it is.

In practice, these beliefs became a software factory. See how it works.

The people building it

A small team, on purpose.

Build with us

If these beliefs match yours, log in and try them on your own work.

Log in