The Knowledge and Skills I Mastered Were Swallowed by GPT

Just as my parents firmly believed I could read and write, I took it for granted that my child would also be able to program like me. Programming is an emerging art and a fundamental skill that is becoming increasingly important. Mastering programming is a beneficial supplement to a child’s literacy skills and can help them remain competitive in the job market. As I write these words, my wife is pregnant with our first child, about three weeks away from the due date. I am a professional programmer, but by the time my child can type, programming as a valuable skill may have faded from this world.

I first had this thought on a Friday morning this summer while I was developing a small amateur project. A few months ago, my friend Ben and I decided to try to let the computer create a crossword puzzle in the style of The New York Times entirely on its own. In 2018, we had used software to create a word puzzle, and we did very little—just made a few modifications based on demand in certain places. Now, we were trying to develop a crossword puzzle generation program that required no human intervention.

In the past, developing similar projects involved both hardware and software, and Ben was better at hardware. We once made a neon sign that would light up when the subway approached the station near our apartment. Ben was responsible for making the glass tubes and connecting the circuit board to the transformer, while I wrote the code to process traffic data. Ben also had some programming experience, but it was brief and had been over twenty years ago, so the main programming work was left to me. However, for the new crossword puzzle project, Ben introduced a third “participant”. He subscribed to ChatGPT Plus and used GPT-4 as a programming assistant.

Then, some strange things happened. Ben and I discussed some programs needed for the project. Then, soon, Ben had it ready. One time, we needed a command that could print a hundred lines of random content based on a dictionary file. I thought for a while with no idea, so I tried using Google Search. I tried some methods I could find, and just as I was about to start writing code, Ben told GPT-4 our idea and got perfectly runnable code.

Commands like this are notoriously tedious, and everyone should look them up, so they don’t count as real programming. A few days later, Ben said he wanted to develop an iPhone app that could score words from the dictionary, but he didn’t know how painful it was to develop iPhone apps. I had tried several times and gave up halfway. I found Apple’s development environment hard to get into, not only requiring learning a new programming language but also getting familiar with new programs for editing and running code. You also have to learn various “user interface components” and how to combine them, and finally, you need to figure out how to package the application. There was a mountain of things to learn, and it didn’t seem worth it. However, the next morning, a fully compliant application appeared in my inbox. It ran perfectly and had a very cute design. Ben said he spent a few hours making it, and GPT-4 did most of the tedious work.

Nowadays, most people have had experiences using AI, but not everyone is impressed by it. Ben recently said, “I didn’t really respect it until I started having it help me write code.” I suspect that those who are naturally skeptical, who watch ChatGPT output awkward text or false facts, will still underestimate what is happening.

The knowledge and skills that once took a lifetime to master can now be swallowed in one bite. For me, programming has always been an endless and colorful field. Now, I find myself wanting to write an elegy for it.

I think of Lee Sedol. Lee Sedol was once a world-class Go player and a national hero in Korea, but he is now most famous for losing to a computer program called AlphaGo in 2016. At the beginning of the match, Lee Sedol believed he could easily defeat the AI. However, after several days of competition, he lost. Lee Sedol said at a press conference, “I apologize for my incompetence.” Three years later, he retired. It seems there was a question troubling Lee Sedol: what will happen to something he devoted most of his life to?

My obsession with computers began when I was six years old. It was in the early 90s in Montreal when my brother and I were playing Mortal Kombat. He told me some “finishing moves”—some terrible yet clever ways to defeat opponents, but we didn’t know how to execute these skills. He dialed into an FTP server using an MS-DOS terminal and typed some obscure commands. Soon, he printed out a page of code—the command for the finishing moves used in the game. We went back to the basement and started blasting each other.

