Writing code got faster. Why didn't the work?
Keyboard: ← → to move, F for full screen, O for overview.

AI · Delivery · Brownfield
Writing code got faster. Why didn't the work?
AI didn't remove the bottleneck, it moved it. In an existing system, the real cost is finding and proving the rules.
Muhammet Şafak
Section 01
Bottleneck
AI didn't remove the bottleneck, it moved it.
One station
It didn't vanish. It moved.
Make writing 3× faster, but leave review and verification where they are, and you haven't tripled throughput.
The author's observation · one team I watched
Output went up; throughput went down.
- ~2×Code outputRoughly double once they leaned on agents
- 6Weeks laterThey were shipping more slowly
- 3×PR queueThe pull-request queue tripled
- 2IncidentsTraced back to changes nobody had read
Delivery pipeline
Throughput follows the slowest station
- 1Step 1: Write
got faster - 2Step 2: Review
- 3Step 3: Integrate
- 4Step 4: Verify
- 5Step 5: Release
Where did the bottleneck go?
It was always expensive; now it's drowning
- ReviewGeneration produces PRs faster than humans can give them real attention; review degrades into rubber-stamping.
- VerificationWriting tests is nearly free; suites fill up with flaky, timing-dependent cases.
- IntegrationMore code means more coupling and more ways for the same message to arrive twice and corrupt state.
DORA 2024 and 2025 reports, as cited in the post
AI is an amplifier, not a shortcut.
Teams with strong delivery practices get more out of it; teams without them ship their dysfunction faster.
When does this not apply?
Know which world you're in
- No downside to protect yet
- Go fast
- No process for a system not yet built
- There's something to keep honest
- Other people depend on production
- The bottleneck moves past the writing
Section 02
Brownfield
So what about a system that's been running for years?
Where the knowledge lives
Greenfield vs. brownfield
| Criterion | Greenfield | Brownfield |
|---|---|---|
| What is "correct"? | You define it | The system already defined it |
| Where is the knowledge? | With you and whoever made the request | In the code, the data, people's heads |
| Cost of a mistake | Reversible | Live data and users pay |
| Dominant cost | Production | Verification |
What moves
What moves isn't code, it's rules.
In brownfield, what moves isn't code, it's rules. An agent is a multiplier where the knowledge is with you, and an assistant where the knowledge is in the system.
Where rules hide
Three places, three ways to dig
Code says what a rule is; usually only people know why.
- Unwritten exceptions in the code3 business rules in 15 lines
- Implicit rules in the datastatus counts, what NULL means
- The reasoning in people's headswas it meant to be this way?
An honest breakdown of one week
Writing code is one day out of five
days, approximate
- Rule discovery1.5
- Actual coding1
- Parity verification1.5
- Edge cases0.5
- Cutover and monitoring0.5
Where an agent is a multiplier, and where it's an assistant
What it speeds up and what it doesn't
- Mechanical conversionTurning one pattern into another; minutes, not hours.
- Reading codeExtracting rules; the output is a list of questions, not an answer.
- Verification toolingScripts that compare old and new, characterization tests.
- Validity of a ruleAn agent finds the rule; it can't tell you whether it's still wanted.
- VerifyingShowing it produces the same results as the old one is the daily work.
- Cutover and coordinationNot technically hard; but it takes up calendar.

How I estimate brownfield work
Four rules
- Count unknown rules, not lines. (pending)
- Spend the first half day on discovery, then give the estimate. (pending)
- Budget at least as much for verification as for production; the ratio comes out around 1:1.5. (pending)
- Write the cutover as its own line item. (pending)
Writing code got faster. Understanding what the years mean did not.

Thank you
Sources: posts on sade.dev and muhammetsafak.com.tr