A few days ago I wrote about whether AI-assisted images qualify as Art. Short answer: yes, because Art lives in the vision, not the brush. Now I want to talk about another third of my creative life—the third that most people would not consider creative at all, which only proves they have never done it. I want to talk about code!

What Programming Actually Is

Programming, called coding by programmers (who call themselves coders, because every subculture requires its own jargon or what is even the point), is simply the act of getting your computer, phone, tablet, or smart refrigerator to do exactly what you want. It does not matter if you do it in machine code, Assembler, FORTRAN, COBOL, VB.NET, Python, English, Jive, or Mandarin. What matters is that you have a clear picture in your head of what should happen, and you find a way to make the machine understand and manifest it.

If that sounds familiar, it should. It is exactly the same process I described in But Is It Art?: you have a vision, and you labor to drag it into shared reality. The medium happens to be logic instead of pigment, but the itch is identical. You see something that does not exist yet. You need it to exist. You will not sleep well until it does.

Only a computer programmer would understand this, but programming is one of my passions. The joy of crafting a piece of elegant code that fits seamlessly and efficiently into a project—a project that will help someone be more creative, or at least accomplish a boring goal quickly and in a fun way—is what I live for.

Also, pistachios.

A Brief and Ludicrously Incomplete History

I started programming in 1972, which means I have been at this for fifty-four years. In that time, I have watched the tools change so dramatically that describing them to a younger programmer is like describing radio to a ten-year-old who only knows streaming. Allow me to describe programming to you.

In the beginning—my beginning, anyway—you wrote your program on paper, on a special form called a coding sheet. Then you handed the coding sheet to a person called a keypunch operator, who typed it onto a stack of punched cards. Then you handed the cards to a person behind a window, who fed them into a machine, which ran your program and printed the results. Then you picked up the printout, discovered you had misspelled DIMENSION on line four, wrote a correction on the coding sheet, handed it back to the keypunch operator, and waited another four hours. This was called a fast turnaround.

Eventually we got terminals, and then personal computers, and then the ability to type our own code directly into the machine. This was an astonishing improvement. Instead of waiting four hours to discover a misspelling, you could discover it in four minutes. The misspellings did not decrease, but the lag did.

Then came integrated development environments—Visual Studio, Eclipse, IntelliJ—that could catch some of your errors as you typed, which was like having a very patient, very literal-minded copy editor sitting on your shoulder, tapping it every time you forgot a semicolon. Programmers complained about this, naturally. Programmers complain about everything. It is our second-favorite activity, right after arguing about which text editor is best. (The answer is Visual Studio, and I will fight you.)

Enter the Amanuensis

And now we have AI. And the question that everyone keeps asking—the question that is the title of this essay—is whether the code that an AI helps you write is really your code.

I find this question hilarious, and I find it hilarious for a very specific historical reason: nobody ever asked this question about the programmer who used a keypunch operator.

Think about what a keypunch operator did. You handed her (it was almost always a her in the 1970s) a sheet of paper listing each individual thing you wanted the computer to do. And we're talking about a single line that might say, "Add hours-worked to total-hours." And there could be 5000 or more lines just as detailed. The keypunch operator would then create punch cards, one for each line. If she made a mistake, she would have to throw away the card and make a new one. She was fast. She was accurate. She sometimes caught your errors and fixed them silently, because she had been doing this longer than you and she knew that DIMENISON was not a COBOL keyword. And nobody, not once, suggested that the resulting program was hers.

An AI coding assistant is a keypunch operator. A very, very fast keypunch operator who has read every programming manual ever published and never takes a coffee break. I describe what I want—sometimes in precise technical language, sometimes in a vague wave of the hand like "make the dialog box not look terrible"—and the AI translates my intent into syntactically correct code that I then review, test, adjust, and integrate into the larger design. The design is mine. The architecture is mine. The decision about what the software should do and why is mine. The AI is just typing it up for me, like a really smart keypuncher.

