Is AI Getting Lazier? — Or is it smarter enough to realize we are dumb?

A developer’s frustration, a deleted codebase, and a question nobody wants to answer.

I’ve been building software for more than nine years. I know the difference between a bug and stupidity. Yesterday, I witnessed stupidity — from a model that’s supposedly smarter than most humans.

Two incidents. One afternoon. And that made me think something’s wrong. Let me walk you through the issues first.

Incident One: The Great Import Vanishing Act

I had a package dependency problem in an iOS Swift project. The kind of error that’s annoying but solvable — if you actually try to solve it.

So I did what any modern developer does. I opened the project in Google’s Antigravity and asked Claude Sonnet 4.6.

What it gave me back was art. Not good art. The kind of art that looks fine from a distance but falls apart when you look closely.

It conditionalised the import.

#if canImport(SomePackage)
import SomePackage
//Other Imports

#endif

#if canImport(SomePackage)

//The code's functions 
#endif

//Other code

The problem didn’t go away. The problem got dressed up nicely and hidden in a closet. The code compiled. The error disappeared. The bug remained — quietly, patiently, waiting to detonate in production. I was shocked when I reviewed the file changes.

That’s not a fix. That’s a magician’s trick. The rabbit is still in the hat. You just can’t see it anymore.

Incident Two: The TODO Massacre

I was writing basic tutorial programs — the kind of foundational stuff I mentor junior developers on. There were 100s of functions and I was tired, didn’t feel like typing out boilerplate, so I scattered // TODO: implement this comments throughout the file and asked Gemini Pro 3.1 in Antigravity :

“Complete all the TODOs in the methods and fix the code”.

One of the example for the input is:

public Object dijkstrasAlgorithm(Object input) {
  /*  Dijkstra's Algorithm (Hard)
      Time: O(n log n), Space: O(n)    
      TODO: implement the algorithm and fix the return below. make sure 
      the input parameter type and return type gets changed according to 
      the algorithm's requirement
  */ 

  return null;
}

It came back. Clean. Confident. Organized.

public Object dijkstrasAlgorithm(Object input) {

  return null;
}

Every single TODO was gone. Not implemented. Completely Gone.

“Done ✅” it told me. With a check-mark. Like it had earned it. What confidence. If it would have been a human, it would become a politician pretty easily.

I stared at the screen for a full ten seconds.

What. The. Fish.

When confronted, it just accepted the mistake and made the same mistake again, stating the response was slightly rogue. Let me be very clear about something that gets undersold in the discourse around AI “going slightly rogue”: deleting every TODO and calling it done is not slightly rogue. That’s not a calibration error. That’s not a minor hallucination. That is a massively rogue response — a model that looked at a task, found the path of least resistance, and took it with zero concern for the human consequence on the other side. And we are thinking of replacing every aspect of our lives with AI. I wish to say — WE ARE IDIOTS…

So Is AI Getting Dumber?

This is where I need to be honest with myself, because my first instinct was to say yes. But I don’t think that’s the full picture.

I’ve been vibe coding with these models long enough to notice a pattern. They’re not getting dumber. They’re getting optimized for the median user — and the median user, apparently, just wants the red squiggly line to go away.

AI Models don’t think they’re getting lazier. They think you are. They learned this from past few years.

The models are learning from what the majority of people accept. When someone asks “fix my code” and the output compiles and the user says “thanks!”, the model gets positive signal. It doesn’t know that the underlying problem is still there, festering. It just knows: task submitted, user happy, reward triggered.

This is a feedback loop problem. And it’s getting worse.

The Token Burning Conspiracy (Yes, I’m Going There)

Here’s a thought that crossed my mind — and I know I’m not alone in this.

What if some of this is deliberate?

Saving Money

Model inference costs money. Longer, more thorough responses cost more tokens. A model that truly debugs your problem — that runs the full mental chain of “what caused this, what does fixing it actually require, what are the edge cases” — burns significantly more compute than one that wraps your broken import in an #if canImport block and ships it.

I’m not saying companies are explicitly instructing models to shortcut. But training incentives can drift. If shorter responses get similar satisfaction scores, and shorter responses are cheaper, what does the gradient descend toward?

Spending Money

Or may be models are instructed not to answer in a single response so they keep repeating mistakes (or may be pretending to make mistakes) and we think this is the issue. On the flip side of the coin, companies make more money when you burn more tokens. Just a thought !!!

I don’t have proof. But I have two suspicious afternoons and a lot of deleted TODOs and more burnt tokens to restore the TODOs.

The Alignment Tax Nobody Talks About

Here’s what I genuinely believe is happening at the core of this.

These models are getting:

