All Briefs
Mission Brief · 006—·updated

A six-lane highway.
Through an old town.

Your developers got faster. Did your product? AI widened the coding road, and that is where most AI-first stories end. But code is one street. Discovery and analysis still arrive through a narrow lane. Review — now with a security check on every generated change — has a toll booth. Testing has a single-lane exit. A highway with no town around it moves cars faster to the same queue. Change the traffic below and see where the time goes.

+91%
review time in high-AI teams · Faros 2025
No link
AI adoption ↔ org. delivery gains · Faros
QA + product
most of our 2026 hires · the town around our highway
Try the traffic controls
006 · Traffic control

Widen the highway.
Now watch the exit.

Start by boosting coding alone — that is the AI-first pitch. Watch where the cars pile up. Then add product and QA capacity, and finally give Review room. Each car is a task; the result that matters is how many reach customers. All simulator numbers are model assumptions, separate from the research below.

Traffic control · a model, not a forecast
Real speed · delivered
8 / week

Tasks reaching customers, across the whole route.

Ideas in20 / week
Code written10 / week

Felt speed: 3× coding capacity. The highway has room for 24 tasks/week; only 10 reach it and get coded.

Try a route
City limits → customersEnd of week 12 / 12
  1. 01

    Old town

    Discovery, analysis, prototype

    +102 more waiting10 handled / week →
    Spec & prototype10 / week capacity120 waiting before this stage
  2. 02

    The highway

    AI-assisted coding

    10 handled / week →
    Code24 / week capacity0 waiting before this stage
  3. 03

    The toll booth

    Read, challenge, security check, approve

    10 handled / week →
    Review12 / week capacity0 waiting before this stage
  4. 04

    The exit

    Test the whole journey

    +6 more waiting8 handled / week →
    QA / verify8 / week capacity24 waiting before this stage

Moving cars = work processed. Parked cars = waiting tasks (up to 18 drawn per queue). Lane counts and driving speed are illustrative; the capacity numbers drive the calculation.

96 delivered so far · 120 ideas waiting to enter · 24 tasks waiting inside the town (WIP)

Delivered / week8 → 12
All waiting tasks · week 12144 → 96
Of those: WIP inside town24 → 48

QA / verify sets the pace. Turn up coding alone. Then widen the streets around it.

How this model works

One task, one route

Every car is an equal-size task. Empty queues at the start; 12 weekly steps; same-week handoffs. No rework, batching, context switching or delivery delay is modeled. This is flow arithmetic, not a road-traffic or delivery forecast.

The arithmetic

Code capacity = 8 × AI boost. At each stage: handled = min(queue + arrivals, capacity). Unhandled work stays queued. Delivered/week = min(ideas in, Spec, Code, Review, QA).

Count the whole queue

Ideas awaiting Spec are the incoming backlog. Work that has passed Spec but is waiting for Code, Review or QA is WIP. Total waiting = both. Adding capacity may grow WIP at the next constraint even as total waiting falls. It cannot guarantee an empty queue.

Highway only vs highway + town

AI-first is the road.
The town is the product.

Three streets that fast coding does not widen. On the left, what a coding-only speedup looks like from the inside. On the right, what the same work needs once it has to reach a customer — the part that is easy to underestimate when the code is arriving so quickly.

01
Highway only vs Highway + town

Know what to build.

Highway onlyA ticket says 'add export'. The agent builds an export. It is fast, plausible and nobody asked which export, for whom, or what would count as useful.
Highway + townDiscovery before the prompt: who needs it, what they are trying to accomplish, what must not change. A prototype to expose the misunderstanding while it is cheap. Analysis is the street the highway starts on.
Fast code for the wrong thing is the most expensive kind.
02
Highway only vs Highway + town

Read it. Then check it.

Highway onlyPull requests arrive bigger and more often. Review becomes a formality, because there is no time for it to be anything else.
Highway + townEvery generated change gets a reader who understands the system, and a security pass: permissions, injected input, secrets, the failure path. Review time goes up — Faros measured +91% — and that is the job, not a bug. The toll booth is where the product gets its guarantee.
The one wrong line looks like the fifty right ones. Somebody has to find it.
03
Highway only vs Highway + town

Prove it works for a user.

