AI Has No Wisdom. So What About Me?

I read a blog post recently, and it stung a little.

It's called "AI Has No Wisdom and Neither Will You," by a developer named Alexandru Nedelcu. Pretty rude title. The annoying part is that after reading it, I had a hard time arguing back.

Why did it sting? Because I built this very blog in three days with AI tools, knowing almost nothing about code. If you asked me who the post is warning about, I'd have to admit I'm standing uncomfortably close to the target.

The argument: bad code shows up late

The author opens with things he'd heard in just one month. People saying they haven't written code since 2025. That code reviews are dead. That nobody reads code anymore. He thinks that trend is dangerous, and his reasoning goes roughly like this.

First, you can't measure maintainability on the spot. The cost of bad architecture shows up months, sometimes years, later. You fix one thing and something completely unrelated breaks somewhere else. Adding a feature means touching five places, and you forget the sixth.

Second, that's exactly why AI struggles to learn what good code looks like. Reinforcement learning needs a reward signal you can measure right away. Maintainability doesn't work that way. So models end up learning from beginner rulebooks and from code in the wild, which (let's be honest) is mostly not great.

Third, and this is the part that hurt: when people stop reading and writing code, people stop learning too. No choices, no responsibility for mistakes, no lessons from mistakes. The AI makes the mistakes, the AI doesn't learn from them, and neither does the person leaning on it. Everyone stays exactly where they are.

He brings in the Dreyfus model, which breaks skill acquisition into stages from novice to expert. Beginners follow rules. Experts read the context and make judgment calls. In his words, "Experts don't follow the rules, they make the rules." And that judgment comes from late nights chasing production bugs and swearing you'll never make the same mistake again.

Where I nodded along: slow feedback

The idea that stuck with me most was the chain "can't measure it, so can't learn it." Because it's not just about code.

I'm not a developer. I plan products. And planning works the same way. A bad requirement or a misaligned direction doesn't look bad on day one. The screens look nice. The deadlines get met. Then, months later, it blows up. I've watched a product that was technically solid get cancelled before launch because it didn't line up with the strategy. What I learned from that wasn't in any textbook. It just hurt, and that's why I remember it.

AI-written planning docs have the same vibe. They look convincing. Clean table of contents, nothing obviously missing. But the moment someone asks "why are we doing it in this order?", I'm the one who has to answer. Sure, the AI can give an answer too. It just won't be the one taking responsibility three months later when that answer turns out to be wrong.

His example about splitting functions landed as well. Ask an AI to "simplify" some code and it'll chop a big function into several small ones that nobody ever reuses, so now you have to open every one of them just to understand the original. Split up, yet harder to follow. It's like taking a one-page spec and breaking it into five appendices. Tidier on the surface. Worse for whoever has to read it.

Where I see it a bit differently

I don't buy the whole conclusion, though.

He predicts more companies will proudly advertise a "NO-AI" policy, and that it'll become a competitive advantage. That feels like a stretch. He says himself that he uses AI every day and even teaches his colleagues how to use it. So the way I read it, his real target isn't AI. It's handing over the judgment along with the typing.

For me the line isn't "use AI or don't." It's "who makes the call, and who learns from it?" AI writing the first draft is fine. Calculators didn't kill mathematical thinking. But you still need the instinct to notice when the calculator spits out something weird. Without that, you end up carrying the wrong answer around with total confidence.

So what am I going to do?

Nothing grand. Just a few rules I've set for myself after reading it.

If I can't explain it, it's not my code. Even when AI writes it, I want to stay with the core logic until I can explain it in my own words. Maybe not every line. But at least where the data comes from and where it goes.

Ask "why did you do it this way?" more than "just do it." Asking for options and trade-offs builds judgment far better than collecting answers. And I make the final call.

Write it down when I'm wrong. Whether it's a bug or a plan that went sideways, I'll write the cause in my own sentences, not an AI summary. Experience only turns into judgment if it passes through my own head at least once.

Will I actually stick to this? No idea. When I just want to be done for the day, "let the AI handle it" is a very tempting sentence.

Wrapping up

AI not having wisdom is fine. It's a tool. Nobody expects a hammer to have an architectural philosophy.

The problem is what happens if I keep outsourcing the judgment. A few years from now, I could be the one holding the hammer with no idea what to build.

When was the last time you asked your AI "why?"

Source: AI Has No Wisdom and Neither Will You by Alexandru Nedelcu