In developing software, you have an idea of how you want it to behave. Software is behaviour. That’s in a sense what you create in a software project.

Behaviour quickly becomes insanely complex. Even as a single developer, having written every line of code, it’s a challenge to maintain an accurate mental picture of the behaviour of the system.

With more people involved in making the software, this is increasingly the case – and I don’t think it’s linear.

As we use AI more and more to make software, maintaining a mental picture of the behaviour of the software becomes even more of a challenge.

As the provider of some software you are responsible for that behaviour. It’s what you offer customers for money. Understanding what it does has always been critical, and I don’t see that changing.

Now what can one do to understand a piece of software. You can participate in writing the code for it. That gives you an understanding. You can read the code that others have written. And you can use the software itself.

As for documentation in the form of text and diagrams, that’s helpful to some extent, but it is mostly for getting an overview. When describing the details, I know of no better representation than the code.

What about asking an LLM how the code works? That’s a good idea but I don’t think it’s mature enough yet. But it might become like asking a longtime developer to explain it.

As code is increasingly written by machines, the practice of code review needs to evolve. I can’t see that we’ll come to a point soon where the makers of software wouldn’t want to peek under the hood. And I think we’ll want to put significant effort on review in the coming years.