As AI Writes 90% of Code, Programmers Focus on Problems, Not Typing

Eight months ago, a software engineer was producing 90% human-written code and 10% AI-written code. By the time of writing, that ratio had flipped: their codebase is now roughly 90% AI-written and 10% human-written. To understand what this shift means for the work itself, the engineer walks through a concrete example: optimizing a GPU matrix-multiply kernel.

Matrix-multiply kernels are extraordinarily complex pieces of code. Modern GPUs like the latest Nvidia models dedicate enormous resources to matrix operations—north of 96% of floating-point operations happen in tensor cores, which deliver 2250 teraflops in bfloat16 matrix multiplications compared to only 75 teraflops for all other operations combined. Yet despite this hardware specialization, writing kernels to use all that performance is notoriously difficult. The particular kernel the engineer was optimizing used Cluster Launch Control (CLC), a hardware feature not widely documented, and it had strange interactions with certain inputs.

The engineer's process broke into nine distinct steps. First, they identified the problem: coworkers reported slow matrix multiplications, profiling showed idle tensor cores, and targeted benchmarking revealed that slightly different inputs gave big speedups. At step one (finding the code), the engineer asked an AI to locate the relevant section of a large library. The AI found it first and pointed to the exact lines, even confirming that the team's initial theory about the problem was plausible. At step two, the engineer deliberately did not ask the AI for help while reading the code themselves. They discovered that the team's theory was only partially correct—the real issue was that the kernel was exiting CLC mode and handing control back to the hardware scheduler, a slower path.

At step three, the engineer needed to create a monkey-patch to test the fix (the fastest way to iterate in Python-based neural network training). They asked the AI to set up the boilerplate. Their first fix attempt caused a deadlock. Rather than spend hours understanding the surrounding pipelining code, they asked the AI to diagnose the issue. The AI immediately identified the problem: the engineer was violating an invariant where pipelining logic also reasoned about CLC state. The AI suggested using one unused slot of shared memory (reserved for unknown reasons and entirely unused) to track the now-separate CLC state. The engineer estimates this understanding would have taken them hours or a full day; they asked the AI to implement the fix, and it worked immediately and significantly sped up the problematic inputs.

At step five (review), the engineer spent time understanding the change, then asked a second AI to review the first AI's work. The second AI found a potential bug: the kernel was clobbering other state, which would be fine during normal shutdown but problematic with CLC if valid tokens arrived after padding tokens. The first AI worried this could cause issues because CLC documentation does not guarantee ordering. The engineer proposed a simpler fix than the AI suggested; the AI agreed. The engineer also added an assert to test whether valid tokens ever arrived after padding tokens. At step six, they asked an AI to write a benchmarking script. The script did not reproduce the initial issue, so they asked the AI to reproduce the exact inputs from production—tedious manual work made efficient by AI.

At step seven, the engineer asked the first AI for additional optimization ideas. The AI suggested four ideas beyond the engineer's own idea; one tiny change sounded especially promising. Both the AI's idea and the engineer's idea sped up the code further. The engineer chose to keep only the AI's smaller change, deciding their own idea, though slightly faster, was too complex. At step eight, a code review tool found a problem: the engineer had replaced an assert with a print statement (not wanting the code to crash over idle curiosity), but review flagged this as wrong since the code assumed CLC work arrived in order. This contradicted extensive earlier conversations with two AIs where the engineer had tried to avoid that assumption.

At step nine (simplification), the engineer had careful conversations with multiple AIs to determine exactly what assumptions the original code and new patches introduced. They decided to accept the assumption that CLC work arrives in order, which simplified the code. The AI did an adequate job simplifying; the engineer refined it further. Throughout this entire process, the engineer was in constant conversation with multiple different AIs, asking questions about the code, requesting ideas, generating new code, and using AI for review. They consumed far more tokens per day than even a few months earlier.

Overall, the task took four days. The initial implementation alone took just under a day, whereas the engineer estimates it would have taken two or three days without AI. However, the full cycle—including benchmarking, careful review, and code simplification—took only about one day less than the estimated five days without AI. The engineer notes this is because "writing code" has not been their bottleneck for years; the real time sinks are understanding, benchmarking, and decision-making. The engineer did produce higher-quality work by some measures: they tried more optimizations and created plots showing how each behaved. But they also understand the kernel less deeply than they would have if they solved it alone. The AI caught many subtle bugs during review—memory leaks, state clobbering, undocumented assumptions—which the engineer found humbling. The engineer now believes most software is subtly broken in edge cases, and that AI-assisted code review might make software vastly more robust than manual review alone, even if the code itself is still written by hand.

The engineer's account reveals a paradox at the heart of AI-assisted coding: speed gains in implementation do not necessarily translate into proportional gains in overall productivity. The reason is that writing code—the part AI has made dramatically faster—was never the bottleneck. The engineer explicitly notes that they have long felt "writing code" is not their limiting factor, citing the old software engineering principle of ten lines of code per day from the Mythical Man Month. What actually consumes time are understanding the problem, benchmarking solutions, reviewing code for correctness, and making architectural choices. AI helps with some of these (e.g., writing benchmarking scripts, pointing to relevant code), but the engineer still had to spend days on the non-coding parts.

A secondary theme is the quality paradox: the engineer produced higher-quality work in some metrics (more optimization attempts, better visualization) but with reduced personal understanding. This matters because the engineer's decisions about competing AI suggestions—whether to simplify the fix, whether an edge case was real—required them to read and reason about the code themselves. Had they trusted the AI completely, they would have made worse choices. The engineer explicitly states they do not trust the AIs to get complex reasoning "completely right." This suggests that AI's real value in coding may depend on a human's ability to be skeptical and to understand the domain well enough to catch AI mistakes—a skill that becomes harder to develop if you rely on AI for implementation.