Did AI Write This Code? Or Is It Just Developer Stupidity?
Did AI Write This Code? Or Is It Just Developer Stupidity?
I’ve been using AI for coding for a while now.
Actually, AI came into my learning journey from the beginning.
I was learning programming, building projects, debugging problems, and at the same time AI became part of my workflow.
So I have seen both sides:
Using AI as a learning tool.
And using AI as a code generator.
Before starting, let me make something clear:
This is my POV.
It comes from my own experience using AI, learning programming, and building things.
Maybe you disagree with me. That’s fine.
I’m not trying to convince everyone that my opinion is the only correct one.
I’m just sharing what I have seen.
Did AI really write this code?
Recently, I started noticing something interesting.
Sometimes you look at a piece of code and think:
“There is no way a human wrote this.”
Too many classes.
Too many abstractions.
Too many layers.
A simple 20-line problem somehow became 200 lines of code.
And the first reaction is always:
“AI wrote this.”
But then I started asking myself:
Is this really AI stupidity?
Or is it just:
Developer stupidity?
And honestly…
Sometimes it is hard to tell.
Human Stupidity
Developers have always written stupid code.
AI didn’t create bad code.
Humans were already doing it.
Especially junior developers (and sometimes experienced developers too) have one common problem:
They want the code to look impressive.
They want it to look professional, scalable, enterprise-ready, and “senior level”.
And this is where things start going wrong.
A developer has a simple problem.
Instead of asking:
“What’s the simplest solution?”
They ask:
“How can I make this more advanced?”
Then they go to AI:
“Make this code better.” “Make it faster.” “Make it more professional.” “Make it production-ready.”
And this is where AI starts burning tokens.
A Simple Example
You have a simple requirement:
“I need to create an appointment for a user.”
The actual code could be:
1
2
3
4
5
def create_appointment(user, time):
return Appointment.objects.create(
user=user,
time=time
)
Simple.
Easy to understand.
Easy to maintain.
But then someone asks AI:
“Make this scalable and production-ready.”
Suddenly it becomes:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
AppointmentViewSet
|
AppointmentService
|
AppointmentManager
|
AppointmentRepository
|
AppointmentFactory
|
AppointmentStrategy
|
AppointmentValidator
|
AppointmentEventHandler
|
AppointmentNotificationService
Congratulations.
You now have an enterprise appointment architecture.
For creating a simple appointment.
AI Stupidity
AI has a different type of stupidity.
The interesting thing is:
AI doesn’t always write bad code.
Sometimes it creates code that looks like a senior developer designed a huge system.
But the problem is:
The system is solving a much bigger problem than the one you actually have.
Imagine you are building a simple gym management system.
You only need to get active members:
1
members = Member.objects.filter(is_active=True)
Simple.
Easy to understand.
Easy to maintain.
But then you ask AI:
“Make this scalable and production-ready.”
And suddenly you get:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
MemberViewSet
|
MemberService
|
MemberRepository
|
MemberQueryBuilder
|
MemberSpecification
|
MemberFactory
|
MemberManager
|
MemberDomainEntity
For a simple database filter.
Not Every Abstraction Is Overengineering
Not every abstraction means overengineering.
Sometimes creating an abstraction early is a reasonable engineering decision.
For example:
1
SMSService
Even if today you only support one SMS provider.
Because maybe tomorrow you need to add another provider.
The problem starts when we create structures without a clear purpose.
I have seen projects where from day one they had:
1
2
3
4
5
SMSService
EmailService
NotificationManager
MessageFactory
ProviderInterface
But most of them were just empty shells.
No real use case.
No actual requirement.
Just there because:
“Maybe someday we need it.”
The difference is simple:
Good engineering asks:
“What problem are we preparing for?”
Bad overengineering asks:
“What if one day we need everything?”
How Can We Tell?
You cannot identify AI code just by looking at it.
Overengineering is not proof.
Bad naming is not proof.
Too many comments are not proof.
Humans can write all of these.
AI can write them too.
The better question is:
Can the developer explain the decisions behind the code?
Ask:
Why do we need this class?
Why do we need this abstraction?
Why is this condition here?
What happens if we remove this part?
If they understand the decisions, maybe the complexity has a reason.
But if the answer is:
“I don’t know. AI suggested it.”
Then we have a different problem.
The Real Problem
The problem is not AI.
AI is just a tool.
The real problem is:
A developer who doesn’t understand something now has a tool that can generate hundreds of lines of code in seconds.
Before AI, bad developers could write bad code slowly.
Now they can write bad code faster.
Much faster.
Final Thoughts
Maybe the question shouldn’t be:
“Was this code written by AI?”
Maybe the better question is:
“Does the person who shipped this code understand why it exists?”
Because at the end:
AI can write stupid code.
Humans can write stupid code.
But the worst combination is:
Human stupidity + AI speed.