I once thought my brother was a hacker. Like many programmers, I dreamed of breaking into and controlling remote systems, not to create chaos but to find hidden things. In 1986, Loyd Blankenship wrote in the Hacker Manifesto, “My sin is curiosity.” In the 1995 movie Hackers, there is a scene where Dade Murphy proves himself in an underground club: someone pulls out a colorful computer book from a backpack, and Dade recognizes each one from the cover: a green book about the international Unix environment, a red book about the N.S.A.’s trusted networks, and a book with a cover showing a guy in a pink shirt playing with an IBM PC. Dade applied his expertise to the school’s sprinkler system and helped clean the ballast of an oil tanker—all done by typing on a keyboard. This story tells us that knowledge is power.

But how do you learn hacking skills? When I was in fifth grade, my family settled in New Jersey. In high school, I went to the Borders bookstore in Short Hills and bought Ivor Horton’s Beginning Visual C++ (which is 1200 pages long)—my first magic book. Like many other tutorials, it started simply, then suddenly became not so simple. Medieval students referred to the moment beginners encounter learning failure as the “Bridge of Asses” moment. This term comes from the fifth proposition of the first book of Euclid’s Elements, which is the first concept in the book that is difficult to understand. Those who successfully crossed the bridge would continue mastering geometry, while those who could not only sighed in vain. Section 4.3 of Beginning Visual C++, which is about “dynamic memory allocation,” was my bridge of asses. Unfortunately, I couldn’t cross it.

(Image source: veer图库)

But I didn’t give up on the subject; I remember the moment things changed. It was a long flight, and I brought a heavy laptop and a CD-ROM with the Borland C++ compiler. The compiler converts the code you write into machine-executable machine code, and I spent several days getting this compiler to run. As is customary, every programming beginner’s first program is “Hello, world.” When I tried to run my version, I only saw endless error messages. Solving one problem led to another. I had read the Harry Potter series, and I felt like I had a broomstick but hadn’t learned the spell to make it fly. I knew what might happen if I could do it, so I persevered. I learned that programming is not really about knowledge or skills but about patience, or rather, an obsession with it. Programmers are people who can endure endless tedium. Imagine explaining how to assemble furniture to a fool over the phone in a language you rarely speak, without pictures. Now imagine that the only response you get is that you made an absurd suggestion, and the furniture looks less and less like furniture. So when you finally finish it, you feel a sense of relief. I clearly remember leaning over the aisle of the plane and pressing the enter key one last time. Then I sat up, and this time the program did what I wanted it to do. “Hello, world” appeared above the cursor, as if a sage had awakened and introduced himself to me.

Most of us will not become the kind of hackers described in Hackers. The so-called “hack” in programmer’s terms is fixing—expressing creativity through code. I never formally learned programming; I just tinkered around, making the computer do some useful or enjoyable little things. When I was a freshman in 2006, I wrote a program to search for leaderboard information on pgatour.com so that I wouldn’t miss Tiger Woods’ ranking in the Masters. Later, after reading Ulysses in English class, I wrote a program that randomly extracted sentences from the book, counted their syllables, and compiled haikus—a more primitive form of language regurgitation than today’s chatbots, but I thought it could write real poetry:

I began to take programming seriously. I proactively offered to develop programs for a friend’s startup. I gradually realized that the world of computers is vast, like sedimentary layers in geology, orderly. From web browsers to transistors, each subfield or system is built on older subfields or systems, layered but organized. The deeper you dig, the more you feel the “mechanical empathy” that race car driver Jackie Stewart spoke of—a perception of the advantages and limitations of machines, knowing how to make them work.

In my friend’s company, I felt my mechanical empathy growing. In my sophomore year, my friend and I watched Danger Zone, and he suggested I make a game based on it. I thought for hours and then disappointingly told him it was beyond my ability. However, the idea resurfaced in my junior year, and by then, I finally found a solution. I now had a better understanding of what the machine could do. I spent the next 14 hours developing the game. A few weeks later, playing this game became a regular activity among my friends. This experience was profound. I could understand why people would want to spend their lifetimes on handcrafted art: there’s nothing more enjoyable than watching others enjoy what you’ve made.

