I Had 110 Broken Blog Posts. AI Couldn't Fix Them Alone.

One hundred and ten blog posts. Mixed issues — table content that was just text, broken layouts, formatting inconsistencies, CMS fields that didn't match the design. Nothing catastrophic on its own, but at scale it's the kind of job that makes you question why you became a developer in the first place.

This was at Jaryah, on the same client project where I tested Webflow MCP for CMS edits — the one where I saw roughly 70% accuracy. That number is important. I'll come back to it.

When the job landed on my desk, my first instinct was: AI can handle this. I'd already seen Claude work inside Webflow through MCP — reading collections, editing fields, applying fixes. If it could get 70% of CMS edits right, why not hand it the whole list and let it run?

So I tried.

I connected Claude to the Webflow site, gave it the audit report, and expected it to work through the posts the way I would — identify the issue, apply the fix, move on.

It worked. Sort of.

Some fixes landed perfectly. Simple formatting issues, straightforward content updates, the kind of work where the pattern is clear and the fix is obvious. Claude handled those without a problem.

Then it hit the ambiguous stuff. A post where the table content needed to become an actual table — but the structure wasn't obvious from the text alone. A layout that was technically broken but only at a specific content length. CMS fields that needed context about the client's brand voice to fill correctly.

These aren't hard problems for a human. They're hard problems for an AI because they require judgment, not execution. Claude would fix the surface issue and miss the reason it was wrong. Or it would fix one post correctly and apply the same logic to a different post where it didn't apply.

The 70% number held up. But the remaining 30% wasn't just "more of the same" — it was the part that actually needed a developer.

The 30% AI couldn't handle wasn't harder code. It was context — knowing why something was wrong, not just that it was wrong.

I stopped expecting AI to solve the problem and started using it as a tool.

The difference sounds small. It isn't.

When I expected AI to solve the problem, I gave it open-ended instructions: "Fix this blog post." "Update the CMS fields." "Make this match the design." Sometimes it worked. Sometimes it broke something else. Sometimes it did exactly what I asked and the result was wrong because I hadn't explained enough context.

When I used AI as a tool, the workflow changed completely.

Here's what it looked like in practice: a blog post had content that should have been a table — three columns, specific headers, alternating row styles. Instead of telling AI to "fix the table," I gave it the raw content and said something like:

"Take this content and convert it into a three-column table. Headers are: Service, Description, Price. Use the same table structure as the other posts in this collection — bordered cells, no background fill on the header row, left-aligned text."

AI converted it. I checked the result. Moved to the next one.

Another post had a broken layout at 768px. Instead of "fix the responsive issue," I inspected it myself, found that a flex container was wrapping incorrectly, and told AI: "Change this section's flex direction from row to column at the 768px breakpoint. Keep the gap at 24px."

AI made the change. I previewed it. It was right. Next post.

The pattern was always the same: I identified the issue, defined the fix, AI executed it, I verified. Over and over, 110 times.

The boring answer is that AI made me faster. It did. The repetitive work — the clicking, the field editing, the format conversions — went from hours to minutes. That's real and it matters.

But the interesting answer is what I realized about my own job.

When I was going through those posts, the work that AI couldn't do broke into three categories:

Understanding the problem. Not "this table is broken" — that's obvious. But "this table is broken because the content was pasted from a Google Doc and the column separators got lost, and the client's style guide says tables should have bordered cells with no fill, and this particular post is the one the client's marketing team will screenshot for their quarterly report so it has to look right." That context lives in my head, not in the CMS.

Deciding what to build. Not just fixing what's broken, but deciding what "fixed" means. Should this content be a table or a set of cards? Should this section stay as-is or get restructured? These are design decisions that depend on the brand, the audience, the purpose of the post. AI can execute either option. It can't choose between them.

Owning the result. When I ship 110 fixed blog posts, I'm the one who's responsible if something looks wrong. Not the AI. If a client opens a post on their phone and the table overflows, that's on me. So I check. Every time. Not because I don't trust AI — because I'm the developer and the result is mine.

AI handles execution. The developer handles everything before and after the execution — the understanding, the decisions, the ownership.

This is the part where most blog posts say "AI will never replace developers" and call it a day. I don't think that's honest.

AI will absolutely replace some development tasks. The repetitive execution work — the clicking, the formatting, the pattern-based fixes — that's already being handled. If your entire job is executing well-defined tasks with clear patterns, AI is coming for that work. It's already here for some of it.

The developers who are more vulnerable are the ones who only provide execution. If you can be replaced by a prompt, you will be.

But here's what I keep coming back to: the work that AI couldn't do on those 110 posts wasn't technical. It wasn't about knowing Webflow better or writing better code. It was about understanding the problem, providing context, making decisions, and taking ownership. Those are the skills that make someone a developer — not the ability to click through a CMS faster.

If your entire value is executing well-defined tasks, AI is coming for that work. If your value is understanding the problem and deciding what to build, AI is making you more productive.

This is the question that actually keeps me up at night. Not "will AI replace me?" — I'm experienced enough to adapt. But what about someone just starting?

The entry-level work that used to teach judgment — the repetitive tasks, the small fixes, the "do this 50 times and you'll start to see the patterns" work — is exactly what AI is automating. If a junior developer's first job is to fix 110 blog posts, and AI can do 70% of that, where do they learn the judgment that comes from doing the other 30%?

I don't have a clean answer for this. But I think the answer isn't to pretend AI isn't coming. It's to make sure junior developers learn the skills that AI can't teach — problem understanding, design decisions, ownership — as early as possible, not after they've spent two years doing execution work that's no longer there.

This isn't an "AI will never replace developers" post. That argument is dishonest — it pretends the threat isn't real.

This isn't an "AI is amazing" post. That argument is also dishonest — it ignores the 30% that AI couldn't handle.

This is an honest answer based on what I actually experienced: 110 blog posts, one AI tool, two different workflows, and a clear picture of what changed and what didn't.

AI didn't make me unnecessary. It changed what I spend my time on. Less clicking. More thinking. Less executing. More deciding. And I'm more productive because of it — not despite it.

The debate usually goes: "Will AI replace developers?"

I think the better question is: "What kind of developer do you want to be?"

The one who provides the context, makes the decisions, and owns the result? Or the one who only provides the execution?

AI is making that distinction matter more than it ever has. The sooner you decide which side you're on, the sooner you can build toward it.