The 80% Problem
Fast Tickets, Slow Growth
“I feel like a reviewer now. Not a builder.”
A senior engineer told me that in a 1:1 a few months ago. And I haven’t stopped thinking about it.
The AI coding assistant had been doing most of the implementation: first-pass logic, boilerplate, initial test stubs. Her job had shifted. Read what it produced. Catch what it missed. Push it across the finish line. Ticket throughput was up. She was closing more work in a week than she had in a month before.
She wasn’t sure whether this was good. I wasn’t sure either.
Here’s the pattern I keep seeing across my team. Call it the 80% Problem. AI gets an engineer to something that looks 80% done in a fraction of the time it used to take. The last 20% takes about as long as it always has. The edge cases. The design decisions that don’t have a clean precedent. The debugging that needs you to actually understand what the code is doing.
So net throughput goes up. Metrics look great. PR count climbs. Jira burns down faster. If you’re watching the dashboard, everything is working.
But there’s a second number nobody’s tracking. Call it craft growth rate. The judgment you only build by struggling through the hard part yourself. By getting it wrong three times before you understand why the fourth attempt works.
That number is going in the other direction.
When the AI generates the skeleton and the engineer’s job becomes review and correction, the engineer is doing less of the work that builds judgment. They’re checking a machine’s decisions, not making their own. Getting faster at verifying. Not getting faster at inventing.
I use AI tools. My team uses AI tools. This isn’t about whether to use them. It’s about what’s happening to the engineers using them, below the PR count.
In SEA, this pattern has a particular edge to it.
The junior pipeline here is thin. Senior engineers in KL and Jakarta are one LinkedIn message away from a Singapore bank offer, an Australian remote role, a US company paying in dollars. The attrition math is harder before you even add AI to the equation.
The traditional response is to grow your own — hire juniors early, build the mid-level bench yourself over two to three years. But that model depends on juniors doing the hard work that builds judgment. A junior who spends their first two years reviewing AI output instead of building things from scratch is not getting the apprenticeship they need to become the mid-level engineer who stays in year three. They’re getting faster at closing tickets. They’re not learning to carry the last 20%.
Eventually they hit a problem the AI can’t scaffold. A gnarly distributed systems edge case. A product decision with no precedent. A codebase with enough entropy that the AI just hallucinates. They won’t have the reps to push through. In the US or Europe, you hire senior talent from a deeper pool when that gap surfaces. In KL, you’re often waiting eighteen months for the right candidate.
The 80% Problem shows up differently depending on how the engineer is oriented to the tool. I’ve had engineers push back on the AI-first workflow entirely. I’ve learned to read that resistance differently than I used to.
They’re not refusing the tool. They’re refusing to ship code they don’t understand. “I need to know why it works. If I didn’t write it, I’m not sure I do.” They’ll use AI for research, for understanding a library, for testing edge cases. They won’t let it author the implementation and hand them the result.
I used to frame this as friction. Now I frame it as signal about what kind of engineer they’re trying to remain.
On a velocity dashboard, the engineer who leans heavily into AI generation looks faster. The engineer who insists on writing the core themselves looks slower. Neither metric tells you what’s actually accumulating in each of them.
Which means the dashboard is asking the wrong question.
So what’s the EM job here?
I don’t think it’s to impose AI-off days or restrict tool usage. Engineers will — correctly — ignore it.
I think the EM job is to make the distinction visible.
The 80% Problem isn’t that AI does 80% of the work. It’s that the 80% it does is exactly the part that used to build the engineer. AI accelerates getting things done. Whether it accelerates becoming someone who can do things depends entirely on how the engineer is using it.
In 1:1s, the question I’ve started asking is: “What did you write without AI this week?” Not as a gotcha. Not as surveillance. It’s craft growth rate made legible — a way to see whether an engineer is using AI as a tool that extends their capacity, or as a shortcut that’s quietly offloading the work that would otherwise build it.
The answers are telling. Engineers who are growing tend to have a clear answer. They can point to a decision they made, a problem they debugged, a design choice they argued for. Engineers who are drifting toward pure review-and-correct often can’t.
That’s the signal I’m trying to catch early.
The uncomfortable claim underneath all of this: forcing AI-off constraints for junior engineers is not gatekeeping. It’s apprenticeship.
Not as a punishment. Not as skepticism about AI. As a deliberate pedagogical structure — the same reason you don’t let an intern spend their whole rotation summarizing PowerPoints. The constraint is the learning.
A junior who writes 200 lines of working code they fully understand is building something the AI can’t give them. A junior who shepherds 800 lines of AI-generated code through review is closing tickets faster, but the judgment isn’t accumulating at the same rate.
That doesn’t mean AI tools are off the table for juniors. It means the EM has to be intentional about which problems juniors own end-to-end. Where the constraint lives. What the AI augments versus what it replaces.
The dashboard doesn’t tell you this. The 1:1 might.
The senior engineer who said she felt like a reviewer rather than a builder wasn’t asking me to fix anything. She was doing what good engineers do: naming a pattern she’d noticed in herself before it became a problem. Not every engineer has that self-awareness — especially juniors who don’t know what they’re not building yet.
The EM’s job is to hold that awareness on their behalf.
The PR count is real. The engineer underneath it is the thing you’re actually managing.