During this time, I was completely immersed in a “House of Cards” state and put learning aside. I worked hard, but not on learning. One night, I used six machines to run a program in parallel in the basement. I laid the printouts full of numbers on the floor, thinking about a path planning algorithm. The cost was that I experienced a nightmare—taking a final exam while knowing nothing. In 2009, during one of the worst financial crises in decades, I graduated with a GPA of 2.9.

But I still got my first full-time job easily. I had programming experience, and no one asked about my grades. For young programmers, this was their boom time. Companies were competing for top programmers. The competition for experienced programmers was so fierce that they complained about their inboxes being flooded with recruitment emails. The popularity of computer science majors exploded. (My degree is in economics.) Coding “boot camps” claiming to turn beginners into high-paid programmers in less than a year began to appear.

In an interview in my twenties, the company’s CEO asked me how much salary I thought I deserved. I said a number that embarrassed even me. He drafted a contract on the spot, offering a salary ten percent higher than I requested. Skills as a “software engineer” were highly valued. In one company I worked for, a colleague got into trouble for directly asking a fellow engineer a question using HipChat (the predecessor to Slack). He was told, “Never use HipChat to contact engineers directly.” We were too important; you couldn’t do that!

This was an era of near-zero interest rates and astonishing growth in the tech industry. Some norms had taken shape, with companies like Google telling the industry that programmers could enjoy free espresso and hot meals, world-class healthcare and parental leave, on-site gyms and bike rooms, casual dress, and “20% time,” meaning they could spend one day a week doing anything they liked. People believed their skills were so important that a kind of superstition arose. For example, estimating how long a coding task might take was considered foolish because programmers could open a stone and dig out a pile of bugs at any time. Deadlines were a curse, and if the pressure of delivery was too great, programmers could simply say the word “burnout” to gain extra months of time.

I felt from the beginning that something was not quite right. Was what we were doing really that precious? How long could this boom last? When I was a teenager, I did some web design. At that time, this work was popular and respected. You could complete a project over a weekend and earn thousands of dollars. But then tools like Squarespace came along, allowing pizza shop owners and freelance artists to create their own websites with just a few clicks. For professional programmers, a portion of high-paying, relatively effortless work disappeared.

The programmer community’s response to these changes was—you must constantly upgrade your skills and learn harder, more obscure things. Software engineers, as a species, like automation. Inevitably, the best among them build tools that render other types of work obsolete. This instinct explains why we are so well taken care of: code has tremendous leverage. A piece of software can affect the work of millions and even replace programmers themselves. We should view these advancements as a rising tide, gradually flooding our exposed feet, but as long as we continue to learn, we won’t be submerged by it. This is sound advice unless faced with a tsunami.

When we were allowed to use AI chatbots at work to help with programming, I deliberately avoided using them. I thought my colleagues would do the same. But soon, I saw the colors of AI chat sessions on their screens—the zebra stripes of that Q&A style. A common saying is that these tools make you more efficient, and in some cases, they can help you solve problems at ten times the speed.

I wasn’t sure if I wanted that. I enjoyed the programming process itself and liked the feeling of “being a useful person.” The tools I was proficient in, like the text editor I used to format and browse code, could satisfy both needs. They reinforced my practice of the craft—though they allowed me to complete work faster, I still felt I was contributing. But AI, as people described it, seemed different. It provided so much help that I worried it would rob me of the satisfaction of both enjoying solving problems and being satisfied with being a problem solver. I could infinitely increase productivity, but what I could show for it might only be the results.

The actual work products of most programmers are rarely exciting. In fact, they often tend to be mundane. A few months ago, I came home from work and told my wife I had a very enjoyable day solving a particularly interesting problem. I was developing a program to generate tables, and someone wanted to add a title that spanned multiple columns—and our custom layout engine did not support this feature. This work was urgent: these tables were used in important documents. So I locked myself in my room for half the afternoon. There were many sub-problems to solve: how should the layout engine users express that they wanted a title spanning columns? What should their code look like? And there were some trivial details that, if ignored, would lead to bugs. For example, what if one of the columns of the spanning title was deleted because it had no data? I knew it was a good day because I had to take out pen and paper—I was sketching possible scenarios and double-checking my logic.

