The Coding Skills My Son Wants to Protect

7 min read

A graphite-and-coloured-pencil illustration of a phone on a programmer's desk displaying Connor's worry about becoming worse at troubleshooting.

My son Connor sent his answers back to me in a text.

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.”

Reading his answer, I could hear some anxiety underneath it. He’d spent three years getting good at something. What would it mean if the next three years made 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. I thought that was odd since he’d never shown much interest in electronics and always seemed more interested in computers. But it was his decision, and I encouraged him to pursue it.

His younger brother Alec took a different path. When Alec was about twelve, I introduced him to PHP, a database, and Bluehost and encouraged him to build a simple address book—a basic CRUD (create, read, update, and delete) application. Then he started learning Ruby on Rails. By fourteen or fifteen, he was becoming a solid young developer. He went on to internships 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 right after graduating. I was somewhat relieved (just because I understood the industry better), although I worried that an electrical-engineering degree would make the transition harder. But Bell gave him a chance.

At the time, software still looked like safe [fatherly] advice. The pay was excellent. Hiring was strong. The industry was famous for signing bonuses, free meals, and companies competing for talent. My sons and I talked about all of it.

I also knew enough programming to understand what was changing with the advent of ChatGPT. I learned PHP in earnest in my thirties, then a decent amount of Python. 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 could help, I jumped at it. This was before Claude Code and Codex. I copied code out of ChatGPT, pasted the resulting errors back in, and repeated the loop. Even that early primitive workflow saved me a ton of time.

By late 2023, I was reading the hype-versus-stochastic-parrot arguments on Hacker News and Techmeme while also watching the tools improve on YouTube. Some programmers were dismissive about eventual job displacement. Others could see how quickly the capability was moving.

From my strange position—much older than a junior developer but still close enough to learning to remember every obstacle—the writing was on the wall. Business leaders would surely salivate at the idea of cutting headcount and salaries.

The question was how quickly the wall would move.

The upside of using AI as a coding assistant is real. 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 implementation changes what the rest of the job looks like. 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.

That shift is happening while the entry path into programming is becoming less certain.

Stanford researchers using ADP payroll data found a 16 percent relative employment decline among workers aged twenty-two to twenty-five in the occupations most exposed to AI, after controlling for firm-level shocks. Software development was among the occupations with a large early-career decline, though the researchers are clear that AI isn’t the only cause and junior roles haven’t vanished. The pressure at the bottom of the profession is now visible in the data.

The harder question isn’t whether an agent can complete an issue. 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 boundaries earned trust. A mature dependency has a contract, maintainers, a version history, a bug tracker, and a reputation. Generated code placed inside your own repository has no such institution standing behind it. It arrives looking like your code and becomes your problem when it fails.

Connor is now living both sides of this change. In his role, 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 that configures network infrastructure—the software involved in setting 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 blocked the testing Connor actually needed to do without deepening his understanding. Removing that delay is an obvious and deeply felt gain.

But notice how he uses AI 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.

The tool is powerful because Connor already has something to compare its answer against.

He uses it as a private domain expert too. 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 between networking and software language. He can keep asking until the explanation fits the problem. He wouldn’t want to give that up, and neither would I.

He’s also more skeptical than the usual job-replacement argument allows. Claude Code on one engineer’s laptop, he told me, makes that engineer more capable. Replacement becomes more plausible when a company connects AI to its conversations, product plans, technical systems, and operating knowledge, which requires rebuilding how the entire organization works; far beyond distributing chatbot seats.

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.

I still think computer science was a good path for my sons.

It taught them 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, and I’d change the destination. The goal would extend beyond producing code to understanding 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

  1. Cui et al., The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers, Microsoft Research, June 2025.
  2. Annie Vella and Kelly Blincoe, The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study, arXiv preprint, May 2026.
  3. Erik Brynjolfsson, Bharat Chandar, and Ruyu Chen, Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence, Stanford Digital Economy Lab working paper, revised November 2025; authors’ February 2026 update.

FOLLOW THE ABUNDANCE TRAP

I'll send the next essay when it's worth sending.

A short note when something new is published, plus the questions and examples I'm exploring as the book takes shape.