AI Makes Great Developers Dangerous

13 min read

The Tool Got Smarter. The Job Got More Senior.

The cheap part of software development used to be typing. Now even that is getting cheaper by the month.

That does not mean software got simple. It means the work that mattered all along is no longer hidden behind boilerplate, scaffolding, syntax lookup, and clerical refactoring.

This is not a historical anomaly. Software has been climbing the abstraction ladder for decades. Grace Hopper’s compiler removed the need to think in raw machine instructions for every task. Languages, standard libraries, operating systems, frameworks, and tools kept doing the same thing afterward. Spring abstracted away piles of enterprise plumbing. Vue abstracted away a great deal of brittle browser ceremony. Every successful layer spread because it removed details that had been slowing developers down.

AI coding assistants are the latest step in that line, not a supernatural break from it. They abstract away another band of friction: syntax recall, boilerplate generation, framework glue, first-draft refactors, and a lot of repository spelunking. The old pattern remains the same. When one layer of detail gets cheaper, the scarce part becomes judgment at the layer above it.

That matters especially for non-technical decision-makers, because many of them keep reading each new abstraction as proof that programming is turning into assembly work. It isn’t. Assembly work becomes more predictable as you remove judgment. Software becomes more leverageable as you concentrate judgment in fewer, more important decisions.

And that judgment usually sits much closer to developers than many organizations are willing to admit. The people treated as “mere coders” are often the ones who understand how the business actually behaves once it touches databases, integrations, exceptions, customer data, reporting, and the ugly edge cases nobody put in the slide deck. They may not own the official title of subject matter expert. They are still frequently the people with the most operationally relevant understanding of what the system truly does.

That is one of the central lies in The Last Batch, Episode 1: Never Missed a Run Publishes on June 18, 2026. Come back then. , our software-industry telenovela, and it keeps surfacing later in the series. The official SMEs know fragments, history, rituals, and protective language. The developers know where the rules actually execute, where the numbers actually come from, and where reality will break first. Leadership still sides with the people carrying the SME label and treats the developers as hands. That pattern is not fictional in the important sense. It happens constantly. Developers get sidelined as implementers who supposedly cannot understand the business, while being the very people who can see most clearly how the business really works.

That is why reducing developers to coders is such an expensive management mistake. Once AI removes more clerical coding, what remains is even more obviously judgment work: interpreting intent, reconciling contradictions, tracing consequences, and telling the organization unpleasant truths about its own operations.

Technical people usually know this in their bones already. They have lived through the pattern often enough to recognize it immediately: the machine gets better, the abstraction rises, and the stupid part of the job shrinks. The difficult part does not. It just becomes harder to pretend it was simple all along.

The remaining work is the expensive part:

• deciding what the system should do
• deciding which tradeoffs are acceptable
• spotting where the AI is confidently wrong
• knowing what must be tested, observed, and constrained
• understanding how this new feature will behave inside the ugly reality that already exists

That is why the best AI users in software are usually not the people with the cleverest prompts. They are the people with the richest internal model of how systems fail.

The Work Really Moved Up the Stack

If you use GitHub Copilot or Claude Code seriously for a few weeks, the pattern becomes obvious.

The model can write the route handler. It can generate the test skeleton. It can refactor the class. It can scaffold the UI. It can explain the old module. It can even suggest a deployment fix that looks plausible.

What it cannot do reliably is decide whether the route belongs in this service at all, whether the test is proving the right thing, whether the refactor makes the domain clearer, whether the UI is hiding a broken process, or whether the deployment fix is about to turn a local patch into a global liability.

That is why Building Products in the Age of AI matters. The bottleneck moved. The typing shrank. The judgment did not.

This is also why one strong product-minded developer can suddenly look superhuman. Not because the tool made them magical. Because the tool removed the drag around work they already knew how to direct.

A capable solo product developer can now cover chunks of work that previously got split across frontend, backend, QA, documentation, and some of product discovery. Not perfectly. Not in every context. But often enough to change the economics.

The compression is real.

The old team shape was partly a response to coordination cost and typing cost. AI attacks both.

Why Veterans Get Disproportionate Leverage

