Will source code become the new assembly?

I read less code than I used to. With AI writing more of the implementation, I expect that to continue.

Saying that can sound careless. Reading code is part of how we learn to program, understand a system, and check someone else’s work. When you have spent years doing it, the idea of shipping something you haven’t read feels wrong. I understand the reaction.

But we already do it every time we compile a program.

If you write a routine in assembly, the instructions are your working material. You choose them, read them, and work through what they do. Move to a higher-level language, and much of that work becomes the compiler’s problem. You read the source you wrote. You generally leave the generated assembly alone.

The processor still executes those instructions. They still determine whether the program works. We just became comfortable letting a tool produce them without checking each one ourselves.

I think AI coding agents will make us comfortable doing something similar with source code.

The first reaction is usually that AI makes mistakes. It does. Sometimes stupid ones. An agent can misunderstand a request, miss a dependency, or confidently tell you it finished something that doesn’t work.

Calling it a compiler doesn’t make those problems disappear. A compiler works from a language with defined rules. An agent has to interpret what you meant, often from a request that leaves half the decisions unstated. The comparison has limits.

What interests me is the change in our relationship with the output.

For most developers, source code has been the place where we express our decisions. We decide how something should work by writing the implementation. Then another developer reads it and tries to work out whether those decisions were correct.

With an agent, more of those decisions can happen before the code exists. We describe the behavior we want, explain the constraints, and establish how we’ll check the result. The agent works out the implementation.

That is the direction I see software development taking. Source code becomes something we generate and inspect when necessary, while more of our attention goes into defining what the software should do.

Consider a fairly ordinary request. A user should be able to download their invoices.

You can spend your review reading the component, the request handler, and the database query. You can also run the application and check whether the download works, whether it contains the right invoices, and whether another account can access them.

You may need both. But reading the implementation is one way to gather evidence about the result. It shouldn’t automatically consume most of the human effort.

As agents get better at implementing that feature and checking their own work, I expect to spend less time following every intermediate decision they made. I still care about those decisions when they cause a problem. I have less reason to read them all when the behavior is clear and the checks give me enough confidence.

This is where the compiler comparison makes sense to me.

We didn’t stop caring about machine instructions when we adopted higher-level languages. We got a more useful place to work. We could express more without managing every instruction ourselves.

An agent offers another move in that direction. I can describe a change across several parts of an application and let it handle the implementation. If I then have to reconstruct every detail before accepting the result, a large part of that benefit disappears. My reading speed becomes the limit.

For now, some changes still require that much attention. The tools haven’t earned the same trust everywhere. A routine interface change and a migration that deletes customer data deserve different levels of scrutiny.

I expect that boundary to move as the tools improve. Gradually, and with plenty of mistakes along the way.

There is also something uncomfortable about knowing less of your own implementation. Writing code yourself gives you familiarity almost for free. You remember why a function exists because you struggled with it yesterday. When an agent does the work, you have to decide which details are worth learning.

I don’t think the answer is to insist on learning all of them.

I want to understand the architecture, the important constraints, and what happens when something fails. I want to be able to investigate the implementation when I need to. Keeping every generated function in my head seems like a poor use of the time the agent just saved me.

That still requires engineering knowledge. You need enough understanding to set useful constraints and recognize weak evidence. A convincing demo can hide a broken permission check. A passing test can check the wrong behavior. Experience helps you notice what nobody thought to ask.

But experience can also make an old habit feel like a permanent requirement. Reading source code has been central to our work for so long that it’s easy to assume it must remain central.

Assembly used to be someone’s source code, too.

I think we’ll keep reading code for a long time. We’ll read it to debug, to investigate, to learn, and to examine decisions with expensive consequences. As agents become more dependable, though, reading every line will make less sense as the default condition for shipping.

I want to reach the point where I can spend most of my attention on the software people actually use, and open the implementation because I have a reason to understand it. We already work that way with compiler output. Source code may be next.