For funded product teams on a TypeScript monorepo

Roughly double your shipping capacity. Without hiring anyone.

Measured against a traditional IDE-assistant workflow. We show you the numbers, and how they were measured, before you sign anything.

We put the agent-first system our own engineering runs on into your repo. About a month, and we do the work. Quality enforced by machinery, not promises.

01 / The problem

You bought the AI tools. The roadmap still slipped.

Because a licence was never the missing piece. Two things were, and they need different fixes.

Your codebase isn’t ready for them

Agents flail in a repo that was only ever built for people who already know it.

The context an agent needs lives in three people’s heads, not in the repo.
CI takes long enough that agents lose the thread mid-loop.
Every branch needs its own database, ports and environment. Setting those up by hand is nobody’s job, so people wait their turn instead.
Nothing catches a plausible-looking mistake until a human happens to read it.

Your developers haven’t changed how they work

The licences arrived. The way work actually happens stayed exactly the same.

AI gets used as faster autocomplete, not as a development process.
No spec, no plan. Straight to prompting, then debugging whatever came back.
Nobody was taught how to delegate a task well, or how to check the result without reading every line.
Your seniors absorb the difference. They cannot review output at the rate agents produce it, and they know it.

And underneath both, the thing nobody says out loud: you don't fully trust the code the agents write.

Neither gap closes by buying something. Both need engineering work and a change in how people work, and your team has no time for either, because they're busy shipping. That's the trap: too busy shipping to get faster.

02 / The outcome

What it looks like on the other side

Parallel work, and a fast loop: One command gives any developer or agent their own database, ports and environment. Test time follows the size of the change, not the size of the repo.
Coverage that means something: Tests are written against the agreed plan, not to move a percentage. If a change can break something, something fails.
Seniors read verdicts, not diffs: The machinery reviews first and escalates only what needs a person.
The repo explains itself, and its history: A new hire or a fresh agent is productive on day one. Plan, issue, PR and commit stay linked, so blame answers why, not just who.
Agents can see the running system: We wire your services and logs into an MCP server built for your stack. An agent chasing a bug reads the real logs instead of guessing.
Your developers work differently: They specify before they prompt, delegate with intent, and verify by machinery rather than by reading every line.

You merge agent-written code without that feeling in your stomach, not because you trust the model, but because you can see what checked it.

You'll know it landed when the complaints change

An engineer will tell you their laptop is too slow. Nothing regressed. They just have five agents building and running test suites at once on a machine specced for one person typing. That is the good problem. The constraint moved off your people and onto hardware, which is the cheapest thing you will ever buy.

03 / The offer

Three steps. One month to install. Done for you.

Step 1
Harness Maturity Assessment
Fixed price. Delivered in days.
We map your repo against a seven-phase harness maturity model. You get a maturity map, a prioritised gap list, a diagnosis of where you are losing agent productivity, and what it is worth to fix. Mostly async, plus one working session.
You keep the report whether or not you continue. If you do, its price is credited toward the program.
Step 2
The Retrofit Program
About one month.
Two things at once. We install the system, with agents doing the work between sessions, while your team keeps shipping. And we teach your engineers the loop, on their own backlog, leaving them a playbook written for your repo.
Week one you see the first piece working: isolated environments and a verify step, before anything else changes. The teaching is part of the program, not an extra. Installing tools nobody uses is how this usually fails.
Step 3
Continuity
Required. Billed quarterly, up front.
We keep your install current: new skills, tighter gates, fixes that came out of other engagements. And we talk once a month about what changed and what to do next.
Three months come with the program. Then twelve months minimum, then month to month with thirty days’ notice. It does not auto-renew. Stop paying and you keep the machinery: it lives in your repo and runs on your CI. You lose the updates and the call, not the gates.

04 / The mechanism

Why this works when the tools didn't

A licence makes one developer faster on one task. Changing what a team can ship takes two things, and most efforts only ever do the first.

The codebase becomes somewhere an agent can work

Readable, isolated, gated. Checks that run whether or not anyone remembers: review before a human looks, tests scoped to the change, environments that can't clash.

The team learns a different way of working

Write the spec before you prompt. Write the plan before you build. Hand work off properly, and check it with machinery instead of reading every line. Taught on your own backlog, not in a workshop.

The install is the part you can see. The second decides whether any of it is still true in six months. That is why it sits in the program, not sold as training on the side.

The delivery model is the demo

We work the same way you will afterwards: one or two days a week on your repo, agents running between sessions. We build it using it. If it didn't work, we couldn't deliver in a month.

05 / How we work

We didn't write this down and hope. We work this way every day.

