What, Why, How, and AI

When was the last time you really cared about the lines of code that went into something that you use each day? There are easily hundreds of millions of lines of code between you reading these words and me writing them. The text editor, the window system and display stack in my laptop, a networking stack that I use to push these changes up to the internet, servers and routers that talk to each other to get your web browser (itself a work of engineering), and then all the local device stuff that draws the pixels that glow to produce the words you then decode into the thoughts you’re hearing in your head right now.

That’s a lot of code for a relatively simple act - reading some words.

The tech industry for decades has been gradually building this tower of babel that lets you do things past generations could hardly dream of. Words written or spoken, video captured, beamed around the globe in fractions of a second. Millions and millions of lines of machine instructions orchestrating every tiny little bit, papering over the uncomfortable realities that make such systems unreliable.

And yet, the code has almost nothing to do with the experience. The point of the code is to enable us to do things that are far more human.

I recently got through Peter Naur’s “Programming as Theory Building” article. The point he makes is that programming is about the model we build in our head of the problem we’re trying to solve (what I’ll call the “why”) and our idea of the solution to that problem (the “what”). The “how” we then implement in code is its own, separate model downstream of the first two. Code, in isolation, is meaningless unless grounded in a “what” and especially a “why”.

But what does this have to do with AI?

Many software engineers are finding themselves in a weird spot in the last six months. Steering an AI model to generate code is surprisingly effective at this point in 2026. AI models are able to find, exploit, and fix arcane and obscure bugs in open source software to the point that many projects are having to come up with new ways to cope with these tools. Average programmers can churn out a high volume of better-than-average blobs of code. The line is increasingly blurry between “this is clearly AI” and “this was written by a human” - and I believe this is particularly true in software.

Software is one of those domains where there are usually a few ways to solve a problem, but all of them must meet strict syntax requirements. AI tools are pretty good at verifying the correctness of generated code, and with a little tuning it can make output that looks just like something anyone on the team might write.

Peter Naur’s article has me thinking a lot about the disconnect that AI is driving when it comes to these three models of “why”, “what”, and “how”. AI is particularly good at producing a lot of lines of tokens. Whether those tokens cohere into meaningful words, code, or ideas is something that requires some sort of grounding.

Code generation works with AI reasonably well because that “grounding” can happen with automated tools - tests, linters, static analysis, types, style guides, and more. Software teams have been building tools like this for decades, and the whole industry benefits in a unique way when what we build can inspect itself to see if it meets a few measurable standards of “good code”.

Whether that code actually suits some broader solution, and then more broadly why we care about solving those problems in the first place, becomes far more abstract than any AI model has been able to reach thus far.

It’s all in your head

To me, Naur’s point seems to boil down to the fact that the code is downstream from what we believe about the code. Our belief about “what” it does and “why” it does it matters far more than “how” it gets done. If you don’t believe me, consider how many professional software engineers do just fine without having a clue about how assembly works. That is a more accurate “how” than any line of Python or Ruby or even C, and yet somehow we don’t care. The “how” is reliable enough to get us to the “what” and the “why”.

This may seem like an excuse to lean hard on AI to solve all our “how” problems. Who cares if the “how” is now delivered in a few seconds what may have taken a few days before? It’s still the same blob of code in the end, right? And even if it’s a little different from how we might have made it, if it works, it works, right?

The process of coming up with the “how” is part of refining our understanding and even belief about our “what” and our “why”. That process is entirely tacit - it’s not something that you can read from just skimming through a blob of code. It’s true that you can get some idea of it when you look at a broader scope of code. Even then, the model we have in our heads about “what” we are building is the thing we socialize with teammates and especially customers.

We don’t sell customers lines of code. We sell them solutions to their problems. If we don’t understand the “what” and the “why”, we can never really build that shared understanding.

Shared understanding is the thing we are missing

Coming to a shared understanding with other people is something I think we’ve lost with the rise of faster cycles in society. Our processors have profoundly higher clock cycles than the chips of a few generations ago. Our news and information cycles have gone from weekly to daily to 24 hour and now right down to the millisecond. There is more information being generated every second than any person could reasonably understand in many lifetimes. We are drowning in all of that “how”, and never getting enough room to breathe to really understand the “what” or the “why”.

I believe that there’s a tradeoff between frequency and friction. They are inversely correlated. The higher the frequency of something, the lower the friction has to be. This applies just as much to a combustion engine or electric motor (more friction means the motor runs slower and hotter) as it does to a processor (the way we drive processor frequencies higher is by reducing the friction of electrons hopping around atoms).

It works the same way for people. Spotify took all the friction out of music discovery, to the point that you can listen to just about any music you can think of. And yet, all the playlists start to sound the same once the algorithm picks up a bit of your tastes. Even worse, you lose the magic and serendipity of swapping mixtapes or burned CDs with friends and discovering a great new sound because a friend-of-a-friend passed a track along.

That magic was the opposite of convenience. The friction is what made it good. It forced you to bump into other people, to give gifts and to share what you loved. That friction gave us enough space to start to build our own tastes, our own model of “what” we liked and even “why” we liked it.

Putting the friction back

I think if we’re going to survive whatever AI future is impending upon us, the things that are going down in friction are going to go up in frequency. We’re going to get more code, we’re going to get more clickbait, and more personalized ads. I don’t know that I really need more of any of that. If the cost of the next word is approximately zero, and tuned to maximize your engagement (something that’s been true for a while, but goes even higher as AI turns up the dial), what changes?

When it comes to coding and code review, we’re already seeing proposals for more friction. Vouching systems (where you can’t contribute unless you’re already trusted by others) aren’t exactly new, but they’re having a renaissance as a way to push back against AI pressure. Paradoxically, I think pair programming with AI assistance may be more useful than when XP was introduced.

That extra friction of another person forces everyone to be honest about the point of it all: it was never the code. It was always about building shared understanding and consensus.

Friction for friction’s sake is not the point. But, if the triad of “why-what-how” models is lopsided because “how” is getting inflated from tech’s frequency going through the roof, friction that keeps us grounded in our “what” and especially our “why” is more than beneficial. It may be the thing that saves us.