Understanding the code is not enough

A software developer with more than a decade of professional experience argues that reading and understanding AI-generated code is not sufficient, because developers lack the domain and ecosystem experience needed to judge whether generated code is a good design. The developer, who has shipped code in about 5 major programming languages but has never worked with Ruby or Ruby on Rails, contends that a programmer can read and understand generated Ruby code while still being unable to explain why it is better than an alternative, making them a bad critic and reviewer of AI output. The argument extends beyond programming languages to business domains, where unfamiliarity with the problem space, users, and the system's historical evolution undermines a developer's ability to judge their own additions.

Understanding the code is not enough There’s an ongoing debate among people who pay attention to the evolving nature of software development whether reading and understanding the code produced by an AI agent is crucial or a thing of the past. Some people will argue that there is some code that has to be read and understood in detail, such as fundamental security aspects of your system or things like payment processing, but that most other things can instead be quality-controlled simply through automated tests and AI review. This is a not a blog post arguing about those people and arguments. Whether or not that’s the future for our industry I cannot say. Instead, I will talk about the other, more conservative, side who argues that “agentic programming is great but you should still read and understand the code”. Because I feel that the debate is hung up on something comparatively irrelevant. Understanding generated code I have worked professionally with software a little more than a decade. Through those years, I have shipped significant amounts of code in about 5 major programming languages. None of those are Ruby, and I have never worked with Ruby on Rails, for instance. But if I were to be dropped into a Ruby codebase today, armed with Claude Code or Codex, I probably would be able to get going and write some working web app code. Not only that - I feel pretty confident that whatever diffs I produced would be something that I could in fact read and understand. Ruby is an imperative programming languages like many others I have worked with - it has if-statements, loops, lambdas and classes. And Rails is somewhat similar to other web application frameworks, meaning I likely would be able to figure out what any generated controller or ActiveRecord code does. But, crucially, since I have never worked with Ruby or Rails - I would not be able to motivate why this particular code is a better design than any alternative. Why? Because I do not have any experience to draw from that would lead me to compare this to a hypothetically different solution. If something in Ruby or its ecosystem contains an alternative way of solving the same problem that’s simpler or more performant, then I will have no natural way of knowing. This makes me a very bad critic and reviewer of the code generated by the AI. Similarly, I am very comfortable with writing Kotlin code - but I have never worked professionally with Android. If I force my coding harness to solve a problem for me, I am sure I will be able to look at the diff and tell myself that “this makes sense”. But do I know that? Did the AI do something incredibly silly to placate my rather poorly designed requests? Or imagine I were an expert “web frontend programmer”, who just decided to dive into server side programming for the first time. My strong skills in Typescript will surely lead me to understand something like Java or Go. But do I have what it takes to actually tell a good solution from a bad one? Did I just generate something that makes perfect sense, or did I accidentally instruct the agent to move heaven and earth for me in the system, because I actually don’t fully know what I want? This extends beyond programming languages and ecosystems too. Today it is simpler than ever to dive head first into a business domain either at a new job or at a different department of your current one and start producing code and resolving tickets. But if you are not truly familiar with the problem space, the users of your product and the historical evolution of the system - then are you actually equipped to judge your additions? Understanding what you want To me, it is important to know what you would like the solution to be shaped like when you generate it. To have a sense of the architecture you are building towards. This might not mean that you have to review and understand every single line of every function - but it means that you have an idea and strong opinion on the overall design. You need to know how to take the original problem description and turn it into actually well informed instructions for the AI. That is rarely as simple as taking the description in the ticket and hoping that the model is powerful enough to figure it out. And to my knowledge, this still can only be earned through experience. By letting your brain exercise, thinking hard on problems, failing and learning from your mistakes, pushing through the friction and ultimately building familiarity with your problem space. This relates to what programming influencer Matt Pocock talks about when he reflects on Tactical vs. Strategic programming https://x.com/mattpocockuk/status/2057110441864696164 . Like me, he is worried what will happen if people are not forced to work through the nitty-gritty as a way to build up their intuition for higher level thinking. Reading the code you generated in a programming language, ecosystem or domain you are unfamiliar with and thinking “yeah I understand this code” is not only not enough - it’s not even the important bit.