This isn't a process we wrote up for clients. It's how we work, built under real pressure in a codebase where being wrong is expensive. Here is what a single change goes through, every time. It is also what your engineers are taught to do, and what gets installed in your repo to make each step possible.

01
It starts with a written plan, not a prompt. Read the code, write down the approach, argue about it before any code exists. The expensive mistakes are design mistakes, and this is the cheap place to catch them.
Instead of: Prompting straight at the problem, then debugging whatever came back
02
The task becomes its own worktree, with an isolated database, ports and environment. One command. Nothing to configure, nothing shared with anyone else’s work.
Instead of: Weeks of platform work, plus the collisions you keep paying for afterwards
03
An agent builds it from that plan. Everything it needs is already in the repo: the conventions doc, the skills, the subagents. Nobody feeds it context on the side.
Instead of: Documentation that never survives a deadline, and one enthusiast’s half-built setup that leaves when they do
04
Tests get written against what the plan said the change should do, not to move a coverage number. If the change can break something, something fails.
Instead of: Coverage that climbs while confidence doesn’t
05
Gates run on every change: typecheck, lint, build, and only the tests the change can affect. Minutes, not the whole suite.
Instead of: A platform-team project measured in months, and rarely prioritised
06
Several agents review it before a human opens the diff. Their findings get checked and ranked. The human reads the verdicts and decides.
Instead of: Senior review hours. Every week. Indefinitely.
07
Whatever the model still got wrong has to get past a verifier built to catch it. Not caught by luck, or by whoever happened to be reviewing.
Instead of: Hoping whoever reviewed it was paying attention that afternoon

None of it depends on anyone remembering. That is the point, and it is why a month is enough. It is also all work you would otherwise build and debug yourself, in the gaps between shipping features.

06 / What it costs

How much does it cost?

Better question: what does doubling your shipping capacity cost if you do it by hiring?

Not double the payroll. More. Output per engineer falls as a team grows: more coordination, more review load, more onboarding drag. Doubling what actually ships takes more than twice the people. Fred Brooks wrote a book about this in 1975. Anyone who has grown a team since has felt it.

Example team: eight engineers
To double output, optimistically: + eight more
Senior base salary, US average: $158,361
Fully loaded, each, per year (rounded down): $200,000

Year one, and every year after: $1.6 million

Deliberately conservative. Base salary is the US average for a senior software engineer; the loaded figure adds payroll tax, benefits, equipment and space, then rounds down. In most funded markets it is higher, and equity is not counted at all. Check it yourself: Indeed: US software engineer salaries · levels.fyi: software engineer total compensation.

Plus six to twelve months of recruiting and ramp before the first of them contributes anything.

And if you build it yourself?

Every team that takes agents seriously ends up building some version of this. The only real variable is how you pay for it.

Building it yourself is not free. It is senior engineers working it out slowly, between shipping, and getting somewhere worse a year from now. You are paying for that already. It just does not arrive as an invoice.

We charge less than one of those eight hires, plus a monthly fee to keep it current. It takes about a month, and it makes the engineers you already have faster instead of giving you twice the people and the same bottleneck.

Run the same arithmetic on your own headcount. The numbers change; the shape doesn't. The exact figure is scoped to your repo and quoted on the assessment call.

Also included

New-Engineer Onboarding Pack: The legibility layer doubles as onboarding. A new hire is productive in a day.
Your first three months of continuity: Included in the program, so the install starts current and stays that way from the day we leave.

07 / The terms

We're opinionated. That's most of why it only takes a month.

You are not hiring someone to run workshops. The decisions are made: how work gets specified, how it gets handed off, what has to be true before anything merges. They came from doing this under real pressure, and we don't reopen them for each client.

That is inflexible on purpose. Opinionation is what removes the thousand small decisions a team would otherwise argue out one at a time, in meetings, over a year. Take the argument away and a month is enough.

What you're buying is nearer to a fractional CTO than a contractor: judgement about how your engineering runs, from someone who runs one.

Right fit

You want your team’s velocity to change this quarter, not eventually.
You are willing to let engineering conventions change, including ones people are fond of.
You would rather adopt a system that already works than design your own.
You have someone senior who can say yes without a committee.

Wrong fit

You want a menu of options to evaluate and pick from.
Your conventions are a matter of principle rather than of outcome.
You want to pilot it with one engineer and decide next quarter.
You are looking for extra hands rather than a different way of working.

We run one engagement at a time, so a bad fit costs both of us the slot. If that's what the call turns up, we'll say so on the call.

Who does the work

The operator is Pavel Kudinov. PhD in computer science, and twenty years building engineering organisations, most of them other people’s.

