The Hidden Cost: AI's Time Complexity Trap

These days, the moment a problem gets stuck in our heads, we turn to AI for help. We explain our problem, it gives us some answers. How accurate or high-quality those answers are is always up for debate. If we know the subject well or have some background, it's easy to interpret AI's responses but what do we do when we don't?

As developers, AI is now a tool for us. I think there's no one left among us who doesn't use it. From writing code from scratch to updating existing code, AI is now our teammate in many tasks. But how consciously does this new teammate suggest code? How much of the code it suggests actually works properly? Can we be sure that code won't cause us problems down the road?

I wanted to start this post with some questions to stir things up a bit. The answers are all hidden within us. Today I want to talk a little about my own experiences, about the consequences of accepting AI-written code without thinking, and about how we can catch those problems early if we just stop and think.

The Silent Trap

You ask AI: "How can I find duplicates in this array of 100,000 user records?" It gives you 20 lines of clean, working code. You copy it. It works. You deploy it. Three months later, your data import job takes 45 minutes instead of 5. That's the hidden cost of not reading the code AI wrote for you.

Here's the thing about AI-generated code: it works, but it usually doesn't work efficiently. AI models are trained on a massive corpus of code collected from the internet. That code reflects the average, not best practices. When you ask an AI to solve a problem, it statistically generates the most common solution, not the most optimal one.

And here's the key point:

If you don't understand what the code does, you can't see the inefficiency

This isn't about AI being "bad" or developers being "lazy." It's about a fundamental shift in how we consume code. Back in 2015 when you copy-pasted from Stack Overflow, you'd usually skim through the answers and pick the one that made sense. You understood what you were copying. I talked about this in my LinkedIn post. With AI, code looks so fluent, so professional, that understanding it feels optional. But it's not.

Example 1

Let me give a concrete example from my data migration work.

Problem: Let's say I have a CSV file with 50,000 user records. Each record needs to be deduplicated by email address before importing.

A typical AI solution:

class UserImporter
  def deduplicate_users(records)
    deduplicated = []
    
    records.each do |record|
      if deduplicated.any? { |r| r[:email] == record[:email] }
        next
      end
      deduplicated << record
    end
    
    deduplicated
  end
end

Looks reasonable, right? It works. With 100 records you won't notice anything. But what about 50,000 records?

Time complexity: O(N²)

Why? For each record (N iterations), you're checking whether it exists in the deduplicated array using .any? (which is another N iterations in the worst case). That's nested loops. That's exponential pain. To visualize it quickly:

• 1st record: 1 check
• 2nd record: 2 checks
• ...
• 50,000th record: 50,000 checks

Total: ~1.25 billion comparisons.

On a modest server that handles ~1 million comparisons per second, you're spending more than 20 minutes just to remove duplicate records.

A Better Solution (something AI could suggest, but doesn't by default):

class UserImporter
  def deduplicate_users(records)
    seen_emails = Set.new
    
    records.select do |record|
      if seen_emails.include?(record[:email])
        false
      else
        seen_emails.add(record[:email])
        true
      end
    end
    
  end
end

Time complexity: O(N)

Same 50,000 records. Same logic. The difference? Instead of taking more than 20 minutes, it finishes in seconds.

What's the difference between these two approaches?

Understanding the tradeoff between array lookup (O(N)) and hash/set lookup (O(1))

AI could have written the second example too. But it defaults to the first because that's what most people write when they're not thinking about performance.

Example 2

The first example was about processing large files, and maybe not everyone deals with that day-to-day. But the example I'm about to give is something we all run into very often — and many of us (at least more in the past, thankfully less now) don't even notice. N+1.

# What AI suggests

users.each do |user|
  puts user.posts.count  # A SQL query runs for each user
end

# The code after paying attention and fixing it

User.includes(:posts).each do |user|
  puts user.posts.count  # All data loaded, single query runs
end

Example 3

I want to give one more example. Maybe AI has gotten smarter by now — and after scanning this post it'll probably get even smarter. When you want to work across multiple arrays, the first solution that comes to mind or that AI will suggest tends to look like this:

# O(N²) nested loop:

results = []

array1.each do |a|
  array2.each do |b|
    results << a + b if a == b
  end
end

You might accept this code as is. But it doesn't look very efficient. You paste it, it probably gets the job done, you move on. But then what? You could ask AI to make it more optimized. And that's exactly where the difference shows up.

common = array1 & array2
results = common.map { |a| a * 2 }

Of course, AI can do even better than that. The thing is, if you point out that the first code example isn't efficient, AI will probably suggest more optimized code in the follow-up questions. And that way it won't waste your time either 😀

Why Does This Matter?

Bu neden bu kadar önemli. Çalışması yeterli değil mi? Evet zaten ilk önce çalışması lazım kodun, zaten konu aslında sonrası için önemli. Ama şöyle üç maddede özetlemek istersek;

1. Veri, Donanımdan Daha Hızlı Büyüyor

Why is this so important? Isn't it enough that it works? Well yes, code needs to work first but the real conversation starts after that. Let me summarize it in three points:

1. Data Grows Faster Than Hardware

Your test data has 100 records. Production has 100,000. An O(N²) algorithm that's invisible in tests becomes a bottleneck in production. Your monitoring system starts screaming. Your team panics. The post-mortem reveals: "We didn't read the code we shipped."

2. AI Doesn't Know Your Context

AI generally answers your question. It can't know why you're asking or what you're going to do with the answer. Since it doesn't know the full picture of your project, that decision has to come from you. The code it suggests might not fit your project at all.

3. Performance Debt Accumulates

Bad algorithm + bad algorithm + bad algorithm = system failure. You won't notice individual O(N²) operations. But when you have 10 of them on your critical path, a feature that "should take 2 seconds" takes 20.

What Should We Do?

Rejecting AI-generated code doesn't make sense. It's incredibly useful. The important thing is to be deliberate during code review.

Checklist:

1. Read the code. Don't skim it. Read it. Ask yourself: "What loops are here? Which ones are nested? Are we iterating over the same data more than once?"
2. Ask about scale. "This works for 100 records. What about 100,000? 1 million?"
3. Check for common traps:
   • Unjustified nested loops
   • Array operations inside loops (.include?, .any?, .select in an O(N) context)
   • N+1 queries in databases
   • Unnecessary sorting
   • String concatenation in loops (Ruby-specific)
4. Understand the why. If you can't explain why an algorithm is O(N²) instead of O(N), you don't understand it well enough yet.
5. Benchmark early. Don't wait until you deploy. Run load tests with realistic data volumes in your development or staging environment.

Conclusion

The thing about AI that generally makes me uncomfortable:

We're getting used to not understanding the code we write

AI promised to make us more productive. And it does. But productivity without understanding is technical debt with a smile. The best developers I know — the ones who build scalable systems read code. They understand algorithms. They think about complexity. They don't make assumptions. AI is a powerful tool. But tools don't eliminate the need for craftsmanship. They amplify it. So next time AI gives you 20 lines of working code:

Don't just run it. Read it. Understand it. Question it.

Because in the age of AI, code literacy is not optional — it's part of surviving in our industry.

So, do you read your code? With the help of AI, can you explain a piece of code to your teammates?