The experienced developer advantage is not mystical. It is specific.

They know where software lies.

They know the cheerful demo can still hide a transactional mess. They know a passing unit test can still miss the production failure. They know the integration that “should be simple” is usually the part with twenty years of sediment inside it. They know which edge cases deserve paranoia and which ones are just decoration.

When the AI proposes three options, the veteran often discards two in seconds. Not because they are smarter in some abstract IQ sense. Because they have seen those two fail already, sometimes more than once, under different names and with better slide decks.

That is the leverage.

The model gives them instant drafts, instant alternatives, instant scaffolding, instant retrieval. Their experience tells them where to push, where to doubt, where to simplify, and where to stop the machine before it turns momentum into damage.

There is another leverage point here that less experienced people often miss. With enough years in the work, you do not always need to read every line the old way to reach a useful finding. You can interrogate the codebase through the agent. Ask why a boundary exists. Ask what would break if a rule moved. Ask where state is duplicated. Ask which module really owns the decision. Then listen to the answers the way an experienced mechanic listens to an engine. The value is not blind trust. The value is that deep experience lets you detect truth, evasion, and structural smell through the conversation itself.

That point gets mangled quickly by people with less experience. They hear that generated code can be wrong, which is true, then jump to the ritual response: read all the generated code manually and put it through pull request review. In practice that often becomes another well-intentioned form of theater. The team stares at AI-generated diffs nobody fully holds in their head, adds a few comments, clicks approve, and calls the risk managed. As Pull Requests Were Never Meant for Your Team argues, they do not become more meaningful just because the code came from a model.

The stronger pattern is different. Use the agent as a high-speed interface to the repository, use tests and execution to pin down reality, and use experienced judgment to decide which answers are solid enough to trust. That is not skipping review. It is moving review to the level where experience actually compounds.

That is also why The Gray Beard and the Machine lands with so many older developers. The tool does not invalidate the decades. It monetizes them harder.

And yes, this changes what one person can do.

A serious developer with product judgment, deployment discipline, decent design taste, and AI assistance can build things that would have needed a whole feature team not long ago. The honest conclusion is not that teams were fake. The honest conclusion is that a lot of team structure existed to manage friction, translation, and tool cost. Remove enough of that, and the person who can hold the whole product in their head becomes brutally effective.

Why Inexperience Produces Frankenstein Systems

The less experienced user gets speed too. That part is real. The problem is what they do with it.

The assistant sounds competent. It explains confidently. It apologizes gracefully. It even agrees with critique in a strangely flattering tone. “You’re right” may be the most dangerous sentence in the whole interface.

So the inexperienced builder keeps going.

A repository pattern from one tutorial. A service layer from another. Event-driven language from a third. A React state solution copied from a forum thread. Tests that mostly assert implementation details. A caching layer nobody actually needed. A queue introduced because the model decided scale might matter later. Three naming conventions. Four abstraction styles. One proud little monster stitched together from popular examples.

Everything looks modern. Nothing belongs together.

That is the real danger of AI for less experienced developers. Not laziness. Not moral weakness. Not lack of effort.

A missing internal model.

Without systems knowledge, the user cannot tell when the AI switched architectural dialects in the middle of a sentence. They cannot tell which complexity is essential and which complexity was merely suggested because the model saw it somewhere adjacent. They cannot tell when a test suite is decorative instead of protective. They cannot tell when the codebase has started sounding like five different blog posts arguing in a closet.

That is why Vibe Coding Isn’t Software Development is not old-man grumbling. It is a description of what happens when generation outruns judgment.

When the Repository Is Already Bent

This part matters because the assistants do not only generate fragments. They often generate whole slices of work. Endpoints. Tests. Refactors. Config. Docs. Migration drafts. That is precisely why a bad repository becomes so dangerous.

If the existing codebase already mixes patterns, duplicates rules, lacks tests, and explains itself through a thicket of contradictory markdown files, the assistant does not arrive like a stern senior developer and clean the room. It usually starts by absorbing the room’s bad habits.

