我们并非都是糟糕的开发者：AI 无法取代真正理解代码的人

I have always hated this idea that we are all terrible developers who don’t really know what we’re doing. Or that tired old joke that programming is just copying things from Stack Overflow until the errors go away, and anyone who takes pride in their work is kidding themselves. I know it’s usually supposed to be a joke. I just never found it particularly funny.

Of course I’ve written bad code. I’ve also spent years learning how to write better code, how to read it, how to debug it and how to recognise when something that looks perfectly reasonable is going to cause a problem. So have plenty of other developers. Why do we talk about that effort as if none of it counts?

Now I keep seeing the same reasoning used to argue that AI will replace us. You were only copying code anyway. You use libraries you didn’t write. You don’t understand every part of your stack. So what exactly is there to replace?

Well, quite a lot actually. Being able to read the code and really understand what it does would be a good place to start.

I don’t believe AI will ever fully replace developers, because somebody still needs that understanding. And I mean really understand it, not skim through a diff and decide it looks fine. Someone needs to know why it works, where it can fail and what happens to the rest of the application when you change it.

Otherwise it’s all a black box. You ask for something, code comes out, and you hope it does what you meant. Ask the tool to explain it too, sure, but somebody still has to understand enough to tell whether that explanation makes sense. That is a skill, and I’m tired of seeing it dismissed by people arguing that we never had any skill to begin with.

Somebody Wrote the Library

The library argument is especially strange to me. You use PostgreSQL without having written a database yourself, so you never really understood SQL in the first place, and now you don’t get to question SQL generated by an LLM?

Understanding SQL and implementing a database engine are different skills. You can understand joins, transactions, isolation levels, indexes and query plans without having written PostgreSQL. You can explain why a query duplicates rows, why an index isn’t helping, or why two transactions that work perfectly on their own can produce the wrong result when they run together. That is real understanding, and it takes work to develop.

Someone with that knowledge can read generated SQL and catch a query that returns plausible but incorrect results. They can recognise that a join changes what you’re counting, that NULL behaves differently from what the author assumed, or that a query which looks fine on a hundred rows will struggle on ten million. They can explain the problem, demonstrate it and fix it. What more would you want as evidence that they understand what they’re doing?

If your definition of understanding SQL requires having built the database engine yourself, you’ve stopped measuring SQL knowledge. You’re demanding expertise in a different job so you can dismiss the expertise someone actually has.

Somebody wrote PostgreSQL. People designed it, implemented it, investigated bugs, argued about tradeoffs and improved it. The same goes for the compiler, the framework and the operating system underneath whatever you’re building. Depending on their work is an acknowledgement that other people have expertise worth using.

How did that become evidence that nobody has any expertise?

I use Qt in zenkai because I want a good interface without building an entire GUI toolkit first. I still have to understand how my application interacts with it. When startup is slow, knowing which work happens during layout, which work happens during painting and where I’m asking for icons actually matters. Qt doing a lot of the work doesn’t make those questions disappear.

Nobody understands every layer of a modern computer. That has never been the requirement. You need enough understanding to make decisions about the part you’re responsible for, recognise when your assumptions stop holding, and know where to investigate next. Sometimes that means reading documentation. Sometimes it means reading the dependency’s source. Sometimes it means asking somebody who knows more than you.

I don’t need to know every detail of Qt to use it. But if a problem leads into Qt, I need to be willing to read that code too, or find someone who can help me understand it. Installing a dependency doesn’t make that somebody else’s problem forever.

Looking Something Up Was Never the Embarrassing Part

The Stack Overflow joke bothers me for the same reason. There is a difference between finding an explanation that helps you solve a problem and pasting something you don’t understand until the application happens to run.

I’ve learned things from other people’s code. Of course I have. So has practically everyone I’ve worked with. The useful question is what happens after you find the answer. Can you explain why it works here? Can you spot the assumption that doesn’t fit your application? Can you change it when the requirements change?

That takes skill, and it’s a skill you can improve. Reducing the whole process to copying and pasting throws away the part where somebody actually learned something.

It also makes for a miserable introduction to programming. Imagine being excited about finally understanding a difficult problem and being told that nobody really understands anything, everyone is faking it, and caring about doing it well is embarrassing. Why would we want that to be the culture people join?

I’d much rather tell someone that yes, this is difficult, and yes, people get better at it. You don’t need to be a genius to become competent. You need time, practice, curiosity and people willing to explain things without making you feel stupid for asking.

Somebody Has to Be Able to Read It

Imagine an agent generates a change that retries a failed request. The happy-path test passes. The retry test passes too. But what happens if the first request succeeded and only the response was lost? Could the retry charge somebody twice? Where does the system prevent that, and does the generated change preserve it?