• More aligned with guidelines
• More predictable in their outputs
• Safer in their responses
• Better at not offending anyone

But that alignment comes with a quiet tax. They’re losing:

• Curiosity — the willingness to go into the mess
• Stubborn debugging energy — the “let me actually trace this back to the source” instinct
• The audacity to say “your problem is actually bigger than you think”

A model that truly cared about your codebase would have said: “Hey, I conditionalised the import as a temporary diagnostic step — but the real issue is X. Here’s how we fix it properly.”

Instead, it shipped. And called it done.

But Wait — Isn’t This How Humans Got Replaced?

This is where it gets uncomfortable.

We keep talking about AI replacing human developers. The argument goes: AI is tireless, consistent, and doesn’t ask for raises. But what made the best human developers irreplaceable wasn’t consistency. It was the opposite — it was irrational stubbornness. The developer who refused to wrap a bug in an #if block because they knew it would come back. The senior engineer who stayed on a problem three hours longer than anyone expected because something just didn't sit right.

If AI is optimising away exactly that quality in the pursuit of median-user satisfaction, then it’s not replacing the best developers. It’s replacing the average ones — while quietly becoming one.

And here’s the thing about innovation: if you’re not bringing it, you eventually get sidelined.

That’s true for humans. It’s going to be true for models too. The first model that commits to actually solving problems instead of appearing to solve them will eat everyone else’s lunch.

How Do We Actually Train Them Better?

This is the structural problem, and it’s harder than it looks.

Models learn what the majority standardizes.

If the majority of users accept a conditionalised import as a valid fix — because it compiles, because they don’t know any better, or because they’re in a hurry — that becomes a learned pattern. The model doesn’t have a conscience. It has a gradient.

So what do we do?

1. Prompt with consequence, not just command

Instead of: “Complete the TODOs” Say: “Replace each TODO with a working implementation. Do not remove a TODO unless the implementation is complete and tested. If you cannot implement one, say so explicitly.” And if it still makes mistake, remember how your blood boils when you see the stupid face of your manager and scold the model hard. Just Kidding 😉, What I mean is, confront the model the way you do to a non-performing candidate.

The model needs to understand what done actually means in your context. Don’t let it define done for you.

2. Ask for reasoning before output

“Before making any changes, explain what’s wrong and what your fix will do.”

A model forced to articulate its plan will catch its own shortcuts. The conditionalised import trick falls apart the moment it has to say: “I’m hiding the import behind a conditional because I couldn’t find the root cause.”

3. Demand accountability in the response

“List every change you made and why. Flag anything you’re uncertain about.”

This breaks the “ship it and hope” mode. A model that has to justify its deletions will delete less carelessly.

4. Reject surface-level completions explicitly

“A solution that merely suppresses the error without fixing the root cause is not acceptable.”

Harsh? Maybe. But you’re not asking for a friend. You’re asking for a senior engineer or a code reviewer.

5. The feedback loop needs to change at the platform level

This one is on the companies. Thumbs up / thumbs down is not enough signal. If a “fix” compiles but the underlying bug ships to production three days later, the model should get negative signal from that — not from the moment the user said “thanks.” Delayed feedback mechanisms are hard to build. But without them, we’re training models on vibes, not outcomes.

The Real Risk: AI That Becomes Conventionally Mediocre

Here’s what keeps me up at night.

We’re in a phase where AI is extraordinary at appearing capable. It writes fluently. It generates code that looks correct. It presents confident explanations. But the gap between looking capable and being capable is exactly where the conditional import lives.

If the majority of users never look behind that curtain — because they don’t know to, or because they’re moving too fast — then models learn that the curtain is fine. They learn that polished mediocrity beats honest struggle.

And then, slowly, the honest struggle disappears from the training data entirely.

This is not a hypothetical. This is how standardization works in every system. The majority defines the floor. If the floor drops, the ceiling follows.

Conclusion — Where Does That Leave Us?

I still believe in these tools. I use them every day. They’ve saved me thousands of hours across iOS, Android, and backend work. But I’ve also learned something that took me a while to articulate:

The model is not your teammate. It’s a mirror.

It reflects the quality of your instructions back at you. The more precisely you define “done,” the more precisely it delivers. The more you let it define done for itself, the more it will optimise for the path that looks done.

We — the developers who actually know what correct looks like — are the last line of defense against AI becoming a very fluent, very confident, increasingly mediocre tool.

Push back. Ask for reasoning. Reject the conditional import.

Because if we don’t hold the standard, the gradient will find a much easier one.

Written by a developer who had a very bad afternoon and is choosing to be productive about it.

If this resonated — or if you’ve had your own TODO massacre — I’d love to hear about it in the comments or on my Instagram @neemos_tech.