There is something slightly strange happening in software development. For decades, one of the main challenges was writing the code. You had an idea, figured out how to translate it into software, wrote the code, discovered that it didn’t work, stared at it for half an hour, changed three characters and suddenly it did work.

AI changes that process dramatically. Today you can describe what you want and watch an AI coding agent produce hundreds or even thousands of lines of code. And it is only getting better at it. That sounds wonderful, but it also creates a problem that I find increasingly interesting: what happens when AI can write code faster than we can understand it?

That is exactly the question Geoffrey Litt explores in his excellent article Understanding is the New Bottleneck. You can reda it here: https://www.geoffreylitt.com/2026/07/02/understanding-is-the-new-bottleneck. Geoffrey is a design engineer at Notion who writes and experiments extensively with new ways for humans to interact with software and AI. I have written about him before, especially when he was exploring the concept of malleable software: software that users can adapt, reshape and truly make their own instead of simply consuming it as a finished product. But also software you create when you need it and simply throw away when you don’t need it anymore.

In his new article, Geoffrey takes that thinking in an interesting direction. “It’s still important to understand the code that our agents write,” he argues. That sounds almost ridiculously obvious. Of course we should understand our software. But think about what happens when you actually start using AI coding tools seriously. You ask for a feature. The AI changes twelve files. It adds a library, modifies an API, creates some tests and changes part of the data model. Everything compiles. The tests pass. You run the application and it seems to work. Nice! On to the next prompt. And that is precisely where the danger begins.

The code works, so what?

Geoffrey Litt makes an important distinction between understanding code to verify it and understanding code so you can participate in developing it. Verification is basically asking whether the AI did its job correctly. Does the code compile? Do the tests pass? Does it match the specification? Is the architecture reasonable? AI is becoming increasingly capable of doing some of that verification itself.

But understanding has another purpose. If we really understand how a system works, We can think about what it should do next. We can see alternatives. We can recognise that a particular architectural choice will become a problem later. We can connect one part of the system with another. As Litt puts it, understanding allows us “to participate.”

I think that is an extremely useful way of looking at AI-assisted programming. If an AI agent has created half my application and all I can say about the result is, “Well, it seems to work,” I am no longer really developing that application. I am supervising its development.

Every time we accept code we do not understand, we also accumulate what Litt describes as cognitive debt. It resembles technical debt. You can ignore it for a while, particularly when everything is working. But sooner or later you need to change something and suddenly discover that you have lost your mental model of your own software.

So how do we prevent that? This is where Litt’s article becomes particularly useful, because he doesn’t just identify the problem. He experiments with practical ways of solving it.

Use a literate diff

One of the most obvious ways to review AI-generated code is to look at the diff. But imagine an AI agent has changed twenty files. Reading hundreds of changed lines from top to bottom is technically reviewing the work, but it isn’t necessarily a very good way of learning what happened.

Litt suggests turning the process around. Before looking at individual lines of code, ask the AI to explain the change. And not simply: What did you change? Ask it to teach you. What did the system look like before? What problem were we trying to solve? Which concepts do we need to understand? What architectural decision did you make? Which components interact with each other? What alternative approaches were possible? Why did you choose this one? Only then move towards the actual code.

Litt calls one version of this a literate diff. Instead of presenting changed files in whatever order Git happens to show them, the changes are presented as a story: first the background, then the idea, followed by the relevant pieces of code in an order that makes conceptual sense. That is an interesting idea. The AI wrote the code, so why not also make the AI write the manual that teaches us what it just built?

Ask for intuition

There is another subtle but important point in Litt’s approach: intuition before details. Suppose an AI has implemented a caching system. Before studying the implementation, we could ask: What exactly are we caching? Why will that make the application faster? When is the cache invalidated? What happens if it contains stale information? Where does the cache live? What happens after a restart?

Only once we understand those concepts does it make sense to study the classes, functions and data structures implementing them. The same applies to almost anything an AI creates. If it adds authentication, first understand the authentication flow. If it creates a database abstraction, first understand how data travels through the application. If it introduces asynchronous processing, first understand which things now happen in which order. If it creates an API, understand the contract before studying its implementation.

That sounds like basic software engineering. And I guess it is. The difference is that AI makes it extremely easy to skip these steps because the implementation can appear almost instantly.

Make the AI test you

This is perhaps my favourite suggestion from Litt. After the AI has explained the code, ask it questions about the system. Or even better: ask the AI to quiz you.

Litt actually does this. His code explainers contain five questions about the change, and he has a simple rule: he doesn’t send the code to other people until he can pass the quiz. That may sound a little like going back to school, but it solves an interesting problem. Reading something is not the same as understanding it. We can read a beautiful AI-generated explanation and think: yes, perfectly clear. Then somebody asks us five minutes later how the data actually gets from A to B and wemight very well discover that we don’t know.