It is, if you want to get fancy about it, my amanuensis. A word that means "secretary," but in Latin, so it sounds more dignified. (If you want to understand what an amanuensis actually does in a dramatic, lived‑in way, Cloud Atlas is a surprisingly rich place to start. Its 1930s storyline follows a gifted young composer who becomes the amanuensis to an aging maestro—copying scores, refining themes, and quietly shaping a masterpiece while navigating the power dynamics of genius and dependency. The film's reincarnation structure adds an extra layer, showing how creative influence and mentorship echo across lifetimes. It's an ambitious, rewarding watch, and you can find it on IMDb here: Cloud Atlas.

What Has Actually Changed

Here is what AI has not changed about programming: the thinking. The hard part of building software has never been the typing. (Well, it used to be; but that's the point of improvements!) The hard part is figuring out what the software should do in the first place, how the pieces fit together, what happens when the user does something unexpected (they will), and how to make the whole thing maintainable by your future self, who will have forgotten why you did it that way and will curse you for not leaving a comment. The hard part is design, and no AI I have encountered does design. Not yet. Maybe never. Design requires wanting something, and wanting is not yet in the AI skill set.

Here is what AI has changed: the ratio of thinking to typing. It used to be that I would spend twenty minutes thinking about how a control should work, and then ninety minutes typing the implementation, discovering mistakes in my logic while typing, retyping, testing, finding more mistakes, and gradually converging on the thing I had envisioned. Now I spend the same twenty minutes thinking—sometimes more, because the thinking is the fun part and I am freed to indulge it—and then five minutes describing what I want. The AI produces a first draft. I try running it, find the things it got wrong (there are almost always a few, though Claude's top-tier Opus LLM is really good), describe the corrections, and we converge on the final version in a fraction of the time.

The result is not that I produce more code. The result is that I produce better code, because I have more time to think about whether the code I am producing is the right code. The bottleneck was never my typing speed. The bottleneck was the cognitive overhead of translating design into syntax, which consumed attention I would rather have spent on the design itself. The AI has removed the bottleneck, and what has rushed in to fill the space is joy.

The Joy, Specifically

I need to be specific about this, because people who do not program will not otherwise understand it, while people who do program will nod so vigorously they will hurt their necks.

There is a particular pleasure in a piece of code that is exactly right. Not just functional—any code can be functional if you beat on it long enough—but elegant. Code where every line earns its place. Code where the names of things tell you what they do. Code where the structure mirrors the logic so precisely that reading it feels less like decoding and more like agreeing. You look at it and think, Yes. That is how that should work. That is the only way that could work!

This is the programmer's equivalent of the artist stepping back from the canvas and realizing, with a small shock, that the painting is finished. Not because there is nothing left to add, but because there is nothing left to remove. Saint-Exupéry said that about airplanes, and he was right about airplanes, and he was right about code, and he was right about sentences, and he was probably right about most things, which is why he is still quotable eighty years later despite having crashed into the Mediterranean.

Before AI, I spent most of my programming time on the mechanical parts—the syntax, the boilerplate, the tedious plumbing that every application needs but nobody finds interesting. The elegant parts, the parts that sparked joy, were islands in a sea of drudgery. I still loved programming, but I loved it the way you love a garden: the flowers are glorious, but most of the time you are pulling weeds.

Now the AI pulls the weeds. And I spend my time among the flowers. My joy in perfecting the already-perfect application, or polishing a library of reusable controls until each one is a small gem of purpose and clarity, far from being diminished, has increased twentyfold. (Corrected from 20.119-fold, because Claude asked if I really wanted to be that precise.)

The Craft Remains

I wrote my first book on Windows Programming Power with Custom Controls in 1994. The book was about building reusable software components—small, focused pieces of code, each one designed to do one thing thoroughly and well, that you could drop into any project and trust to behave. I believed then, and I believe now, that this is the highest form of programming: not building applications, but building the pieces from which applications are built. Tools. Libraries. Frameworks. Components that are so well-designed they feel inevitable, as if they had always existed and you merely discovered them.

AI does not change this. If anything, it sharpens it. When the mechanical cost of writing code drops, the design cost becomes the dominant factor, and suddenly the questions I have always cared about—Should this be a property or a method? Does this control have the right public API? Is this abstraction earning its complexity?—are the only questions left. The AI cannot answer them. The AI does not even understand why they matter. But I do, and now I have more time to sit with them, turn them over, get them right.

Yesterday I spent forty minutes deciding whether a UserControl should expose its chosen items as a List(Of String) or as an IEnumerable(Of String). The AI would have happily given me either. Both would have worked. But one was right, and finding the right one was the work—my work, the human work, the work that no amount of machine learning will automate because it requires caring about the answer.

That is what programming is. Not typing. Caring.

The Part Where I Get Sentimental

I am seventy-four years old. I will be seventy-five in April. I have been writing code for longer than most of my colleagues have been alive, and I have watched every major shift in the industry from punched cards to cloud computing. I have written in twelve computer languages. (I think. Truthfully I have lost count. Does anyone remember SNOBOL?) I have shipped software that people used. I have written four technical books, including one that was considered in the technical area as being a bestseller. I have earned my opinions.

And my opinion is this: AI is the best thing that has happened to programming since the development of object-oriented programming (another thing I "wrote the book" on).

It has not replaced me. It has freed me. It has taken the parts of my craft that were labor and left me with the parts that are love. At an age when I might reasonably be expected to slow down, I am instead building more, building better, and having more fun than I have had since the 1990s, when Visual Basic first made it possible to design a user interface by dragging things around with a mouse and I thought, Well, it's not going to get better than this!

It got better than that.

The vision is still mine. The architecture is still mine. The obsessive, borderline-compulsive need to make every pixel, every property name, every public API feel inevitable—that is still mine, and it will be mine until they scatter me over the Sonoran Desert or wherever I end up. (I have left instructions for my ashes to be scattered over Chris Evans, but I have a feeling that is not going to happen.) The AI is my keypunch operator, my amanuensis, my absurdly well-read typing pool. And like my radio station boss said in that studio fifty-four years ago: the measure of a craftsman is not the tools he uses, but how well he uses them.

I intend to use this one until they pry it from my cold, dead, impeccably manicured fingers.

Now if you'll excuse me, I have a library to polish. I think one of the controls might be off by a pixel.