AI Code Generators: Real Productivity, Real Risk

In 1952, Grace Hopper built the first compiler and got absolutely roasted for it. Real programmers wrote machine code, the critics said. Compilers were for people who weren't smart enough. They'd make us lazy. They'd make us forget how to actually program.

That argument lost. Spectacularly. And then, with impressive consistency, it ran back the exact same play for high-level languages, IDEs, garbage collection, and autocomplete—each time with the same energy, the same prophecy of deskilling, the same eventual defeat.

IBM Technology's Bri Kopecki opens a recent explainer with this history not to mock the critics, but to contextualize where we are now. "In 2026, we're having the exact same argument about AI code generators," she observes. "Same energy, same arguments, just with 60% more Hacker News comments."

What she doesn't do is tell you which side to be on. Neither will I. But there's something worth sitting with here: according to Stack Overflow's 2025 Developer Survey, 84% of developers are already using or plan to use AI coding tools. The debate about whether this should happen is largely settled by the fact that it already has. The more interesting question is what it actually means—for individual developers, for teams, and for the organizations depending on the code that comes out the other end.

The Translation Frame

The most useful thing Kopecki does is reframe what these tools actually are. "AI didn't learn to write code," she argues. "It learned to translate it."

The framing holds up. Software development has always been a chain of translations: human intent becomes formal logic becomes code becomes machine instructions. Every generation of tooling pushed that first translation step a little further from the machine. AI code generators push it to natural language—you describe what you want, and the model generates something that should do it.

Under the hood, this is a large language model trained on enormous repositories of existing code, primarily open source. The model doesn't reason about your problem the way a developer does. It finds the most statistically likely continuation based on patterns in billions of prior examples. As Kopecki puts it: "It doesn't know. It predicts."

That distinction—prediction versus understanding—is load-bearing. It's why these tools are genuinely useful for the vast majority of tasks and genuinely dangerous for a specific subset of them. The model has absorbed more Python than any human alive. It's also absorbed every bad pattern, deprecated API, and security antipattern that ever made it into a public repository.

The bidirectionality is worth noting too. Hand an LLM a 400-line function nobody's touched in five years and ask what it does—you get plain English. Feed it COBOL and ask for Java. Feed it broken Python and ask for fixed Python. The translator, as Kopecki frames it, goes whichever way you point it.

What's Actually Getting Better

The productivity case is real, even without pinning it to specific numbers that can't be sourced. The shape of the change is legible even qualitatively.

Boilerplate evaporates. The JSON parser you've written fifteen times, the regex you used to burn an hour on Stack Overflow finding—the model handles it. Nobody remembers the exact syntax for a Kubernetes manifest; now nobody has to. Developers report spending more time on the work that actually requires human judgment: architecture, design, the hard tradeoffs where context and consequence matter.

For junior developers, the shift is particularly significant. Kopecki's analogy: pairing a junior with an AI coding tool is like giving them a senior engineer available around the clock—one who never sighs when they ask a basic question. Whether that dynamic accelerates learning or substitutes for it is a genuinely open question. Both things might be true depending on the developer.

At the team level, the productivity pattern gets interesting in a different way. Code reviews, Kopecki argues, shift in character—away from pedantic style enforcement and toward substantive design questions. If that's accurate across organizations, it's not a small change. A significant portion of engineering energy goes into exactly those lower-order debates.

The Part That Should Make You Nervous

Here's where the optimism earns its asterisk.

Only about 30% of AI suggestions actually get accepted by developers, according to Kopecki's account. That's worth sitting with. Even in a world where 84% of developers use these tools, the humans using them are rejecting roughly seven out of every ten outputs. The tools are useful enough to keep around and untrustworthy enough to scrutinize constantly.

The failure mode Kopecki illustrates is more instructive than any percentage. You ask for a function that retrieves account info by user ID. The model produces a clean, well-commented SQL query with a string concatenation vulnerability that a junior developer in 2010 would have caught. It passes your tests. It ships. You find out what it does at 2 a.m.

Or: you ask for an authentication function. It logs users in, manages sessions, and stores passwords in plain text with a helpful comment acknowledging this isn't ideal. The model knows. It just doesn't care, because caring isn't what it does.

Kopecki's phrase for this is "the illusion of correctness"—code that looks right, reads clean, has sensible variable names, and is subtly, deeply wrong. She calls it "the technical equivalent of a really confident LinkedIn post," which is the most accurate description of a failure mode I've heard in a while.

The security concern is significant enough that it's changing how mature organizations think about which tools belong near production. Kopecki's framing on this is sharp: AI-generated code that hasn't been reviewed by a human isn't done. The translator's job ends when the human signs off, not when the model stops generating tokens.

The Actual Decision

The question that matters for most development organizations isn't whether to use AI code generators. It's which kind, for what, under what conditions.

Kopecki draws a useful line with a real-world analogy. If you're abroad and need to find a bathroom, your phone's translation app is fine—stakes are low, speed matters. If you're translating a legal contract, you hire a professional. The two are not interchangeable just because both involve language.

AI coding tools split similarly. On one side: general-purpose chat assistants, quick to sign up for, trained on whatever was available online, no visibility into where suggestions originate, your code leaving your environment to get processed. On the other: production-grade tools trained on curated, permissively licensed data, deployable on-premises or in hybrid configurations, with audit trails and governance policies.

The line between them is what Kopecki calls trust, and she operationalizes it into three questions worth keeping: Where did the training data come from? Where does my code go when you use the tool? And can you audit what happened?

For teams operating under HIPAA, SOC 2, or the EU AI Act, those aren't philosophical questions—they're compliance requirements. "We pipe PHI to a SaaS endpoint" is not a sentence you want appearing in a post-mortem.

The provenance question matters beyond compliance too. The day a junior developer ships AI-generated code into a production monorepo and the legal team starts asking whether it's GPL-tainted, you want answers. General-purpose tools usually don't have them.

None of this is an argument against using AI code generators. It's an argument for using them with your eyes open. The productivity gains are real and the risks are real, and neither cancels the other out. What changes the equation is whether the humans in the loop are actually reviewing what comes out—and whether the tools themselves are built for the context they're being deployed in.

The Grace Hopper critics were wrong about compilers. History strongly suggests they're wrong again now. But Hopper's compiler didn't hallucinate SQL injection vulnerabilities with a confident tone and well-formatted variable names.

The question isn't whether your team uses a translator. It's whether they can tell when the translation is wrong.

By Dev Kapoor, Open Source & Developer Communities Correspondent, Buzzrag