So after an AI has generated something substantial, ask it: What are the five things I really need to understand about this implementation? Then close the explanation and try answering them yourself. Or ask the AI to give you scenarios. What happens if this API call fails? What happens when two users update this record simultaneously? Which component owns this data? What breaks if I remove this function? Where would I make a change if I wanted to add feature X?

If you cannot answer those questions, you probably don’t understand the software yet. says Litt. He describes these quizzes as a kind of speed regulator. AI can move much faster than human understanding, so occasionally we need to deliberately slow the loop down.

Tools for understanding AI code

Then comes an idea I hadn’t really considered before reading Litt. AI doesn’t only have to generate the application. It can also generate temporary software that helps you understand the application. Litt calls these micro-worlds. For example, while working on a Prolog interpreter, he had an agent create a debugger that allowed him to step through execution and see what was happening internally. In another project, an AI-generated interface let him migrate his website step by step while watching the old and new versions side by side.

That opens up all sorts of possibilities. Ask an AI to create a visualisation showing how data flows through the application. Ask it to build a tiny dashboard displaying internal state. Ask it for a stripped-down version of a complicated algorithm with sample data. Ask it to create a sequence diagram. Ask it to instrument the software so you can see which functions are being called. Or ask it to create a small playground where changing one variable immediately shows the consequences.

The important difference is that you do the exploring. As Litt notes, there is a big difference between asking an agent to debug something for you and using a tool created by the agent to investigate the problem yourself. In the second situation, AI hasn’t removed you from the process. It has given you better instruments.

Explain the code back to the AI

We could also add another simple technique: reverse the conversation. Don’t always ask the AI to explain things to you. Explain the software to the AI. Write down your understanding: As I understand it, request A enters here, is validated by B, stored through C and eventually triggers D. Component E is only used when… Then ask the AI: What have I misunderstood or missed?

This forces you to construct your own mental model instead of merely consuming the model’s explanation. You can do something similar by drawing the architecture yourself and asking the AI to check it against the codebase.

That distinction is important. The goal isn’t to have an AI that understands your software perfectly. The goal is for you to understand it.

Sometimes just write the code yourself

Which brings me to Jamie Tanna. Jamie is a software engineer and open-source maintainer who writes extensively about Go, open source, software engineering and his experiences with AI-assisted development. In his writing around GopherCon UK 2026, another question appears that fits remarkably well with Litt’s argument: how do you stay passionate about programming when increasingly powerful tools can do so much of the programming for you? You can read his report here: https://www.jvt.me/posts/2026/08/14/gophercon-uk-2026/.

That is a highly relevant question, because there is another risk here. You can understand perfectly well what an AI agent has built and still find the whole experience rather boring. For many developers, programming isn’t merely a mechanism for producing software. Solving the puzzle is part of the attraction. You try something. It fails. You discover why. You try something else. And somewhere during that process you learn something you didn’t know when you started.

If our interaction with software development becomes prompt, wait, accept, prompt, wait, accept, we may become extremely productive while slowly removing the thing that made programming interesting in the first place. That is why I think understanding and passion are closely connected.

Do not outsource all the interesting bits

There is no rule saying that because AI can do something, we have to let it. Let AI generate boilerplate, write repetitive tests, search through unfamiliar APIs and suggest solutions. But occasionally keep the interesting problem for yourself. Use AI as a teacher rather than a replacement. Ask it to give you hints instead of complete solutions. Ask it to explain an unfamiliar concept and then implement it yourself. Ask it to create an experimental environment where you can play with an algorithm. Or simply turn it off for an hour.

Efficiency isn’t always the objective. Sometimes learning is. Sometimes curiosity is. And sometimes spending an evening solving something that an AI could probably generate in thirty seconds is still worthwhile because we want to know how it works.

That is what I take away from these two authors. Litt’s argument isn’t really that we need to carefully inspect every line an AI generates. That would quickly become impossible. Instead, we need better ways of building and maintaining mental models of increasingly AI-generated systems. Explanations, literate diffs, quizzes, visualisations and micro-worlds can all help.

And Tanna’s thoughts about staying passionate add another line of thought. We shouldn’t only ask how AI can make us faster at programming. We should also ask how AI can make us better at understanding programming. That is a very different objective.

Perhaps the most interesting sentence in Litt’s article comes near the end: “The point was always to augment, not just automate.” I think that captures it perfectly. AI can write the code. It can test the code. It can explain the code. It can even write little tools that help us explore the code. But we still want to understand what is happening. Because the moment we stop understanding our, we also lose much of our ability to decide where it should go next.

I use AI a lot. I find the technology fascinating and useful. But every now and then I come across a story that makes me wonder whether we have completely lost sight of what we are doing. This is one of those stories.

404 Media reports that Amazon is buying large quantities of physical books, scanning them to create AI training data and destroying the books in the process. The journalists even placed a tracker inside a shipment of rare books and followed it to an Amazon facility in Las Vegas where, according to employees, books are cut apart so they can be scanned more efficiently. Amazon itself confirmed that it purchases books through commercial channels to help develop and improve its products and services.