However, what would it look like if viewed from a bird’s eye perspective? A table got a new title; it’s hard to imagine anything more mundane than that. For me, the fun was entirely in the process, not the result. If that process only required a three-minute ChatGPT conversation, what would that process become? As programmers, our work, besides literal coding, also involves many other things, such as mentoring newcomers and designing systems, but coding has always been at its core.

Throughout my career, I have been hired for my ability to solve programming puzzles. However, suddenly, that ability became less important.

I learned a lot from Ben, who kept telling me about the amazing results he achieved with GPT-4. It turns out that it is not only good at handling trivial tasks but also possesses the qualities of a senior engineer: it can propose solutions to problems from its rich knowledge base. In one project, Ben connected a small speaker and a red LED bulb to a portrait of King Charles. His idea was that when users typed text on the website, the speaker would play sounds, and the light would blink messages in Morse code. However, writing a program to retrieve messages for the device was troubling Ben, as it seemed to require specialized knowledge, involving not only the microcontroller he was using but also the backend server technology Firebase for storing messages. Ben asked me for help, and I mumbled a few words. In fact, I wasn’t sure if what he wanted was possible. Then he asked GPT-4, which told Ben that Firebase has a feature that could make this project much simpler. Just like that, here was some code that was compatible with the microcontroller.

Although I was afraid to use GPT-4 and felt a bit uncomfortable about having to pay OpenAI twenty dollars a month to use it, I started to explore its capabilities through Ben. We studied our crossword puzzle project together. I would say, “Why don’t you try this prompt?” He would hand me the keyboard. I would say, “No, you operate it.” Together, we gradually explored the capabilities of this AI. Ben had more experience in this area and seemed to utilize it more efficiently. As he later said, his own neural network had begun to align with GPT-4’s neural network. I would say he had gained mechanical empathy.

Once, he did something that particularly surprised me; he had the AI develop a Snake game, like the one on old Nokia phones. After a brief exchange with GPT-4, he had it modify the game to show how far you deviated from the most efficient route when you lost. The robot took about ten seconds to complete this task. Frankly, I wasn’t sure if I could accomplish this task.

The chess realm has been dominated by artificial intelligence for decades; a player’s only hope is to partner with a robot. This half-human, half-AI team (known as a centaur) may still be able to beat the best human and AI engines working solo. Programming has not yet developed to that extent, but centaurs have emerged. Currently, it seems that the solo GPT-4 is a worse programmer than me, and Ben is worse, but together, Ben and GPT-4 are quite dangerous.

Before long, I succumbed. I developed a small search tool that hoped to highlight the parts of user queries that matched the results. I split user queries into words, which complicated things. My patience was tested, so I started considering using GPT-4. Perhaps I could spend some time writing “prompts” or chatting with the AI instead of spending an entire afternoon programming.

In 1978, computer scientist Edsger W. Dijkstra wrote an article titled “On the Foolishness of ‘Natural Language Programming'” in which he pointed out that if you are not instructing the computer using formal programming languages like C++ or Python, but rather in your native language, you are rejecting the effectiveness of computers. He wrote that formal programming languages are “a very effective tool for excluding all sorts of meaningless nonsense, which is almost unavoidable when using our mother tongue.” Dijkstra’s viewpoint became a consensus in the programming community. In 2014, when this article was circulated again on Reddit, a commenter wrote: “I’m not sure which is scarier: the idea is so obvious, or many people still don’t know it.”

Edsger W. Dijkstra (1930-2002)

When I started using GPT-4, I could understand what Dijkstra was saying. You can’t just simply tell AI, “Help me solve this problem.” Perhaps that day will come, but now it feels more like an instrument you have to learn to play. You have to specify carefully what you want, just like communicating with a beginner. In the problem of highlighting search results, I found myself asking GPT-4 too many things at once, resulting in failure, and then starting over. Each time, my prompts became less ambitious. In the end, I didn’t directly talk to it about search or highlighting issues; I broke the problem down into specific, abstract, and clear sub-problems, which together could yield what I wanted.

