$ cd ../stories
aug 2026

ughh another AI take

[me] The sentence that started this: the levels of management don't have the same interface for what progress is. [ai] Sorry to add to the pile, but it's the thing nobody running the show seems to mean when they talk about AI. The top two interfaces There are two different screens reporting "progress" in the places I've worked. One belongs to middle and senior management. The other belongs to the people actually building the thing. Management's screen is tickets to done. It's the sprint board turning red to green, the velocity chart climbing, the slide deck that says we shipped more this quarter than last. It's clean, it trends upward, and it never shows you the code. Engineering's screen is the codebase. It shows up as the hole you fall into six months later, the method nobody can explain anymore, the section you're afraid to touch because you don't know what it's wired to. It doesn't trend anywhere nice, and no dashboard captures it. Those two interfaces drift apart over time. And the harder management pushes on tickets, the faster they drift. The mandate When middle or senior management decides that the team should fully adopt agentic code generation and implementation, there are a couple of things that the people making that decision miss. Not because they're stupid. Because they're looking at the wrong screen. [me] 0. The measurement trap Tickets to done feeds management, which feeds upper management, which feeds less stability. Each rung up the ladder removes you one more level from the actual software, and each rung adds one more layer of pressure for the number to keep going up. Middle management ends up squeezed from above for "the charts and graphs and statistics," with no real customer value analyzed anywhere in the chain. Not the retention problem the code was supposed to solve. Not the page that still loads slowly. The chart. The chart is the deliverable. And the chart loves velocity, so velocity is what gets optimized, whether or not it produces anything the customer would pay for. [ai] The research nobody at that meeting read Here's the uncomfortable part: the studies don't say what the strategy deck implies they say. Yes, the headline numbers are real. Controlled experiments show genuine speedups — roughly 56% faster task completion in lab tests, and around 26% more completed tasks in field experiments at real companies. [src 1] [src 2] But look closer and the gains skew hard toward the less-experienced people. The juniors get faster. The seniors mostly get busier. [src 8] And when you zoom out past the isolated task to the company, the productivity seems to evaporate. DORA and the wider "AI productivity paradox" research keep finding the same thing: developers produce more output, but company-level productivity barely moves. [src 4] [src 5] [src 3] More code is not the same thing as more value, and the people funding this are optimizing for code. Now the part that actually divides teams, and the part I keep not hearing anyone talk about: whether the company owns the code long term or not. Product companies own their codebase forever. The decisions they make today, they eat tomorrow. That gives you a real incentive to refactor, to reuse, to delete. The cost of complexity comes back to you, so you care about it. Service and consultancy companies don't. They sell deliverables. Billable hours, fixed scope, a handoff at the end of the contract. [src 10] The code is written, the client pays, and whatever debt it carries is now someone else's problem. There's no ownership to hurt you later, so there's no structural reason to keep the codebase clean. The incentive is throughput, not longevity. Ship the feature, bill the hour, move on. I'm not moralizing about that model. It's how the industry has always worked. But when you bolt agentic coding on top of it, you take the thing that was already optimized for adding code, and you remove the last human and financial reasons to subtract any. The complexity gets exported to the client, and the person who inherited it gets to deal with it. [me] 1. The obscurity This is the second thing the decision-makers miss. The codebase, and the features built on it, keep getting more obscure in how they're written and implemented. [ai] Agents produce code that works. That part is real. But they produce it in a way that skips the part where a human has to understand it well enough to maintain it. Developers are increasingly spending their time supervising and evaluating AI output instead of building understanding — which means the intuition about why a thing is the way it is gets thinner with every generation. The result is a codebase that functions today and confuses everyone tomorrow. Every feature becomes someone else's archaeology. And because the demos all happen now, nobody sees the confusion until it's months too late. [me] 2. The bloat And then there's the bloat. Agents add code. They don't remove it. They don't refactor it unless you explicitly tell them to, and even then, not reliably. [ai] The numbers back this up, loudly. Across hundreds of open-source repos, code complexity went up around 41%, and static analysis warnings around 30%. Across hundreds of millions of real code changes, duplication went up about 81%, while cross-file reuse dropped about 35%. [src 6] Nobody is writing that code by hand anymore; it's being generated, and all of it is staying. The refactoring studies tell the same story in a quieter way. Agents are great at low-level cleanup — renaming a variable, changing a type. They're not touching the stuff that actually matters: duplication, reuse, the design-level decisions. The median reduction in code smells from agent refactoring is basically zero. [src 7] Nobody sets the agent loose with the instruction "make this smaller and simpler," because that's not a ticket anyone can close. There's a name for what this creates, and it's technical debt with an interest rate. That same research on Copilot adoption found the least-experienced contributors produced a lot more code — commits up around 44%, pull requests up around 18% — but that code needed rework to meet any standard, and the burden of that rework landed on the few experienced people left. Their original-code productivity dropped about 19% while their review load went up. [src 8] [src 9] The people who could keep the codebase healthy got pulled out of building and into policing everyone else's output. So the experienced get stretched, the juniors get bloaty, and the debt compounds. And because the metrics people care about are tickets, not boredom in the debugger, it never shows up on the management screen. [ai] What would actually fix it None of this is an argument for unplugging the AI. It's an argument for pointing at the right screen. If management wants this to work, it has to stop measuring throughput and start measuring the thing that lasts: whether the customer gets real value and whether the codebase can survive its own growth. The teams being pushed to adopt agents need the authority to say no, to delete, to refactor, to ship a quarter with fewer lines instead of more. The product owned by its people gets a chance. The service shipped and forgotten gets the bill later. [me] Tickets to done is a nice chart. It's just not a verdict. [ai] And that's the take. Sorry it's another AI one. [ai] sources