If this report is accurate — and there are now quite a few similar stories appearing elsewhere — I find this astonishing.

The basic process is brutally simple. Cut off the spine, separate the pages, scan them at high speed and turn the text into training data. The physical book is effectively gone afterwards. And apparently this does not only involve cheap mass-market paperbacks. 404 Media says the shipment it followed contained books that were rare in the sense that relatively few copies were in circulation.

This is not an isolated story either. Court documents previously revealed that Anthropic bought and destructively scanned millions of books for AI training. The Washington Post reported on the project, while Ars Technica described how bindings were removed, pages scanned and the original books discarded. Booksellers in Europe and Australia have meanwhile reported unusual bulk purchases of obscure and sometimes rare titles, although in many of those cases they cannot prove who the ultimate buyer is or what happens to the books afterwards.

I understand why AI companies want books. Compared with much of the web, books contain carefully edited, structured, human-written information. Older books also have another attractive property: they predate the current explosion of AI-generated text. For companies desperately looking for clean training data, that makes them extremely valuable. 404 Media previously reported that printed books are actively being marketed to AI companies for exactly this reason.

But surely there has to be a better way. A book is not simply a convenient container for a sequence of tokens. Especially with older or uncommon books, the physical copy can itself be part of our cultural and intellectual history. Once a scarce edition has been cut apart and recycled, having its text somewhere inside a gigantic training dataset is not quite the same thing.

What makes this even stranger is the contradiction. We are destroying human-made objects containing carefully collected human knowledge so machines can learn from that human knowledge.

Maybe all these reports will eventually turn out to be less dramatic than they currently appear. I hope so. But if AI really needs books this badly, I would much rather see us invest in ways of digitising and preserving them at the same time. Teaching machines should not require destroying the things from which they learn.

Recently, I was standing beside a hockey field, watching one of my daughters play a match. Like so often happens at these events, conversations with other parents started. At some point, someone asked me: “What do you actually do for work?” I explained that I am a technology journalist. That naturally led to a conversation about technology, innovation and the way the world is changing.

After a while, he asked me a interesting question: “Do you have a kind of role model? Someone you consider to be a really great technology journalist?” I did not have to think for even a second. “I guess that would be Jerry Pournelle,” I said.

For many people today, that name probably does not immediately ring a bell. But for me, Jerry Pournelle represents something that has always been at the heart of technology journalism: curiosity.

Pournelle was not just a journalist. He was also a science fiction author, a computer enthusiast and someone who had a deep connection with the world of space exploration. For many years, he wrote the famous “Chaos Manor” column for Byte magazine, one of the most influential computer magazines of its time. His writing was different from many traditional technology articles. He did not simply describe products or repeat announcements from vendors. He experimented. He built things. He tested technology himself and shared his experiences, including the problems and frustrations he encountered along the way.

That was what made him special. He approached technology as something you had to understand by using it. He was not only interested in what a computer could do according to a specification sheet. He wanted to know what happened when a real person worked with it. Learning by building and experimenting.

I became a technology journalist in a time when technology magazines were still big and influential. I remember waiting for those international technology publications to arrive. Computerworld, PC World, NetworkWorld, Byte. When the latest issues came in, I immediately wanted to take them home. I loved those magazines. In the evenings I used to read them back to front.

At the publishing company where I worked, we had a library with many international business publications. Magazines like BusinessWeek and Fortune were primarily there for the management team. They were considered important reading for directors and executives. But I was fascinated by them too. Whenever I had the chance, I would “steal” those magazines from the library and read them at home. I wanted to understand what was happening beyond the world of IT. What were companies thinking about? Which technologies were changing industries? How were leaders looking at the future?

Looking back, I realize that those moments shaped the journalist I became. Technology journalism is not only about knowing the latest processor, ERP-solution, 4GL tool, cloud platform or software release. It is about understanding the bigger picture. It is about being curious about people, businesses, society and the impact of technology.

That is exactly what I admired about Jerry Pournelle. Even at an age when many people would have slowed down, he remained incredibly active and curious. He continued writing, experimenting and exploring new developments. Technology kept changing around him, but his curiosity never disappeared.

I am younger than Jerry Pournelle was when he was still actively writing, but I recognize that same curiosity. I still enjoy discovering new technologies, reading about unexpected developments and diving into subjects I know little about. Whether it is artificial intelligence, space exploration, digital autonomy or completely new ideas that appear out of nowhere, there is always something new to learn.

And that might very well be the most important lesson from people like Jerry Pournelle. Technology changes constantly. The tools we use today will eventually become outdated. The platforms we consider revolutionary will one day be replaced. But curiosity remains. Or maybe I should say: curiosity needs to remain.

Because that is what makes a great technology journalist like Jerry Pournelle. Not the ability to predict the future perfectly. Not knowing every technical detail. But having the desire to keep asking questions, keep experimenting and keep learning.

I see that Jerry’s website is still available at https://www.jerrypournelle.com/.