The Coding Skills My Son Wants to Protect
My son Connor texted me his answers.
I’d asked what worried him about AI and his programming career. I wanted to hear his own concern, not a ten-year prediction or a CEO’s forecast.
“I’m probably going to lose the good problem solving and debugging muscles that I’ve developed,” he wrote.
Connor has spent roughly three years building those muscles as a developer at Bell Canada. He’s learned how to stay with a problem, follow a bad assumption into the system, read the logs, form a theory, test it, and start again. Now he can give an agent the code, the logs, the architecture documents, and the configuration files and ask it to point him toward the problem.
That’s super useful. It’s also, in his words, “very easy and tempting to do all the time.”
I could hear the anxiety underneath his answer. He’d spent three years getting good at something. Was the next three going to make him worse at it?
I wasn’t reading this as an expert on the future of programming. I was reading it as his dad.
The story I used to tell about my sons and their careers in programming was much tidier than the one unfolding now.
Connor came out of high school wanting to study electrical engineering. That seemed odd. He’d never shown much interest in electronics and always seemed more interested in computers. Still, it was his decision, so I encouraged him (parenting occasionally involves shutting up).
His younger brother Alec took a different path. At twelve, I introduced him to PHP, a database, and Bluehost and encouraged him to build a simple address book. By fourteen or fifteen, he was becoming a solid young developer. He later interned at Tesla and Stripe, then joined Stripe (where he is now).
Near the end of Connor’s electrical-engineering degree, he changed direction. He took an internship focused more on coding and decided to look for programming work after graduating. I was relieved (mostly because I understood software better), though I worried his degree would make the transition harder. Bell gave him a chance.
At the time, software looked like safe dad advice. The pay was excellent, hiring was strong, and companies were throwing around signing bonuses and free meals as if the party couldn’t end. My sons and I talked about all of it.
I’d learned PHP in earnest in my thirties, then a decent amount of Python, so I knew enough programming to see what ChatGPT was changing. My method was familiar to anyone who learned that way: take a Udemy course, build a scraper or a small application, get stuck, search Stack Overflow, try the answer, get stuck somewhere new.
Ideas and marketing came easily to me. Getting code syntax right and turning an idea into working software did not.
So when ChatGPT showed up, I jumped at it. This was before Claude Code and Codex. I copied code out, pasted the errors back in, and repeated the loop. Even that primitive workflow saved me a ton of time.
By late 2023, Hacker News and Techmeme were arguing about hype and stochastic parrots while the demos kept improving. I was much older than the typical junior developer, but I still remembered every obstacle from learning to code. The writing was on the wall: business leaders would salivate at cutting headcount and salaries.
The question was how quickly the wall would move.
And to be fair, this stuff works. Across three randomized workplace experiments involving 4,867 software developers, access to an AI coding assistant increased completed tasks by about 26 percent, with larger gains among less-experienced developers.
But faster code changes the rest of the job. In a 2026 longitudinal study of professional engineers, 82 percent reported spending less time writing code. The researchers described the emerging work as “supervisory engineering”: directing, evaluating, and correcting what AI produces.
The harder question isn’t whether an agent can complete an issue… it’s what happens to the judgment required to understand what the agent produced. Programming has survived many rounds of abstraction. Compilers, higher-level languages, open-source libraries, package managers, frameworks, and cloud infrastructure all allowed developers to stop understanding some layer below their work.
Those abstractions earned trust because they came with boundaries. A mature dependency comes with a contract, maintainers, a version history, a bug tracker, and a reputation. Generated code comes with none of that. It lands in your repository looking like your code and becomes your problem the moment it breaks.
Connor sees both sides in his own work. AI can remove hours of waiting for hardware. It can also tempt him to hand over the debugging skills he wants to protect.
He’s working on a provisioning system used to set up internet service on routers. Testing a new feature normally requires a fully configured physical device. In the development environment, those devices are scarce and slow to set up.
Connor used AI to help build a way to seed the database with realistic data. The system behaves as if a physical device has been fully provisioned even though no hardware is involved. A slow manual loop became something he could run repeatedly in seconds. He estimates that it saves him hours per week during active development.
Waiting for scarce hardware taught Connor nothing. It only blocked the testing he actually needed to do. Removing that delay is an obvious win.
He’s much more careful when the change touches a codebase he already knows.
He asks for pseudocode first. He steers the proposed implementation until it matches the shape he has in mind. Then he lets the tool write code, skims the result, and tests it.
He also uses AI as an endlessly patient domain expert. If he needs to understand a networking protocol, he can ask basic questions without worrying about wasting a senior network engineer’s time or translating the question into software terms first. He can keep asking until the explanation fits the problem. He wouldn’t want to give that up, and neither would I.
Connor is also less impressed by the usual job-replacement hot take. Claude Code on one engineer’s laptop, he told me, makes that engineer more capable. Replacing the engineer becomes more plausible when a company connects AI to its conversations, product plans, technical systems, and operating knowledge. That requires rebuilding how the organization works, not sprinkling chatbot seats across the org chart.
This is why his worry about debugging matters. AI is most useful to him when he understands enough to direct it. The capability he wants to protect is the capability that makes the tool valuable.
Learning to program taught my sons to break a problem into components, to adapt across languages, to get unstuck, and to experience the breakthrough that comes after a problem has resisted them for days. They learned concepts underneath syntax. They learned that confusion can be worked through.
If they were sixteen now, I’d still encourage them to pursue it. I’d be more honest about the uncertainty. But I’d change the destination. Producing code wouldn’t be enough. I’d want them to understand the system around it: the product, the architecture, the failure modes, the security boundaries, and the people who will depend on it.
Become a systems thinker who can steer the machine. Keep enough of the difficult work to know when it’s wrong.
Connor told me how tempting it’s become to hand an agent everything it needs to find the problem. I want him to protect the pause before he does, often enough to keep the skill that lets him judge the answer.
Notes and sources
- Cui et al., The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers, Microsoft Research, June 2025.
- Annie Vella and Kelly Blincoe, The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study, arXiv preprint, May 2026.