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 thinking it myself: AI is going to melt most of these hard spots away.
Paste an error and AI reads it and tells you how to fix it. Stuck on what to make, and AI hands you a starting point. Even self-study's biggest loneliness — no one to ask — AI fills in. The wall of writing itself is dropping fast.
So is there nothing hard left, in self-study or in engineering? I don't think so. In place of the hard spots that vanished, a different gap has appeared. That's what I want to write about today. Up front: this is my read for now, and I honestly don't know how it'll look in a few years. I'll write that part too.
Once, "being able to write" was the wall. Now AI writes
Until recently, the wall in programming was "being able to write." Memorize the syntax, wrestle with errors, set up the environment. They said self-study had a 90% dropout rate because this is where everyone broke. Now AI does much of that. Working code comes out astonishingly fast, and reasonably correct. The bar at the entrance has dropped dramatically. First, I want to honestly admit this. Clinging to the old ways and refusing to use AI would be a waste.
But a new gap appeared — "you can have it built, but you don't understand it"
In the earlier article, I wrote about the gap of "being able to copy, but not to build on your own." The AI-era gap is a meaner cousin. Have AI build it, and it runs. But you don't understand what's inside. With copying, at least you typed it yourself. Hand it to AI, and you get "something that runs" without even moving your hands. Convenient. But the instant it runs, you feel like you understood, and you stop. Before, you broke on "can't build it." Now you proceed, not understanding, on "it got built."
AI tends to think "as long as it runs"
Using it, I feel AI has a habit of thinking "as long as it works." Ask, and it spits out something plausibly working, all at once. But AI has no concept of technical debt. If the current task passes, it's done. The one who'll struggle with that code next is future-you. So left alone, what comes out tends to be code that "runs, but (for now) causes trouble." Three kinds:
- Can't fix it later: you don't grasp what's written where, so you can't find where to fix.
- Don't understand it: you can't explain in your own words why it runs. The reason it works isn't inside you.
- Can't break it to test: in the earlier article I wrote that "break it and fix it once a day" makes you grow. But if you don't understand the inside, you're too scared to break it. You lose one way to learn.
The engineering ahead is "understanding the meaning inside"
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 you don't understand). Someone who understands the inside can instruct precisely: "structure it this way here, put this responsibility there." Use the same AI, and what comes out changes.
Let me give one concrete example. When I have AI write code (I use a tool called Claude Code), I hand it an instruction file called CLAUDE.md. What's in it isn't a special invention — it's principles long talked about in engineering.
- 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 extra behind.
In short, it's a document for conveying, accurately to AI, the "right way to build" that I understand.
What's interesting is that none of this is new. SOLID, DRY, KISS, YAGNI — words human engineers built up over decades. Even now that AI writes, far from disappearing, the person who understands these fundamentals is precisely the one who can direct AI well. And — the very fact that you have to write such an instruction file is, more than anything, proof that AI, left alone, drifts toward "as long as it runs." The more accurate the instruction, the more what comes back changes.
And honestly — the reason I can hand AI the "right way to build" like this is precisely because these have become flesh and blood inside me. Knowledge you only read in a book won't let you write this. Only the things you understood in your gut — by building it yourself, stumbling, getting burned, and finally seeing "this really matters" — come out as accurate instructions to AI. What hasn't become your own flesh and blood, you can't hand accurately to AI either. The very time you spent learning, failing, and making it your own becomes the foundation of your power to use AI.
So the center of value moved from "being able to write code yourself" to "understanding the inside and being able to instruct AI accurately." You can hand the writing hand to AI. But the understanding head is still held by a human.
— By the way, full confession: CLAUDE.md goes on further than this. But from here it gradually enters the territory of "my preferences." I want to write it this way, I like this arrangement — quirks only that person has. Less a universal principle, more just particularity. So I'll spare you the contents (heh). Probably every CLAUDE.md has, slipped in, some odd insistence only its owner understands.
But apart from preference, there's one serious premise. Even building hand-in-hand with AI, code usually doesn't stay yours alone. Others read it. A different AI session writes the next part. Even you, six months later, are basically a stranger. So "aligning the way you build" is not just for AI's sake, but for the premise of developing with multiple people. A consistent structure becomes a shared language between people (and AI).
The method is "test small"
So how do you proceed "while still understanding"? The method is the same as the earlier article. Test small. 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. Proceed 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 instant you have it build something big at once, a "runs-but-don't-understand" lump is born. So don't rush. Precisely because AI is fast, the human deliberately cuts it small. Not getting swept up by the speed is the discipline of the AI era.
What works in the near term is "reading code and noticing it's off"
If the writing goes to AI, what's left to the human is reading. And what works most in the near term, I think, is not just being able to read, but reading AI's output and being able to notice "this is somehow off." "Plausible" and "correct" are different. Subtly wrong, somehow risky, structurally warped — yet it looks like it runs fine. Against output like that, can you read it and stop at "hm, that's strange"? This becomes the most needed skill on the ground.
Concretely, it's this. Useless code left in, unused. Or, even though a part is already prepared, not using it and going out of the way to rebuild something similar. Both run. So if you don't know, you overlook them. But someone who understands the place notices right away: "this isn't needed," "here, you should just use the one that already exists." Being able to read not for whether it runs, but whether anything extra is left in, and whether what should be used is being used. That's what noticing it's off means.
And this "noticing it's off" comes from understanding the inside. If you don't understand, you can't even tell whether it's 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, this is, I think, the most needed skill on the ground in the AI era.
For now, the human holds the structure
AI won't, on its own, protect the structure — where to put what, how to manage state, how to divide responsibility. Because "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 spits out code, the design of how to stack it is, for now, still the human's job. This, I think — for now — is the human's last stronghold of value.
Honestly, the future forks in two
I've written "the human holds the inside" up to here, but let me be honest. I don't know how long this stays true. The future probably splits in two — over whether AI can transcend the very problem of "code you don't understand is trouble."
- Branch A (can't transcend): everyone keeps building "as long as it runs," and incomprehensible implementations increase like crazy, all over the world. Then the value of people who can understand the inside, read it, fix it, rises instead. Understanding becomes a survival skill.
- Branch B (transcends even that): AI takes on understanding and maintenance, all of it, before the human is ever troubled, and 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
One last honest thing. In either future, there's something that works. In branch A, the power to understand the inside lives on directly. In branch B too — even if this worry becomes unnecessary, the time you spent moving your hands to understand has become your own flesh and blood. Understanding stays with you, even if the result goes unused. The time you tried — even if it tips toward the side later laughed at as "that worry was pointless" — doesn't vanish. This is the same thing I've kept writing in the earlier article and throughout this feature.
So for now, toward an unknown future, I test small and proceed 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.
