Why AI Can't Replace Developers (But It Will Expose the Bad Ones)

AI can speed up development massively — but only if you know which decisions to make yourself, and which bugs to catch before they ship.

Everyone's saying AI killed the developer. I spent the last few days building my portfolio site end-to-end, and I'm here to tell you — it didn't. But it changed the job completely.

Here's exactly how I built it, what went wrong, what I had to fix manually, and why experienced developers still matter more than ever.

Starting with Lovable — React + Supabase

I kicked things off using Lovable, with React, Tailwind CSS on the frontend and Supabase + PostgreSQL on the backend. The goal was a fully dynamic portfolio — every section (about, services, projects, blog, reviews, experience) editable from an admin panel without touching code.

For the most part, AI got me there fast. But I learned early to never just accept what it generates. Every feature I added, I'd review the code myself. And I'm glad I did.

AI bug caught in the wild: The AI was making an API call to save data on every single keystroke while editing blog posts and projects. No debounce. No delay. Just hammering the database with every character typed. I caught it, called it out, and had the AI fix it — but the lesson stuck: always read the code.

Adding the integrations myself

Some things I chose to wire up manually rather than leaving to AI. for example Email integration, and Automation. And I built a custom SDK from my own CRM to handle lead tracking directly inside the portfolio — capturing visitors, automating emails when I publish new posts or projects, and managing offer campaigns.

This kind of integration isn't something you just prompt your way through. You need to understand the system you're plugging into.

Converting to Next.js — and another AI regression

After everything was working in React, I realized the site wasn't SEO-optimized. So I started converting to Next.js. I used Claude to speed up the migration, but ran into a frustrating pattern:

The AI kept using an old, unstable cache method even after I explicitly pointed it to newer Next.js docs. It would correct itself for one or two responses — then silently drift back to the deprecated approach. I had to fix that part manually.

This is something AI genuinely struggles with: following a new convention consistently when it has a stronger prior from training data. Point noted.

The real work: caching decisions

This is where things got interesting — and where I think the developer's role becomes impossible to replace.

Caching in Next.js isn't just a switch you flip. You have to actually think: which pages should be cached? For how long? When do they need to revalidate? These are architectural decisions with real performance, cost, and freshness tradeoffs.

Cached (public pages): Portfolio pages are served from cache indefinitely. Zero database calls on each visit. Fast load, SEO-friendly, low server cost.

No cache (admin panel): Admin panel needs real-time data. Caching here would show stale content — defeats the purpose entirely.

When I publish a new blog post or project, I trigger revalidateTag and revalidatePath from the admin panel. The public site updates — no rebuild, no manual redeploy, no stale content.

Can an AI make this call? It can suggest options. But deciding what your site actually needs, given your update frequency, your audience, your infra costs — that's a judgment call. Not a prompt.

Why "AI-first" startups will eventually call a developer

There's a wave of non-technical founders building products entirely with AI tools. No developers involved. Ship fast, iterate, go live. And look — for a lot of early-stage stuff, that actually works.

But here's what happens at scale:

When the site can't handle traffic, when server bills double overnight, when caching is misconfigured and the database gets hammered — they'll need a developer. Not an AI tool. A person who understands the system deeply enough to diagnose what went wrong and fix it.

The bugs that matter most in production are the ones that only appear under load, over time, in edge cases. Those aren't fixed by regenerating a component.

What I actually learned

• AI is a force multiplier — but only for developers who know what to check

• Always read generated code. AI will ship bugs with confidence

• AI drifts back to old habits — especially with evolving frameworks

• Architectural decisions (caching, revalidation, data flow) still need a human

• The demand for developers isn't going away — it's shifting upward

The developers who'll struggle are the ones who stop learning. The ones who stay curious, build real systems, and understand what's happening under the hood — they're not being replaced by AI. They're being upgraded by it.