Every few weeks, someone shares a bold opinion: "Don't bother learning to code, AI will do it all." I've seen this from VCs, influencers, and people who have never actually shipped a production system.

They're wrong.

In the past few weeks, I've written about the human-in-the-loop, the future of software engineering, and what these changes mean for enterprise organizations. The core point across all three: AI moved the bottleneck from coding to review, from doing the work to making decisions.

Here's what many people miss: you can't develop good judgment without first learning to code.

You Can't Review What You Don't Understand

My daily workflow looks different now. When an issue comes up, my first thought is to let AI handle it. Security problems in Undici, bugs in Fastify, new features for Platformatic: AI handles the coding for me.

But I still review every change, every behavior update, every line that goes live.

How did I learn to do this? By writing code for years, making mistakes, shipping things that broke in production, seeing how systems behave under pressure. There's no shortcut. You can't review what you don't understand, and you can't understand what you haven't done yourself.

When AI generates a sorting algorithm, I know if it fits because I've built sorting algorithms myself. If it suggests a caching layer, I understand the tradeoffs because I've fixed cache bugs at 3am. When it designs a distributed system, I can spot problems because I've faced them before.

I didn't get that knowledge by watching AI. I learned it by doing the work.

The Skill Changed, Not the Need

I said the job of a programmer who just takes a Jira ticket, completes it, and clocks out is gone. AI can do that now, faster and cheaper. Some people took this to mean: "So don't learn to code."

That's like saying cars exist, so don't learn to walk. Walking builds the balance and awareness you need to drive well. Ignoring coding fundamentals leads to blind spots in technical judgment.

I've watched developers skip understanding algorithm complexity because AI was handling the coding. The result? Inefficient solutions that fell over under real load. Coding builds the mental models you need to be a good reviewer, architect, or technical leader. Without that foundation, you can't judge what AI produces.

The difference is what you're learning to code for. A decade ago, you learned to code because the job was coding. Today, you learn to code because the job is judgment, and judgment requires understanding how software actually works.

That's why I say fundamentals matter again. Algorithms, distributed systems, hardware, caching, networking, databases—they're not just academic topics. They're the foundation for judging what AI creates. You can't learn them by watching. You learn by building.

The Bootcamp Confusion

When I said the bootcamp path to becoming a software engineer is closing, some people misunderstood. I didn't mean "don't learn to code." I meant the old path of learning just enough to get hired, then building missing skills on the job, is broken because those training roles are disappearing.

The answer isn't to stop learning. It's to learn differently. Go deeper. Focus on fundamentals, not just frameworks. Learn why things work, not just how to use them. A proper computer science education—university or serious self-study—matters more now than five years ago.

Bootcamps taught you how to code. Now you need to understand computing itself.

The Software Plumber Needs to Code

I'm excited about what I call the "software plumber": local developers serving small businesses that couldn't afford custom software before. The restaurant needing a reservation system. The auto shop wanting inventory management. The accountant's office needing a client portal.

Some see this and think, "That's just vibe coding; you don't need to know how to code."

You do.

The first version might work with vibe coding. But who keeps it running when the business changes? Who fixes it when it breaks on the busiest weekend? Who knows why the database is slow after six months?

The plumber analogy works because you're not just paying someone to connect pipes. You're paying for their ability to diagnose problems, make good calls, and draw on years of experience with water systems. Software plumbers need that same depth.

AI speeds up building. It doesn't remove the need to understand.

The Enterprise Reality

In my article about enterprise organizations, I described three levels: large companies with full-time senior engineers, mid-sized companies using part-time experts, and small businesses helped by local developers.

At every tier, humans in the loop need to understand code. The senior architect reviewing AI output at a bank needs to understand distributed transactions. The fractional consultant advising a mid-market company needs to understand performance characteristics. The local developer building a tool for a restaurant needs to understand data modeling.

The depth changes. The details differ. But the core skill—reading, writing, and thinking about code—is needed at every level.

IT departments building custom tools instead of buying SaaS? They still need people who can code. Not because coding is the hard part, but because you can't judge, maintain, or improve software you don't understand.

What "Learning to Code" Means in 2026

Here's what learning to code looks like today.

It means understanding how a computer runs your program, what happens when you use memory, how the network stack works, why some data structures are faster for certain tasks.

It means building things from scratch at least once before letting AI do it. Write a web server. Build a cache. Make a simple database. You might not do this in your job, but the understanding you gain is what makes you valuable.

It means reading code. A lot of code: open source projects, production systems, AI-generated code. Being able to read and understand what code does, what it doesn't do, what it gets wrong—this is the most valuable skill for developers in 2026.

Use AI aggressively. Let it accelerate your implementation. But always understand what it produces. Always review. Always be able to say "this is wrong and here's why."

The Real Risk

I'm not worried people will waste time learning to code. I'm worried about the opposite: a generation of developers skipping learning and just prompting AI, leaving us with critical systems nobody understands.

The projections say 75% of code could be AI-generated by 2026. If that happens, the ratio of AI-produced code to human reviewers could get overwhelming. We'd end up with systems beyond human comprehension.

I've made open source contributions I didn't fully understand. I look back on them with regret. Every maintainer has done this, and it always causes problems later. Bugs are harder to fix. Behavior is harder to explain. Technical debt grows.

I wish I'd taken the time to understand that code before accepting it. It would have saved me headaches later. This is why I keep saying: understand before you ship. The stakes are just higher now.

Imagine this at scale. Whole systems built by people who never learned to code. Maintained by people who can't read the code. Breaking in ways no one can figure out.

The human in the loop isn't a limitation. It's a protection. And humans need to understand what they're looking at.

Learn to code first. Then use AI to speed up your work. Do it in that order.