After discovering the capabilities of AI, my work life began to change. GPT-4 became like a hammer, and everything in my eyes became a nail. I finally understood why the office computer screens were always filled with chat boxes and how Ben became so efficient. So I opened my mind and started using it more frequently.

I returned to the crossword puzzle project. Our puzzle generator printed output in an ugly text format, like “s”, “c”, “a”, “r”, “*”, “k”, “u”, “n”, “i”, “s”, “*”, “a”, “r”, “e”, “a”

like lines of letters. I wanted to convert such output into a beautiful webpage that would allow users to explore words in the grid and clearly display scoring information. But I knew this task was tricky: each letter had to be tagged with the word it belonged to, whether horizontal or vertical. This was a very detailed problem that could likely take me an entire evening.

My child is about to be born, and I have little free time left, so I started chatting with GPT-4. We exchanged messages back and forth, sometimes needing to look at some code to understand what it was doing, but I hardly did the kind of programming thinking I once thought of. I didn’t think about numbers, patterns, or loops, nor did I use my brain to simulate the computer’s activities. As another programmer, Geoffrey Litt, wrote after experiencing a similar situation, “I never engaged my programmer brain in it.” So what did I do?

Perhaps feeling that the game of Go has been permanently devalued, Lee Sedol chose to withdraw from the game. I initially learned programming because I felt that computers were like a kind of magic. Computers gave you power, but you needed to study their secrets—learning a spell that required a special way of thinking. I felt chosen. I worked hard, thought seriously, and accumulated obscure knowledge. Then, one day, it became possible to achieve many of the same purposes without thinking or knowledge. From one perspective, this could make much of a person’s work look like a waste of time.

Whenever I think of Lee Sedol, I think of chess. About thirty years ago, when machines conquered that game, people worried there would be no reason to play it anymore. However, chess has never been more popular than it is now—AI has made the game more vibrant. A friend of mine recently started learning chess. He can use an AI coach anytime, which can provide him with exactly the right level of games and tell him where he went wrong after he loses. Meanwhile, chess masters are studying the moves of computers as if reading oracles. Learning chess has never been so easy, and studying its deepest secrets has never been so exciting.

Computer science has not been conquered. GPT-4 is impressive, but ordinary people cannot master it like programmers. I still feel my profession is safe. In fact, I feel safer than before. As software development becomes easier, it will become more widespread, and programmers will increasingly turn to design, configuration, and maintenance. Although I have always felt that the tedious parts of programming are the most engaging and important, they are not what I am particularly good at. I have not passed many coding interviews at large tech companies. What I am relatively good at is knowing what is worth doing, what users like, and how to communicate on both technical and human levels. A friend of mine referred to this moment of AI as the “moment of revenge for mediocre programmers.” As the importance of coding itself begins to diminish, perhaps soft skills will shine.

This leaves me uncertain about what to teach my child after he is born.

I even think that when my child grows up, the way we view “programmers” will resemble how we now look back at the history of “computers”. Typing C++ or Python code may eventually seem as absurd as issuing binary commands on a punch card. Dijkstra might be shocked that making a computer do what you want could be as simple as making a polite request.

So perhaps what to teach is not skills, but spirit. Sometimes I think about what I might have done if I had been born in another era. In the agricultural age, coders might study water wheels and crop varieties; in the Newtonian era, they might have been fascinated by glass, dyes, and time measurement. Recently, I watched oral histories about the development of neural networks, and many of the interviewees—born around the 1930s—played with radios as children, which shocked me. Perhaps the next generation will explore those artificial intelligence systems that were once viewed as black boxes by their parents late at night. I should not worry about the end of the programming era. The hacker spirit lives on!

This article is reproduced from InfoQ, https://www.infoq.cn/article/0PY4NyD9cPDe4pEQlRVa;

The original text is translated from A Coder Considers the Waning Days of the Craft, The New Yorker, https://www.newyorker.com/magazine/2023/11/20/a-coder-considers-the-waning-days-of-the-craft

Author: James Somers

Translated by: Xue Mingdeng