As I've moved from IC to having a team over the years, more code was being written than I could possibly understand at the depth I would have if I'd written it myself. Agentic coding is changing the composition of the team, augmenting humans with superpowers that increase feature volume by an order of magnitude. Same problem, different scale.
This observation has fueled the online chatter to say "coding is solved". From my personal work, I believe that if coding isn't solved now, it will be soon, at least for typical business software.
But writing code isn't software development. It is one small part of the entire practice. There have been many studies over the decades showing that writing the code is in fact the cheapest part of the process. Robert Glass summarized the findings in 2002, showing maintenance consumes 60% of the total cost for the average project.
The hard parts of software are outside of the code: understanding the job it does, turning that into abstractions, and adjusting it to match the constraints of users and operations. Writing the code is the part where we materialize the abstractions. Once you've figured out how to build it, writing the code is the easy part.
As the agents create code, we still have to understand the abstractions, how they map to intent, how they can be extended, and how to decompose them when they invariably break. As my human teams scaled, I retained this understanding by thinking not at the line-by-line code level, but at the system level.
The essential skill with coding agents is still the same we cultivated as our teams grew: boxes and lines.
For me, the map of the system is expressed as the component boxes and the lines that show how they interact. The boxes are opaque, but I can see what they do by looking at how they interact. The incoming and outgoing messages define a contract, and in my experience this is where the most difficult defects appear.
Someone asked how I debug complex systems if I don't understand every line, and this is the way. Is a component sending a malformed message? I can trace that into the code. The system view is the map, and the boundaries tell us where to go hunting inside the box.
It's hard to get boxes and lines just looking at code. I've always encouraged my engineers to give me a sequence diagram as part of their deliverables. The boxes are right there at the top, and the lines go between them. Agents are great at this, and if you're struggling to view the system they're coding, I suggest you ask them for sequence diagrams as they work.
The agents are often silos, doing great work in parallel. Sometimes identical great work. I wrote about this in Reasonable But Wrong, where I shared an issue that only shows up in the system map, because it's a boundary problem. The agent proposed adding a line to the store, updating an entity already controlled by another service. A clear violation of ownership that only shows up on the map, not in the diff.
The old lessons of people management get us a long way, but they definitely have their limitations. The tools we use to get quality from people do not work on agents. In this world those rules are replaced by structure, with checks at the boundaries. "One writer per entity" is a mechanical rule a deterministic gate can check. Passing gates are the acceptance criteria that control the agentic loop.
Personally, I developed the system-level debugging skill the old fashioned way: by grinding through years of writing and debugging code through increasingly complex projects. You need exercise to build muscle. The hard question we face now: if agents do the slog, how do juniors cultivate the skill?
On a recent HN thread, a commenter pointed out that when we transitioned from assembly to high level languages, the juniors did just fine. Fair. But in my experience, the organizations that intentionally helped people carry their skills to the new tools did better in the end. They were certainly better places to work.
I'm trying to find ways to help my people make this transition. One interesting idea I heard: have the juniors walk through each step in the transcript from the agent. This reminds me of the narration technique: an expert speaks their thoughts out loud as they walk through a process, so the trainee sees not just the outcome but also the reasoning.
Coding is approaching "solved", but that's the smallest slice of the entire product of software delivery. As it shrinks, the time we spend on the essential tasks that surround it becomes an even larger portion. That's the job we keep as we bring in this new power. The map is the vehicle I use to bring up people coming after me, but I'd love to hear where others are finding success.