CTO of a Shell-backed logistics company, where I built a 50-person product engineering organisation from scratch: hiring, review, release management. Before that, engineering leadership at a grocery platform Alibaba acquired. In 2022 I was building LLM coding agents for blockchain indexers, before that was a category anyone was hiring for.

I am not going to send you a team. I do the work, with agents, in your repo.

Measured practice, March–July 2026

13 hrs: of tracked engineering a day, sustained across 143 days
~150B: tokens driven through agents in that window
400:1: tokens of context read for every token written

Nobody works a thirteen-hour day for 143 days straight. It is that high because the agents keep going while I sleep and eat. That is the point. And almost none of what they wrote needed a human to fix it afterwards.

Tracked by WakaTime, not by us.

08 / The guarantee

The guarantee is a test, not a promise

At program end we run the acceptance test. Two criteria, both binary, both demonstrated live in your repo.

It ships

A fresh agent takes a real task from your backlog and carries it to a green PR, every gate passing. Off-the-shelf agent, model and version frozen at assessment. No input from us. Nothing to go on but your repo and the harness in it.

It stops bad code

We inject a plausible defect, and the machinery catches it before it could merge.

If both criteria aren't met, we keep working at no charge for thirty days.

Still not met? You get the assessment fee back in full, plus an agreed share of the program fee, and we're done. That share is written into the contract before we start, so nobody is negotiating it in the middle of a bad outcome. Continuity doesn't start billing until the test passes.

We cap it deliberately. "We'll keep trying indefinitely" is not a remedy. It leaves you holding more of a vendor you've stopped believing in, with no way out.

What we need from you

Repo access and a working environment on day one.
One named technical contact who can decide without convening a committee.
The tasks and the pass criteria, agreed and frozen at assessment.

Without those the guarantee doesn't hold. Not as a loophole: the test measures whether your repo can carry the work on its own, and we can't measure that without the repo.

Note what the guarantee is not tied to: a productivity multiple, or how quickly your team adopts. We teach the working loop and we hand over the playbook, but what we warrant is the machinery, demonstrably, in your repo. How far your engineers run with it depends on your people and your codebase, and we won't guarantee numbers we don't control. Anyone who does is selling you something.

09 / Straight answers

The things you're already thinking

“Agent code is slop debt.”: Quality isn't promised here, it's enforced. Gates, review dispatch and verifiers, the same machinery we rely on in our own production work, where being wrong is expensive. And we prove it adversarially: we inject a real defect and show you the gates catching it.
“We already tried AI tools.”: So did we. Tools make one developer faster. This is the system around the tools. The assessment shows you where the tool stopped and the system was missing, in your own repo.
“We're too busy shipping to do this.”: That's precisely why it's done for you. Your team's roadmap doesn't pause; we work on the repo around them.
“Consultants leave, and the value leaves with them.”: Everything lands in your repo, versioned and CI-enforced. The acceptance test is run by a fresh agent with no input from us. If it works, the value is provably in your repo rather than in our heads, and it keeps working after we are gone.
“How much of our time does this cost?”: One technical contact who can answer questions and make decisions. Your seniors for a session to agree the acceptance tasks. That is it. The retrofit is done for you, and your roadmap keeps moving.
“Where does our code actually go?”: Through the model provider’s API. Training on your code is switched off at the account level, and so are the feedback and telemetry paths that could carry it — those upload source as-is if you leave them on. Local session transcripts get purged when the engagement ends, and we keep nothing. We sign your NDA. If you need commercial terms or zero data retention, say so at the assessment and we arrange it before work starts, not after.
“What about giving agents write access?”: Autonomy is tiered by domain risk. High-blast-radius areas stay gated. You set the policy; the machinery enforces it.
“Double the shipping capacity, compared to what?”: A traditional IDE-assistant workflow: engineers with AI autocomplete and chat, working the way most teams work today. Not compared to writing code by hand, and not a claim about your team's ceiling. We walk you through the numbers and the caveats at the assessment.
“Is the continuity subscription optional?”: No. The toolkit keeps moving, and an install nobody updates goes stale. We are not willing to leave one behind with our name on it. The terms are in the offer above. If a required subscription kills the deal, tell us early and we will part on good terms.
“Our stack is unusual.”: Tell us at the assessment. Where the toolkit doesn't fit your repo, we improve the toolkit. That work is included, not billed as custom.

10 / Start here

Start with the map

Fixed price. You get a map of where your repo loses agent productivity, what it costs you, and what to fix first. Take the program and the price comes off it. Don't, and you keep the report.

One client at a time. We'll tell you honestly whether you're a fit.