My 13-year-old son builds apps and games by describing what he wants in plain English. I have to admit it is impressive. It also hit me that he doesn’t know any code at all.
So I gave him the speech. I told him it would make him a better builder to understand what sits underneath the software: learn a language, see how the pieces fit, then use the tools. It felt like a reasonable thing to say after 25 years in this industry.
A few weeks later he came to me and said he had done his own research. He wanted to know which language I learned first.
My climb up the stack
I started with BASICA. It leaned on the BASIC interpreter IBM had put on chips on the motherboard of the original IBM PC, and clones without those chips needed a different product, which is why Microsoft later shipped GW-BASIC. Then I learned C, and after that Visual Basic, versions 3 through 6.
Each step gave me something and took something away. C gave me control and made memory my problem. Visual Basic gave me speed and hid most of what Windows was doing underneath. Nobody on my side of the table thought of that as cheating. It was just how you got work done.
The question
He listened, then asked whether I had learned Assembly.
I was honest. A bit, but not much.
He asked one more thing, and it is the question I have not stopped thinking about. What do you think the previous generation said about yours, the one that grew up on Assembly?
I had no answer. First I was proud. He had taken my assumption, tested it, and come back with a thesis of his own. Then it landed. We showed up with C and called it programming, and the people before us had every reason to roll their eyes.
They said it about us too
He was right, and the record backs him. When John Backus’s team at IBM promoted FORTRAN in the 1950s, programmers met the claims with widespread skepticism. Many saw efficient coding as a craft too mysterious to automate, and they did not believe a compiler could match their hand-tuned work.
The skeptics were not fools. They worried about wasted machine time and slow code. Then the compiler turned out to be good. By 1959, many IBM 704 installations used FORTRAN exclusively.
Every generation of programmers has handed a layer down to the machine, and the one before it has called that layer the real work. Syntax is the layer my son is handing off, and I think he is right to.
Here is how I think of it. Each layer handed something to the machine, and each one left something the builder still had to understand.
| Layer | Handed to the machine | Still on you |
|---|---|---|
| Assembly | Nothing, you wrote every instruction | Registers, memory, exactly what the CPU does |
| Compilers (FORTRAN, then C) | Turning code into machine instructions | Memory, performance, how data is laid out |
| Visual Basic | Windows plumbing and drawing the interface | How the system behaves when it breaks |
| AI from plain English | Syntax and most of the code | What to build, how it fails, what it costs, who can see the data |
What is different this time
There is one difference, and it is the one that matters. A compiler is deterministic. The same source gives the same machine code every time, so once a compiler has earned your trust you can stop reading its output.
AI output does not work that way. It varies from run to run, and it can be wrong while sounding certain. Developers know this better than anyone. In Stack Overflow’s 2025 survey of more than 49,000 developers, 84% used or planned to use AI tools, up from 76% a year earlier. Over the same year, the share who trusted the accuracy of those tools fell from 43% to 33%. Use went up and trust went down. The people closest to the work are checking it, which is the right instinct.
Measuring the benefit is harder than it looks. In a randomized study by METR, 16 experienced open-source developers worked on real issues in codebases they knew well. With early-2025 tools they finished 19% slower, and afterward they still believed the tools had made them about 20% faster. METR has since said its newer data is noisy and an unreliable signal, and that developers are probably more sped up today than they were then. So I would not build an argument on the 19%. I would build it on the gap. Skilled people could not tell by feel whether the tool was helping, and telling takes measurement, which takes knowing what good looks like.
What to be careless about, and what not
So, back to my question. Should my son be careless about the technology underneath? Part of it, yes.
Safe to hand off: syntax, the choice between two reasonable languages, boilerplate, and the first draft of anything you can test quickly.
Not safe to hand off: how data moves through the system and who can reach it, what happens when a dependency fails at 2am, what the thing costs at ten times the load, and whether what got built is what you meant to build.
The first list is the layer the compiler took from the Assembly generation. The second list is the work that remains when the code writes itself, and it is the work senior engineers always did. It becomes more valuable as more people can build, not less.
If you run an engineering team
The question for a leader is not whether your people can write code. It is whether they can judge what an AI wrote, and who on your team is building that muscle. Here is what I would do.
- Give every AI-written change a named owner who has read it and can explain it. Authorship stops mattering. Ownership does not.
- Ask for the failure story in review. How does this break, what does it cost at scale, who can see the data? An engineer who cannot answer has not reviewed it yet.
- Keep junior engineers close to the lower layers. Have them trace one request end to end, and pair them with a senior engineer during incidents. That is where the underneath becomes real.
- Measure outcomes, not output. Lines generated mean nothing. Defects that reach production, time to recover and cost per request tell you whether the tool is helping. Feelings do not, as the METR gap showed.
Where I landed
My son is right about the language, and I think I am right about what sits underneath. We were both aiming at different layers.
The Assembly generation was right that something was lost when the compiler arrived, and wrong about what mattered. The code was the layer being handed off. The judgment about the code was not.
I set out to convince him that understanding the layers underneath mattered, and he taught me something instead. I am proud of him for it.
What layer is your team skipping right now, and who checks the work?