Last time I wrote about vibe coders eating my job and how I ended up as the unofficial “vibecode director” at my org. The thing I said at the end of that post — that the hard part was never the building, it was the syncing — turned out to be the part people wanted to talk about.
So I went and wrote the long version. It’s a proper paper, and you can download it here.
The whole thing in one paragraph
You used to hire an intern. You’d spend three months teaching them your coding standards, your UX patterns, the reason you never use that one component, the unwritten stuff nobody documented because everyone just knew. Now that intern is the AI. Same job, same frustration — except this intern never actually learns. You correct it in June and it makes the exact same mistake in August, because nothing you said got written into its head. It only got written into a file. That’s the whole discipline in a sentence: you’re not training a person, you’re maintaining an external memory on its behalf.
Why bother reading the paper
Because the numbers are worse than people admit, and I didn’t want to write another vibes-based take on vibe coding.
A few things I found that genuinely changed how I think about my own setup: Faros AI’s telemetry across 10,000+ developers found high-AI-adoption teams merged 98% more PRs — and review time went up 91%. So the work didn’t disappear, it just moved somewhere nobody’s measuring. Stack Overflow’s 2025 survey found 84% of developers use AI tools, but more of them actively distrust the output (46%) than trust it (33%). And GitClear’s analysis of 211 million changed lines found duplicated code blocks went up eightfold in 2024.
None of that means “AI bad.” It means the sync problem is real, expensive, and mostly unaddressed.
And the part where I argue with myself
I’ll be honest — the most useful thing I found was the study that undercuts my own argument. A February 2026 ETH Zurich paper tested whether those context files everyone swears by actually help. Result: auto-generated ones didn’t improve task success at all, and raised inference cost over 20%. Agents failed not by ignoring the file, but by following it too literally.
That stung a bit. But it doesn’t kill the thesis — it sharpens it. Bloated onboarding docs don’t work on interns either. Short, specific, high-signal instructions do. Anyone who’s actually onboarded a junior could have told you that.
What’s in it
The paper covers where the conventions landed (AGENTS.md as an actual cross-tool standard now, plus Skills and MCP), how to make a design system machine-readable so the agent stops inventing a fourth shade of blue, the failure modes with real numbers, and a four-stage rollout you can actually run. Plus the counterarguments, because a paper that only agrees with itself isn’t worth your time.
Grab the PDF here. It’s free, there’s no email gate, and if you disagree with any of it I’d honestly like to hear why.