Highway onlyUnit tests pass. The feature is 'done'. The first real user goes from the mobile screen to the admin role to the failed request nobody wrote a test for.
Highway + townTest planning for whole journeys — roles, devices, bad input, timeouts — and people whose job is to break it before customers do. The exit has to be as wide as the highway, or the highway does not matter.
Done means verified. Everything before that is queued.
Where the work actually went

We built the town around our own highway.

Our engineers have been AI-first for two years. What changed in 2026 is who we hire: mostly testers and product people. Not because coding got worse — because everything around it became the constraint. Four things we now say to anyone who tells us their developers got faster.

01
Ask → prototype → decide

Discovery and analysis are where speed is decided.

A highway only helps if the cars are going somewhere worth going. Product people turn requests into shared understanding before code starts, and they cut the features nobody needed — the cheapest speedup there is.

— Product work alongside your team
02
+91% review time · +154% larger PRs

Review and security checks are a real cost. Budget them.

Generated code is long, fluent and confident. Reading it with comprehension and checking it for security — permissions, injection, secrets, failure paths — is slow by design. Give that work a visible queue, an owner and time. Pretending it is free is how incidents happen.

— Faros 2025 · what we look for in a delivery flow
03
Test → reproduce → verify

Testers are the exit lane.

Users move between screens, roles and devices. Tests have to cover those journeys, including failed requests and unexpected input. Our QA people plan and run that verification so faster development has somewhere to go — it is the role we hired for most this year.

— Pirxey hiring 2026 · QA capacity matched to the release flow
04
Useful to whom?

A plausible answer can still miss the need.

On Elite Medical Prep and a real estate product the model suggested things users did not want and asked questions too broad to help. Nobody fixed that with a bigger model. Product people defined useful behavior, testers checked it against real scenarios.

— Pirxey project experience · qualitative, no client metrics
Evidence · what was actually measured

More activity is one signal.
Delivery is another.

These sources measure different things, in different settings. They motivate the questions in this brief; they do not calibrate the traffic model or predict your team's results. The hero figures come from the linked Faros study and from our own hiring.

+47% / +91%
More PR activity; longer reviews.
Faros studied over 10,000 developers across 1,255 teams. High-adoption teams interacted with 47% more PRs per day; review time was 91% longer. It found no organizational-level delivery correlation with AI adoption. Observational results, not proof that AI caused a slowdown.
Faros · Lab vs. Reality, 2025
+9%
More bugs per developer in high-AI teams.
Same Faros study: bugs per developer rose 9% where AI adoption was high. More code, same verification capacity. It is the number behind the single-lane exit in the simulator — and behind who we hired this year.
Faros · Lab vs. Reality, 2025
19%
Feeling faster needs a reality check.
In METR's early-2025 randomized study, 16 experienced developers took 19% longer with AI on tasks in familiar open-source repositories. Afterward, they still estimated a speedup. A historical result for that setting, not a verdict on today's tools or all developers.
METR · randomized study, July 2025
~30 pts
Developers misjudge their own productivity.
Stanford's study of nearly 100,000 developers in 600+ companies found self-assessments of productivity off by about 30 percentage points on average — 'almost as unreliable as coin flips'. Net gains after rework were about 15–20%, and close to zero on complex existing codebases. Felt speed is not delivered speed.
Stanford software engineering productivity study, 2025
≈33%
Technical debt already takes part of the week.
Stripe's 2018 survey reports 13.5 hours of technical debt in a 41.1-hour developer week: about 33%. That figure describes technical debt, not all maintenance, and predates AI coding assistants. See the report's work-week breakdown on page 4.
Stripe · The Developer Coefficient, 2018
QA + product
Most of our 2026 hires are testers and product people.
Our engineers had the highway. What we added this year was the town: test planning and verification, discovery and analysis, review with a security pass. It is the shape of a delivery team once coding stops being the bottleneck — and it is what we bring when we join yours.
Pirxey hiring · 2026
Mission control standing by

Your highway is ready.
We bring the town.

Product discovery, analysis, testing of the whole journey, review and security checks — the people and the process around fast coding. This is where we have been hiring all year. We write custom software. Some pieces are ready-made. We join your team and work alongside it.

Pirxey · Aleja Grunwaldzka 472, 80-309 Gdańsk, Poland·130+ engineers · 100+ missions delivered