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.
We build ForgeCode because every team we know has more worth building than people to build it.
Three 2026 reports, three ways of measuring it.
“individual developer productivity has improved with AI, but the overall software delivery process has not accelerated at the same pace”
“Throughput on the main branch, however, declined 7% from last year”
“AI adoption is up 65%. Throughput moved less than 8%.”
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.
Four beliefs we hold about engineering work.
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.
Handoffs, waiting and status meetings eat more time than writing code. Work that needs no meeting should not wait for one.
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.
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.
Our own changes are planned, built, reviewed and deployed with ForgeCode. If something annoys us, it gets fixed before it reaches you.
One reviewed commit per change, landed on trunk and deployed on push. Small changes are easy to review and easy to undo.
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.