This essay is about what engineering is left to humans now that AI writes the code. The conclusion has two parts. Understand the meaning inside the code well enough to direct AI precisely. And read what AI produces closely enough to notice when something is off. For now, both of those are human work.
Earlier, I wrote that self-taught programming doesn't last because of talent, but because of systems. I listed some of self-study's hard spots: stumbling on setup, not being able to read errors, having no one to teach you.
Honestly, from the moment I finished writing it, I was already thinking this: AI is going to melt most of those hard spots away. Paste an error, and AI reads it and tells you how to fix it. Not sure what to build? AI hands you a starting point. Even the biggest loneliness of self-study, having no one to ask, AI fills in. The wall of writing code itself is dropping fast.
So is nothing hard anymore, in self-study or in engineering? I don't think so. Where the old hard spots vanished, a different gap has appeared. That gap is what this essay is about. One thing up front: this is my read for now. I honestly don't know how it will look in a few years, and I'll write that part too.
Why is "being able to write" no longer the wall?
Because AI now handles the syntax, the errors, and the environment setup that used to stop people.
Until recently, the wall in programming was being able to write at all. You memorized syntax, wrestled with errors, and set up an environment. Self-study was said to have a 90% dropout rate, and this is where most people broke.
Now AI does much of that. Working code comes out astonishingly fast and reasonably correct. The bar at the entrance has dropped dramatically. This is a genuinely big change, and I want to admit it plainly. Clinging to the old way and refusing to use AI would be a waste.
What is the new gap: "you can have it built, but you don't understand it"?
Have AI build it, and it runs. But you don't understand what's inside. That is the new gap.
In the earlier article, I wrote about the gap between being able to copy code and being able to build on your own. The AI-era gap is a relative of that one, and a meaner one.
With copying, at least you typed it yourself. Hand it to AI, and you get something that runs without moving your hands at all. It's convenient. But the instant it runs, you feel like you understood, and you stop there. You move on without understanding.
Before, people broke on "I can't build it." Now they move on because "it got built," still not understanding.
Why does AI-written code cause trouble later?
Because AI has a habit of thinking "as long as it runs," and it has no concept of technical debt.
That habit is something I feel whenever I use it. Ask, and it spits out something plausibly working, all at once.
If the current task passes, it's done. The one who has to live with that code next is future you. So left alone, what comes out tends to be code that runs but, for now, causes trouble. The trouble takes three forms.
- You can't fix it later. You don't know what's written where, so you can't find the place to fix.
- You don't understand it. You can't explain in your own words why it runs. The reason it works isn't inside you.
- You can't break it to learn. In the earlier article I wrote that "break it and fix it once a day" makes you grow. If you don't understand the inside, you're too scared to break it. You lose one way to learn.
What is the engineering ahead?
Understanding the meaning inside, and directing AI precisely with that understanding.
So what should you do? The answer is probably this.
When you really understand the meaning inside, you can give AI accurate instructions too. That, I think, is the engineering of the programmer and engineer going forward.
Vague instructions draw out AI's "as long as it runs." Say "make it nice," and you get something that runs nicely but that you don't understand. Someone who understands the inside can instruct precisely: "use this structure here, put this responsibility there." Same AI, different output.
A concrete example: the CLAUDE.md I hand to AI
Let me give one concrete example. When I have AI write code, I use a tool called Claude Code, and I hand it an instruction file called CLAUDE.md. What's in it is not a special invention. It's the principles engineering has talked about for a long time.
- Don't write the same thing twice (DRY)
- Keep it simple, above all (KISS)
- Don't build it until you need it (YAGNI)
- Don't cram responsibilities into one thing (single responsibility, the "S" of SOLID)
- Put the same value or name in just one place (SSOT, a single source of truth)
- Split by concern, loosely, and keep related things together (separation of concerns / loose coupling, high cohesion)
- Align naming and style across the team (coding conventions). Use the parts that already exist, and don't leave extras behind.
In short, it's a document for conveying to AI, accurately, the "right way to build" as I understand it.
What's interesting is that none of this is new. SOLID, DRY, KISS, YAGNI: these are words human engineers built up over decades. Now that AI writes, they haven't disappeared. If anything, the person who understands these fundamentals is exactly the one who can direct AI well. The more precise the instruction, the more the result changes.
One more thing follows from this. The very fact that you have to write an instruction file like this is the clearest proof that AI, left alone, drifts toward "as long as it runs."
Only knowledge that became flesh and blood can be handed to AI
Honestly, the reason I can hand AI the "right way to build" like this is that these principles have become flesh and blood inside me. Knowledge you only read in a book won't let you write this. You build it yourself, stumble, get burned, and finally understand in your gut that this really matters. Only that kind of knowledge comes out as an accurate instruction to AI.
What hasn't become your own flesh and blood, you can't hand to AI accurately either. The time you spent learning, failing, and making it your own is the foundation of your ability to use AI.
So the center of value has moved, from being able to write code yourself to understanding the inside and being able to direct AI accurately. You can hand the writing hand to AI. The understanding head is still held by a human.
Beyond that, it's my own preferences
By the way, full confession: CLAUDE.md goes on further than this. From there, though, it gradually enters the territory of my preferences. I want to write it this way, I like this arrangement, quirks only I have. Less universal principle, more personal insistence. So I'll keep those contents to myself (heh). Probably every CLAUDE.md has some odd insistence slipped in that only its owner understands.
Apart from preference, though, there's one serious premise. Even when you build hand in hand with AI, code usually doesn't stay yours alone. Other people read it. A different AI session writes the next part. Even you, six months later, are basically a stranger to it. So aligning the way you build isn't just for AI's sake. It's for the premise of developing with multiple people. A consistent structure becomes a shared language between people, and between people and AI.
How do you keep understanding while you move forward?
Test small. The method is the same as in the earlier article.
Don't have AI build the whole thing at once. Have it build only the smallest step, check whether you understand it, and move on. Go only as far as your understanding keeps up. This is the AI-development version of self-study's "break it and fix it once a day." The human directs; AI is the fast hands. The smaller the slices, the better your understanding and your instructions hold up.
The moment you have it build something big all at once, a lump of "runs but I don't understand it" is born. So don't rush. Precisely because AI is fast, the human deliberately cuts the work small. Not getting swept up by the speed is the discipline of the AI era.
What skill matters most in the near term?
Reading the code AI produced and noticing that something is off.
If writing goes to AI, what's left to the human is reading. And being able to read isn't enough on its own. What matters most in the near term, I think, is the noticing that comes after the reading.
AI produces things that plausibly run. But "plausible" and "correct" are different. Subtly wrong, somehow risky, structurally warped, and yet it appears to run fine. Faced with output like that, can you read it and stop at "hm, that's strange"? That's becoming the most needed skill on the ground.
What "off" looks like: dead code and needless rebuilds
Concretely, two things. One is useless code left in, never used. The other is rebuilding something similar when a part already exists, instead of using that part. Both run. So if you don't know, you overlook them.
Someone who understands that part of the code notices right away: "this isn't needed," or "just use the one that already exists here." Reading not for whether it runs, but for whether anything extra is left in and whether what should be used is being used. That's what noticing something is off means.
Understand, then read, then notice
This ability to notice comes from understanding the inside. If you don't understand, you can't even tell whether something is off. So the earlier "understanding the inside" and this "noticing it's off" are continuous. Understand → read → notice it's off. Only in that order can you judge whether AI's output is safe to trust.
More than being able to write, being able to read and to feel the discomfort. At least in the near term, I think this is the skill most needed on the ground in the AI era.
Who holds the structure right now?
The human does. AI won't protect the structure on its own.
By structure I mean where to put what, how to manage state, how to divide responsibility. For an AI that thinks "as long as it runs," if it passes, that's fine.
So for now, the human holds the structure. Write in the right place, in the right structure, from the start. Don't allow the stopgap that assumes you'll fix everything later. However fast AI produces code, the design of how to stack it is still, for now, the human's job. This, for now, is the last stronghold of human value, as I see it.
How long does this stay true? The future forks in two
Honestly, I don't know. The fork is whether AI can transcend the very problem of "code you don't understand is trouble."
I've written "the human holds the inside" up to here. The future probably splits in two.
- Branch A (it can't): everyone keeps building "as long as it runs," and incomprehensible implementations multiply like crazy, all over the world. Then the value of people who can understand the inside, read it, and fix it rises instead. Understanding becomes a survival skill.
- Branch B (it transcends even that): AI takes on understanding and maintenance, all of it, before the human is ever troubled. The worry of "trouble if you don't understand" itself vanishes. A day comes when we laugh: "there was a time like that."
Which way it tips, I don't know. So this isn't written as an eternal truth. It's the engineering of now.
Even so, the time you spent trying to understand doesn't vanish
Whichever future arrives, the time you spent moving your hands to understand stays with you.
One last honest thing.
In either future, something still works. In branch A, the ability to understand the inside lives on directly. In branch B, even if this worry becomes unnecessary and the result goes unused, the time you spent moving your hands to understand has become your own flesh and blood.
This is the same thing I've kept writing, in the earlier article and throughout this feature. The time you spent trying doesn't vanish, even if it tips toward the side people later laugh at as "that worry was pointless."
So for now, toward a future I can't see, I test small and move forward while checking for myself. That, I think, is the stance that loses the least, whichever way it tips.
Honestly, this text, and this site, I'm building together with AI, testing small. Whether it works out, I still don't know. Even so, the time I spent trying will, I believe, become flesh and blood.
