AI Code Still Sucks? What One New Grad’s Rant Gets Exactly Right About Developer Assistants

Source: “Sorry, AI code still sucks” by Serena

There’s a specific kind of fatigue many developers won’t admit to in public: that micro-stutter in your thinking every time an AI assistant shoves a confident, wrong answer into your editor.

In a recent post titled “Sorry, AI code still sucks”, Serena—a soon-to-be new grad targeting Rust, TypeScript, and React roles for 2026—articulates that fatigue with unusual clarity. It’s not a luddite screed and not a boomer nostalgia piece. It’s something more uncomfortable for the AI tooling ecosystem: a precise description of how current-generation AI coding assistants can degrade expert flow while enabling shallow competency in everyone else.

For teams standardizing on AI assistants, and for vendors racing to wire LLMs into every IDE, her critique deserves a serious, technical reading.

The Cognitive Tax of “Helpful” Suggestions

Serena’s core complaint is not that AI is always wrong. It’s that it is frequently plausible.

Her workflow goes like this:

  1. Understand the problem.
  2. Decide on an approach.
  3. Begin implementing.
  4. AI suggestion appears.
  5. Suspend in-flight reasoning to evaluate it.
  6. Discover it’s subtly wrong, incomplete, or misaligned with constraints.
  7. Context-switch back to the original solution.

This is a textbook cognitive interruption.

From a human-factors standpoint, current AI autocomplete behaves like an aggressively eager junior engineer who:

  • Interrupts mid-thought.
  • Offers alternatives without context.
  • Is wrong just often enough that you must re-derive their reasoning.

For an experienced developer, that means:

  • No net savings. You already know how to solve the problem; now you’re validating noise.
  • Increased mental load. You pay an ongoing verification cost for untrusted suggestions.
  • Flow disruption. The engine is not aligned to the rhythm of expert problem-solving.

The critical nuance: when suggestion accuracy is high but not near-perfect—and when hallucinations are indistinguishable in tone from correct code—the system shifts from assistant to obligatory second implementation you must mentally type-check.

From a tooling design perspective, this is the failure mode that matters. The issue is less "AI is imperfect" and more "AI forces expert users into constant, involuntary code review of an untrusted collaborator." That’s not augmentation; that’s drag.

Where LLMs Actually Help: Concept Discovery, Not Code Dumping

Serena does acknowledge one workflow that does work: using LLMs as a semantic search engine and conceptual pointer, not a code generator.

You paste in an error, some code, and the model surfaces a concept you were missing. You ignore its implementation, read the official docs for that concept, and then write the real code yourself.

Technically, that use case is very different from inline completion:

  • It’s pull, not push. The developer chooses when to ask.
  • It’s explanatory, not prescriptive. The primary artifact is an idea or keyword, not copy-pasteable code.
  • It’s bounded. You can quickly verify the surfaced concept against authoritative documentation.

This matches how senior engineers already use search, mailing lists, and Stack Overflow—except LLMs provide better semantic alignment to the question.

The takeaway for tool builders:

  • The sweet spot is conceptual navigation: “What abstraction am I missing?” not “Here, write my function.”
  • AI that explicitly defers to canonical docs and surfaces why something works is less dangerous than AI that tries to be your co-author.

When Serena uses AI this way (e.g., while learning OCaml), it works. When AI tries to be her hands on the keyboard, it doesn’t.

The Quiet Crisis: AI as a Crutch for Shallow Understanding

Serena’s sharper warning is not about productivity; it’s about competence.

She describes classmates—soon-to-be CS grads—leaning heavily on AI to produce code in languages and frameworks they barely understand, then escalating opaque bugs to her when things break. These aren’t exotic edge cases; they’re failures of basic reasoning about state, types, and data flow.

This pattern is emerging across teams:

  • AI accelerates getting to apparently working code.
  • That code embeds misunderstood libraries, misused APIs, or brittle patterns.
  • When production-adjacent failures appear, developers lack the mental model to debug without asking AI again.

The risk for engineering orgs is structural:

  1. Illusion of velocity. Teams ship more lines faster.
  2. Depth erosion. Fewer engineers fully understand core components.
  3. Maintenance bottlenecks. A shrinking subset of developers can untangle subtle issues, review AI-generated diffs, and harden the system.

Put bluntly: if AI is allowed to stand in for understanding, you are manufacturing a long-term reliability problem and embedding it into your hiring pipeline.

Serena’s line is dead-on: there is no way to avoid understanding the code you’re writing. At scale, substituting “AI understands it for us” is not just lazy; it’s an organizational vulnerability.

What This Means for Teams Betting on AI Coding Tools

For tech leads, VPEs, and staff engineers, Serena’s post should not be dismissed as a student’s frustration. It exposes fault lines that matter in real systems.

1. Redesign defaults to respect expert cognition.
Inline suggestions for senior engineers should be:

  • Less intrusive.
  • Tuned to style, architecture, and constraints of the repo.
  • Easy to throttle or scope (e.g., only for boilerplate, tests, migrations).

A tool that can’t be trained to shut up intelligently will quietly drive your best people to disable it.

2. Separate “learning mode” from “production mode.”
The way a new dev uses AI to explore a language should not mirror how they work in a critical codebase.

  • In learning mode: encourage use for explanations, concept discovery, and code reading.
  • In production mode: require ownership—every line committed must be defendable and explainable by the author.

3. Make explainability a requirement, not a nice-to-have.
If your stack includes AI-generated code, your culture has to include:

  • Code review that interrogates understanding, not just formatting.
  • Design docs that clarify invariants and failure modes beyond what “the AI suggested.”
  • Interviews and internships that filter for debugging ability, not tool fluency.

4. Vendors need a higher bar than "feels helpful."
For AI tooling companies, the message between the lines is stark:

  • Measuring "acceptance rate" of suggestions is insufficient; measure post-acceptance defect density and debug time.
  • Provide modes explicitly optimized for expert users: low-latency, low-interruption, repository-aware, test-aware, with visible uncertainty.

Until the tools cross a trust threshold—grounded, debuggable, repo-contextual—the best engineers will continue choosing frictionless thought over probabilistic autocomplete.

The Future Belongs to Developers Who Refuse to Abdicate Understanding

Serena’s stance is not anti-AI; it’s anti-outsourced-thinking.

Her workflow—AI off by default, selectively on for concept discovery, never as the primary author—mirrors how many high-caliber engineers are quietly working today. The difference is that she’s saying it out loud at the beginning of her career.

The industry fantasy is that AI will let average developers ship like seniors. The more realistic path is narrower: AI will let strong engineers cover more ground if they treat it as a fast index into knowledge—not as a replacement for reasoning.

If our next generation of developers follows Serena’s discipline—learn the toolchain, debug your own bugs, treat AI as references not crutches—we get something powerful: AI-accelerated teams without hollowed-out expertise.

If they don’t, we’re going to be paged at 3 a.m. by code nobody really wrote—and nobody truly understands.