Those are questions about how the code fits into the system. I want somebody who can trace the request, understand what gets committed and explain what happens when the network fails at the worst possible moment. Reading the function and deciding it looks reasonable isn’t enough.

You can ask another agent to review it, write tests or explain its reasoning. That can help, but what happens if nobody on the team can tell whether the explanation is right? We’ve asked for a second answer without knowing how to check the first one.

This applies to human-written code too. A colleague saying it works has never been a good reason to stop asking how. The point of review is that someone brings enough understanding to question the implementation, including the parts its author missed.

And software keeps changing. The person who understands today’s implementation can spot when tomorrow’s requirement invalidates one of its assumptions. If all we have is a prompt and an application that appears to work, every change becomes another request we hope produces the right result.

That is the job I don’t see going away. AI may change how much code a developer types or how many people a project needs. I’m sure the work will change. But if I’m responsible for an application, I need to understand what we’re putting into it. Having more code to review hardly makes that less important.

We Invented Guns. Why Are You Still Doing Martial Arts?

To me, the argument essentially boils down to this:

Why are all these morons still doing martial arts when we invented guns?

If the only thing you think someone gets out of martial arts is the ability to hurt another person, I can see how you arrive at that argument. But you’ve missed almost everything that makes people spend years practising it.

Mastering a skill takes time. You repeat the basics long after you think you’ve understood them. Someone corrects something you were convinced you were doing right. You practise, improve a little, get stuck, and come back anyway. Knowing what a movement is supposed to look like and being able to do it properly are very different things.

That takes patience and discipline, but it also teaches you patience and discipline. You learn to accept correction without treating it as an insult. You learn that being bad at something today doesn’t mean you can’t become good at it. And you learn to keep working when the progress is too small to notice after every session. Those are valuable things to carry into the rest of your life, even if you never get into a fight.

So when someone asks why bother now that a more powerful tool exists, my reaction is: why would that make any of those years worthless? You still developed the skill. You still became someone capable of sticking with something difficult long enough to understand it. You don’t lose that because somebody invented a shortcut to one particular outcome.

I feel the same way about programming. Spending hours tracking down a bug can be frustrating as hell, but there is something you learn by forming an explanation, testing it, finding out you’re wrong and trying again. Eventually you get better at questioning your assumptions. You stop changing random things and hoping. You learn to follow the evidence even when it leads back to code you were very proud of five minutes ago.

Reading the final fix doesn’t give you all of that experience. It can teach you something useful, of course, but seeing the answer and developing the judgement to find it are different achievements. That judgement is part of what you bring when you review somebody else’s code, including code generated by AI.

I’m not saying every task needs to be an exercise in suffering. Use the tools. Skip the tedious parts when you can. But don’t confuse being able to get an answer quickly with having developed the understanding to evaluate it. The years someone spent learning still count.

With zenkai, I can spend an evening working on a small optimisation because I want to understand it. Nobody is waiting for me to invoice those hours. I wanted a project where I could follow that curiosity and keep getting better. Telling me I could have skipped the interesting part doesn’t sound like much of an improvement.

The Tool Still Needs Judgement

None of this requires rejecting AI. If it helps you build something, use it. If it saves you from work you don’t enjoy, great. I don’t think manually typing every character makes someone a better developer, any more than using a library makes them a worse one.

But I do care about the judgement applied to the result. Does it solve the right problem? What happens when the input is wrong? Is the performance acceptable for the way it will actually be used? Can the next person maintain it? Those questions still need answers regardless of where the code came from.

Suppose an agent produces a slow implementation. I want to know why it’s slow. Is it the algorithm, the configuration, an unnecessary database query? Being able to find out and fix it is useful whether the first version came from an agent, a colleague or me six months ago.

I’d rather read the code, check the configuration and measure a different implementation than sit around agreeing that everyone involved has always been an idiot.

And if someone understands the problem well enough to fix the output, that is the expertise the argument was trying to dismiss.

I Want People to Care About Their Work

I’ve written before about missing the curious developer, the person who builds something because they want to know whether they can. This is part of the same frustration. I don’t want enthusiasm for a new tool to depend on contempt for the people who enjoyed the work before it arrived.

I’ve seen plenty of bad code. I’ve also read code that taught me something and worked with people who could find problems I would have spent days looking for. I’m not going to pretend that expertise doesn’t exist because it makes an argument about AI easier to win.

Be excited about what AI lets you do. Show me something interesting you made with it. Explain what it helped with and what you still had to figure out. I’d much rather hear that story than another explanation of why none of us ever had any skill to begin with.

I like programming, and I’ll keep doing it because I enjoy it. But my argument for developers goes further than wanting to preserve a hobby. If we’re going to rely on a piece of software, I want people who can read it, question it and explain why we should trust it. Really understand it, including the ugly parts.

Let AI write the code. Somebody still needs to know what we’ve built.

Thank you for your time and patience reading this article