The weekly letter from Systems Thinking Lab: systems thinking insights for junior engineers, framed through the seven building blocks.
Adrian Quiroga opens his essay with a story. His agent had been iterating on one file through several features, and he had never seen it. Then CI flagged the file's cyclomatic complexity. That alarm, not any plan of his own, is what made him dive into code he was supposed to own.
The essay is "Here Be Monsters", and its thesis is one sentence: "Owning a software system will depend a lot less on having written it (or similar systems) by hand; instead, what will become most important is knowing just enough to know when something is wrong, and being willing and able to dive as deep as needed, when needed." He builds it on three pillars: fundamentals, breadth, and just-in-time depth, which is the willingness to dive when it matters and the humility to know when a dive is beyond you.
I think of that just-enough knowledge as a map of the system: what the parts are and how a request moves through them.
Then comes the uncomfortable part. As he puts it, the industry will not pay juniors to spend years learning it by hand, and "understand every line your agent wrote" is wishful thinking at scale. So if you are early in your career, the old route to that map is not on offer. What is the new route?
I left a comment on the Hacker News thread, and this is what I wrote:
I think the most important way someone could be able cultivate breadth of understanding as well depth when needed is to be able to truly understand all of the things that are touched when someone uses the system, step by step. This doesn’t require deep knowledge in any one aspect of the system, but it does require someone to be curious, be open, and be willing to put themselves in the users shoes and use the feature, and then switch back into the developers mind and map user action to where in the codebase is being activated and why. And be willing to go back and forth. The interesting thing is that agents can help us, but the exercise loses its value if the agent just maps it out for us. We need to be in the process of discovery in order to build our own mental model.
That asks for curiosity, not depth in any one part. And the line I would underline is about the agent: if it draws the map for you, you get the map but not the mental model that building it would have given you.
So here is the practice version, at the size of a single week. Pick one feature of the system you work on. Use it as a user would, start to finish. Then trace it: which request, which service, which data got read or written, and why it was built that way. Then bring in the agent, with the questions you already know how to ask, and let it answer those instead of drawing the map for you.
In his story, it took an alarm to make him dive. You can pick the feature yourself.
Kay
P.S. The high-level map Quiroga says an owner needs is exactly what Course I gives you: seven building blocks and three external entities, the small set of parts almost every system is made from. Learn them and you can explain how your system works, whoever typed the code. It is all at https://systemthinkinglab.ai/courses-i-iv.html