I use AI to write CODE every day. Here’s what I still have to fix every time.

Shadid — Fri, 01 May 2026 17:37:20 +0000

Everyone’s talking about how AI writes 42% of committed code in 2026. Cool stat. But nobody’s really talking about the other 58%.

I build with AI tools daily. Gemini CLI for quick iteration, Claude for heavier lifting and reasoning through architecture. And honestly? I love them. They’ve made me faster in ways I couldn’t have imagined two years ago.

But here’s the thing nobody puts in their LinkedIn/twitter post: loving a tool and being clear-eyed about its limits are not mutually exclusive. After months of shipping real features for a real product, I’ve noticed the same patterns breaking down over and over. Same categories of mistakes. Same places where I have to step in and actually think.

So this is that post. Not a doom piece. Not a “AI will take your job” or “AI is useless” take. Just an honest look at what I fix every single time AI writes code for me.

The AI writes confident code. But confident doesn’t mean correct.

This is the first thing that catches you off guard when you start using AI tools heavily.

The output looks good. Proper formatting, clean variable names, even comments that seem thoughtful. It doesn’t look like broken code. It looks like code written by a developer who knew what they were doing.

And then you run it.

The issue isn’t that AI writes bad code, it’s that it writes plausible code. Code that fits the pattern of what correct code looks like, without always understanding the actual problem you’re solving. It fills in the blanks confidently, even when the blanks needed more context that you didn’t provide.

This means you can’t just review AI code by reading it. You have to run it, and think about what happens at the edges. The review bar is higher than it looks.

It doesn’t know your codebase. You do.

AI tools work from context, whatever you paste in, whatever the file contains, whatever you describe. But your actual project has decisions baked into it that no prompt fully captures.

Why did you structure that particular folder that way? Why is that function doing two things instead of one those are intentional or just technical debt you haven’t cleaned up? Why does that API route return data in that specific shape?

AI doesn’t know. So when it writes new code, it makes assumptions. Sometimes the assumptions are fine. Sometimes they quietly break conventions you’ve been maintaining for months, and you don’t notice until something downstream breaks.

The fix isn’t to stop using AI, it’s to stay the person who knows the codebase deeply. The AI is the builder. You’re still the architect.

Type safety gets creative.

I work in TypeScript. One of the reasons I chose TypeScript is exactly because I want the compiler catching things before I do.

AI generated TypeScript code has a habit of finding creative ways around that. Not always intentionally. It’ll use any when it doesn't know the exact shape of something. It'll cast types with as when things don't quite fit. It'll write a type that looks specific but is actually loose enough to let anything through.

None of these are compiler errors. They all pass. And they all quietly chip away at the safety net you put TypeScript in place to give you.

Every time I get AI generated TypeScript, I read the types specifically. Not the logic, the types. Is this any actually necessary? What is this as hiding? Is this return type honest about what this function actually returns?
Half the time I end up rewriting the types entirely while keeping the logic. That’s fine. That’s the job.

It optimizes for making things work, not for making things maintainable.

There’s a difference between code that works and code you can come back to in three months and still understand.

AI leans hard toward the former. It’ll solve the problem. It’ll solve it in a way that, if you squint, makes sense. But it won’t always ask: is this the simplest possible way to solve it? Would another developer understand this immediately? Does this function do one thing, or secretly four things?

I’ve seen AI-generated functions that were technically correct but so tangled that even I, the person who prompted it had to read it twice to follow the logic. That’s a problem. Code you can’t easily read is code you can’t easily debug, extend, or hand off.

When I get complex logic from AI, I ask myself: can I explain what this does in one sentence? If I can’t, I refactor before moving on. Sometimes that means simplifying. Sometimes it means splitting one function into two or three. The AI did the heavy thinking, I do the cleanup.

Database and schema decisions need a human in the loop.

This one I feel strongly about.

AI will write your queries, your schema migrations, your ORM calls and it’ll make decisions while doing it. Which columns to index. How to structure a join. Whether to use a subquery or a CTE(Common Table Expression). Whether this operation should happen in the application layer or the database layer.

These decisions matter a lot. A missing index isn’t a bug you see immediately, it’s a performance cliff you fall off at scale. A poorly structured query isn’t wrong, it’s just quietly expensive. A schema decision made early in a project shapes everything that comes after.

AI doesn’t have the full picture here. It doesn’t know your data volume, your access patterns, your read/write ratio, or the specific tradeoffs that matter for your product. Currently I’m working on CrimsonWatch an AI powered IELTS mock test platform, and the data model has very specific access patterns. No generated query gets committed without me understanding exactly what it’s doing and why.

This isn’t optional. If you’re using AI to write database code, understanding your database deeply isn’t a nice-to-have. It’s the only way you can tell if what the AI gave you is actually good or not.

Error handling is usually an afterthought.

Ask AI to write a feature and it’ll write the happy path beautifully.

Ask it about the unhappy path and things get thinner. Error handling in AI generated code tends to be either missing entirely, or present but shallow. A try/catch that swallows the error and moves on, a missing null check, an assumed response shape that breaks when the API returns something unexpected.

Real production code spends a lot of its complexity on what happens when things go wrong. Network calls fail. Users do unexpected things. External APIs return unexpected data. AI doesn’t naturally weight that complexity the same way an experienced developer does, because the happy path is what makes the demo look good.

Every AI generated function that touches an external system, I go through it specifically looking for: what happens if this fails? What happens if this returns null? What does the user experience if this breaks at 2am? Usually there’s work to do.

So what’s the actual takeaway?

Here’s where I land on it.

AI tools are genuinely useful. I’m not going back to writing everything from scratch, and I don’t think you should either. The speed is real. The productivity gain is real. On the right tasks, they’re remarkable.

But the developer still matters. Maybe more than before, in a different way.

You need to understand your stack deeply enough to audit what the AI gives you. You need to know your codebase well enough to catch when generated code drifts from your conventions. You need to understand your database, your types, your error surface — because the AI will make decisions in all of those areas, and someone has to be accountable for whether those decisions were good ones.

The 42% of code that AI writes? That other 58% isn’t just the lines you type yourself. It’s the understanding, the judgment, the review, and the accountability that makes the whole thing actually work.

That part doesn’t get automated. That’s still you.

And I’m shadid. Building in public as a solo dev. If this resonated, I’d love to hear what patterns you’ve run into with AI-generated code. Drop a comment or find me on Twitter.

My first step into this community..

Shadid — Sun, 01 Mar 2026 16:25:50 +0000

Hey everyone,👋
I'm a web developer(next.js) and just joined this community(dev.to).
I've heard great things about this community, so I want to be a part of it.

And I'm here..

I have a few questions for you:

How does this community works?
Any tips for newcomers?
Did you get anything from here?

Looking forward to connecting with you all!!

Forem: Shadid