Increasingly, the software engineer’s job is to observe and manage what I propose we call the changescape: the way a system is being evolved and altered.
Modules, API surfaces, class hierarchies are changing rapidly as AI agents independently implement increasingly ambitious tasks. Responsibilities shift, and whole new subsystems sprout overnight, sometimes heavily overlapping with existing ones. Our job is to think about and approve or push back on the shape of these changes, ensuring the overall system stays clean, efficient, evolvable and understandable – both for humans and agents. We rarely fashion the individual details of changes ourselves; we immerse ourselves in understanding of the overall system, its capabilities, its past, present and future, and how the changes being introduced alter it.
The diff-based change review experience that’s become standard over the past 20 years is simply the wrong level to engage at if we want to effectively absorb the big picture of proposed changes and their implications.
I like this term, “changescape”, because it communicates the dynamic nature of the thing. “Architecture” suggests a grand design, a blueprint filed with the city – everything specified before construction begins. Software Architecture is obviously a real concern, and thinking about the big picture is important, particularly when major new projects are kicked off. But the day to day work is managing the chaotic evolution of the system as problems emerge and need to be addressed, features added, and subsystems upgraded. “Changescape” gives a name to what I see the best engineers focus on in the AI-assisted development era.
§1
The term “Changescape” came to me independently, but a bit of research showed that it’s been coined before, in a different context. Ross Gibson, an Australian writer, filmmaker, and academic penned an essay titled “Changescapes” in the IDEA Journal, a publication by The Interior Design / Interior Architecture Educators Association of Australia & New Zealand, back in 2005.
Gibson’s changescapes are not just the changes themselves, but artistic expressions intended to help the person interacting with them experience and understand change and dynamic complexity at the aesthetic level. The two meanings of “changescape” coexist: it can mean both the totality of ongoing mutations and a way to experience and understand them, just as “landscape” means both the hills and a painting of the hills. Software needs both senses of the word. We’re surrounded by the first, and we have almost none of the second.
About half of Gibson’s essay tells the story of his visit to an old lumber mill turned woodland hermit’s oddly artistic compound. It’s a great read, if you are looking for something a bit outside the software echo chamber. But what struck me was the language he used to explain the concept of changescapes and to talk about complex systems in general. Take a look at these quotes:
“[A changescape] helps you think and feel so that you are engaged with a changeful world, so that you feel informed about its maintenance and motivated by its momentum rather than distressed by its entropy.”
“You can use a good changescape to feel the options as well as the obligations it presents, to speculate about possibility in a world of uncertainty. A good changescape is a system you can use to contemplate dynamics, to be with complexity more effectively.”
I think everyone who’s been involved in steering a large software project with many contributors will relate to these descriptions.
We need better changescapes in software if we want to “contemplate dynamics, to be with complexity more effectively”.
§2
The current generation of code review tools was developed for the goal of reviewing every line in a change set for correctness and style, and to help engineers train each other on how to get minute implementation details right. Both of those jobs are now better left to automated reviewers. Copilot, Codex, CodeRabbit, and their ilk are becoming increasingly effective at reviewing the minutiae, and between them and specialized agents like security reviewers from Tenable and Wiz, one can be fairly confident that a change actually does what it says in the description, and probably does it correctly. They still miss things sometimes, of course, though arguably less frequently than humans. And they are getting better fast.
What they consistently fall short on, and where we need better tools for humans, is figuring out if the change is the right change to be introduced in the first place; and if it is, whether it’s being introduced in the right place and in the right shape. When should responsibilities be combined or split? When is adding more options to the API an improvement, and when is it introducing a harmful degree of flexibility? Is now the right time to push a breaking change, or should that happen at a later date? Are the core primitives right here, and when should we add new ones?
Big picture questions. To answer them… Well. To quote Gibson:
“One needs to be able to zoom back and forth instantaneously within a depth of field that connects the past with the present, and with the imminent, so that one perceives patterned continuities operating in concert with change.”
§3
Looking at a thousand individual line changes, organized by the files and directories these changes happen in, is not particularly helpful in this endeavor. Too low level. Change stacks help a bit with the “organized by files and directories” bit by splitting out sets of changes into separable concerns, but they aren’t quite right either, still staying at the level of changed lines of code. Reading a verbose PR description, complete with diagrams and screenshots, is ok, but it’s not great – too static, too high level, too wall-of-text.
A new generation of tools is needed. Ones that allow the interlocutor to understand the change at multiple levels, such as changes to code structure, module behavior, contracts, control flow. A fluid interface that zooms between all of these, and can drop all the way down to code diffs if need be. Ones that track questions, answers and annotations across all the layers, facilitating the conversation between the reviewer and author, human or agent. Ones that encourage contemplation of the changing dynamics of the system.
We need software changescapes.