A heretical view about generated code

From Assembly to English: How Our Source Code Is Changing

Back in the day, if you wanted to make a computer do something, you had to speak its language. And its language was assembly: a terse, unforgiving dialect that mapped directly to the instructions understood by the silicon beneath your fingertips. You’d labor over registers and jumps, nudging electrons into place one bit at a time. It was a world where every line of code was a direct conversation with the machine, a conversation that required patience, precision, and a willingness to get your hands dirty.

But as computers grew up, so did we. We built compilers, marvelous machines in their own right, that could take something more human, like C or Pascal, and translate it into the assembly that the processor craved. Suddenly, you didn’t have to think in opcodes and memory addresses. You could write in loops and functions, trusting that the compiler would handle the messy translation. The source code you cared about, the C code, became the artifact you maintained, improved, and shared. The assembly it produced was a byproduct, a means to an end, rarely seen unless something went wrong or you were feeling particularly nostalgic.

Fast forward to today, and the landscape has shifted again dramatically. Now, we’re not just writing in higher-level languages. Increasingly, we’re writing in English. Or at least, we’re writing prompts in English, addressed not to the machine, but to an AI agent. We say, “Write me a Python function that sorts a list of dictionaries by a given key,” and presto! out comes a block of Python code, ready to be run, tested, and deployed.

At first glance, this feels like a natural evolution. After all, isn’t the history of programming a steady march toward greater abstraction and expressiveness? But there’s a subtle, and perhaps profound, difference in how we treat the artifacts of this new workflow.

The Shift in What We Call "Source"

Back in the compiler era, the C code was the source. The assembly was ephemeral, regenerated as needed, and rarely touched by human hands. If you wanted to change how the program worked, you would edit the C code, not the assembly. The C was the living document; the assembly was the shadow it cast.

But with AI-generated code, we’re starting to see a curious inversion. We write a prompt in English, the AI produces Python, and then we treat the Python as the source. We check it into version control. We maintain it. We debug and extend it by hand. The English prompt that produced it? Often lost, discarded, or at best, relegated to a comment or a commit message.

This is a subtle but important distinction. In the compiler era, the source was the thing you could maintain. With AI, the source is the thing you choose to maintain, even if it  wasn’t written by you, and even if you could, in principle, regenerate it at any time.

Why Does This Matter?

Let’s pause and ask: why did we treat C as the source and assembly as the byproduct? The answer is partly practical, C is more readable, more maintainable, and more portable. But it’s also about intent. The C code expresses what the program should do, in a way that’s accessible to humans. The assembly is just the implementation detail.

With AI-generated code, we’re in a new territory. The prompt expresses intent, but it’s often ambiguous, context-dependent, and not always reproducible. The Python code is concrete, but it may not reflect the nuances of the original request. And crucially, once we start editing the AI-generated Python by hand, we sever the link between prompt and code. The Python becomes the new source of truth, not because it’s the most expressive or maintainable artifact, but because it’s the one we have.

Another consideration is the sheer volume difference between the prompt and the generated code. The following prompt creates 570 lines of code across 10 files.  

“Create a production-ready cloud application that uses Python (Flask) for the backend API, stores user data in a DynamoDB table, and deploys everything on AWS using Terraform. The infrastructure should include an ECS Fargate cluster to run the containerized app, an ECR repository for Docker images, an Application Load Balancer for public access, and secure IAM roles. Provide all necessary Terraform code to provision the resources, and Python code for a sample API that supports user registration and login. Include comments and instructions for building and deploying the app.”

While it's amazing that a three-sentence prompt can create that much code, that means that maintainers must read and understand all that code and verify that it was all generated correctly and matches the intent of the prompt.

Why the Blueprint Still Matters

Let’s take a step onto a construction site and consider the humble blueprint. These sheets of paper, covered in precise lines and symbols, are more than mere drawings—they’re the original language of the building, the foundational instruction that captures the architect’s intent. If you want to understand why a hallway curves or where a window should be, you turn to the blueprints.

Of course, construction rarely unfolds exactly as planned. Unexpected site conditions, evolving client needs, or simple human error often demand changes. This is where the change order comes in—a formal document that records each adjustment to the original plan. Perhaps a wall needs to shift, or a new window is added for more light. Each change order is a footnote in the building’s story, capturing the negotiation between vision and reality.

Eventually, the structure itself takes shape: steel, concrete, glass, and wood assembled according to the instructions and all their amendments. The finished building is the tangible result. But if all that remains is the physical structure—without the blueprints or the record of change orders—the reasoning behind each decision is lost. Why is a column exposed here? Was that room always intended to be this size, or did something change along the way?

This loss is more than academic. Without the original documents, future renovations become guesswork, and compliance or safety questions are harder to answer. The building stands, but its intent—the logic behind its form—has faded.

Just as we risk losing the thread of intent when we discard the original prompt in AI-generated code, so too do we risk erasing the building’s story when we neglect to preserve its blueprints and change orders. These artifacts are not just historical records; they are the ongoing dialog between design and execution, and without them, we are left with a structure whose meaning is half-hidden.  For more on this topic consider https://en.wikipedia.org/wiki/How_Buildings_Learn. 

The Risks and Rewards

There are obvious benefits to this approach of using Generative AI to write code based on prompts. AI can produce boilerplate, explore new APIs, and even suggest optimizations that a human might miss. It accelerates development and lowers the barrier to entry. But there are risks, too.

• Loss of Intent: Without the original prompt, it can be hard to know why the code was written the way it was. Was it meant to be optimized for speed, readability, or something else?
• Reproducibility: If you want to regenerate the code perhaps with a better prompt or a newer AI model you may not be able to, especially if the original prompt is lost. And even with the original prompt, Large Language Models are not deterministic and may produce slightly different answers every time.
• Maintainability: AI-generated code can be inconsistent in style, structure, and quality. Once humans start editing it, the gap between intent and implementation can widen.

What Could We Do Differently?

One possibility is to treat the prompt as a first-class artifact, something to be maintained, versioned, and improved alongside the code it generates. Imagine a world where every Python file has an associated prompt, and changes to the code are reflected in updates to the prompt (and vice versa). This would bring us closer to the compiler-era model, where the source of truth is the most expressive, maintainable artifact.

Alternatively, we might develop new tools and conventions for documenting the relationship between prompts and code, making it easier to regenerate, audit, and understand the origins of our software.  An example of something along these lines is the AWS Step Function Editor.  As shown below, you can edit either the code or the diagram, and the change is reflected in the other view.

Conclusion: A New Kind of Dialog

The evolution from assembly to C to AI-generated Python is more than just a story of abstraction. It’s a story of how we communicate intent, how we maintain our creations, and how we decide what counts as “source.” As we embrace AI as a partner in software development, we have an opportunity and a responsibility to rethink our relationship with the artifacts we produce.

Are we content to treat AI-generated code as the new source, or can we imagine a future where the dialogue between human and machine, the prompt and the code is preserved, maintained, and celebrated? The answer may shape not just how we write software, but how we understand what it means to create