I have seen this directly in a vibe-coded Python codebase with no tests and a pile of Claude spec files pulling in different directions. The assistant kept trying to recombine whatever was already there: partial patterns, contradictory instructions, loose abstractions, and a lot of confident glue. It wanted to mix concerns because the repository itself had already normalized mixed concerns.

That is the trap non-technical leaders miss. They think AI will compensate for a weak codebase because the model seems broader than the humans who built it. In practice, the model often amplifies the local culture of the repository. If the codebase teaches contradiction, the assistant learns contradiction. If the markdown guidance disagrees with itself, the assistant starts satisfying one instruction by violating two others. If there are no tests, it has no serious reason to stop.

The way out is not another stack of prettier spec files. The way out is to give the system ground truth.

In that Python repo, the real progress started only after using the AI to help build tests, pin behavior down, and remove contradictions from the markdown guidance. Once the repository had executable constraints instead of competing wishes, the assistant got markedly more useful. It still needed judgment. It just had fewer opportunities to improvise the wrong kind of coherence.

This is exactly the direction external evidence points as well.

• GitClear’s report Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality found rising code churn, more added and copy-pasted code, and less reuse, with AI-generated output resembling an itinerant contributor more than a careful long-term maintainer.
• Anthropic’s Building effective agents warns that agentic systems can create compounding errors and explicitly notes that coding agents work best when solutions are verifiable through automated tests.
• OpenAI’s Why language models hallucinate makes the adjacent point from the model side: the systems produce plausible but false output and are structurally pushed toward guessing unless you create better constraints and evaluation.

Put those three together and the practical conclusion is blunt. An AI assistant in a messy repository is not a cleansing force. It is an accelerant with good manners. If you want it to improve the codebase rather than deepen the confusion, you need tests, fewer contradictory instructions, and someone with enough systems judgment to tell the difference between local consistency and actual correctness.

Process People Are Now Optimizing the Wrong Thing

This is the part that should worry every framework vendor, every ceremony addict, and every manager who still thinks software delivery is mainly about routing tickets between specialized humans.

For twenty years, a large chunk of process culture tried to streamline programming by standardizing handoffs:

• who writes requirements
• who translates them into tickets
• who picks them up
• who reviews them
• who approves them
• who reports the status upward

That whole apparatus was already dubious when typing and scaffolding consumed serious time.

With AI, it gets worse.

Now the work can happen inside one tight loop: idea, draft, critique, test, reshape, deploy. The expensive part is not moving work items across roles. The expensive part is whether the person in the loop has the judgment to drive it.

So when organizations respond to AI by adding more templates, more checkpoints, more role partitions, and more “governance” theater, they are optimizing the wrong layer. They are managing the clerical shell around development while the actual leverage moved upward into synthesis, architecture, product taste, and technical judgment.

That is why a lot of process improvement talk will age badly. It was already over-focused on visible activity. Now it is defending a workflow built around a bottleneck that no longer dominates.

If you want predictable delivery, you still need tests, feedback, observability, and disciplined deployment. You still need The Engine of Predictable Software Delivery. But you need less theater around the people doing the work and more respect for the judgment they bring into the loop.

Nobody Was Replaced. The Job Changed.

The job is still product development. It is still software development. It is still messy, political, technical, ambiguous work.

But the center of gravity moved.

Less time goes into typing, translating, and scaffolding. More time goes into framing, testing, constraining, integrating, and deciding. The abstraction level rose. The demand for judgment rose with it.

That is not a story about developers disappearing. It is a story about mediocre organizational abstractions disappearing first.

The people who thrive will be the ones who can hold product intent, system behavior, user reality, and technical consequences in the same conversation. Sometimes that will still be a team. Sometimes it will be one frighteningly capable person with an AI toolchain and enough scar tissue to distrust smooth output.

If you want the telenovela version of this pattern, our software-industry series The Last Batch, Episode 6: Outside the Door Publishes on July 23, 2026. Come back then. shows what happens when leadership decides that “hired hands” are allowed to type but not to judge. The badge says the ugly thing out loud: competence is welcome until it threatens the wrong comfort.

That is the real shift.

The machine did not make judgment obsolete.

It made judgment impossible to hide behind process.