In Missing UI, I wrote about a problem I think will become increasingly important as AI agents get better.
We are getting much better at making agents do work.
But we are not getting equally better at helping humans understand the work they did. That imbalance is starting to show up most clearly in software engineering where what's important is not just what is done, but how.
A coding agent can now make changes across dozens of files, refactor an abstraction, add tests, update an API, and fix downstream callers with little guidance.
The work might be correct, in a sense that the thing built works as expected. But then someone has to review it to verify how the new thing works. And suddenly the bottleneck is no longer writing the code.
There is an interesting debate happening around AI-generated code. One camp argues that, as agents get better, humans no longer need to read code. The other camp argues that engineers still need to read and understand the code they are responsible for.
When such a divide happens, often the optimal point is somewhere in between.
My view is that people do not want to read code because our current way of reviewing code changes is painfully bad (and we blame GitHub for it).
Imagine opening a pull request with 2,000 lines of changes that you did not write. Sometimes you don't even know what the problem was before reading the PR description.
Your first job is to gain enough context to review the problem, approach, and its change properly.
You jump between files. You search for callers. You inspect tests. You go back to the PR description. Maybe you open the ticket. Maybe you ask the author a question.
Eventually, you reconstruct enough of the context but that reconstruction is expensive and it takes a lot of time and energy.
AI is making things worse. If agents allow engineers to produce 5x more code, but humans still have to understand that code at roughly the same speed as before, comprehension becomes the bottleneck.
There is one situation where this problem feels much smaller, which is when you were working with the agent yourself. Chat UI fits incredibly well when you were there.
But this breaks down the moment someone else joins. A reviewer was not there. Even you might not really be "there" anymore if you come back a few days later.
No one wants to read the entire agent conversation to (re)gain that context.
There are already interesting attempts to solve this.
Skills such as /show-me and /explain-diff generate higher-level explanations of code changes. Instead of starting from the raw diff, they try to explain what happened, what matters, and sometimes even test whether the reviewer understood it.
whiteboard is another approach to the problem, as the founder states
We were missing the feeling of a "whiteboard session" with another dev where you leave with a deep understanding of a system.
[…]
We struggled to maintain a comprehensible codebase while reaping all the velocity benefits of agentic coding. As more PRs were merged without our understanding, we felt a 'cognitive debt' begin to seep in, until it became difficult for us to even contribute to the system.
I think they are pointing in the right direction. But I do not think a document is the final interface.
The documents are still something you have to sit down and read. That sounds trivial, but I think it matters.
Cognitive debt is often discussed alongside exhaustion.
After a day full of Slack, meetings, coding, reviews, and context switching, the last thing you want is another dense document requiring focused reading.
The solution has to have two attributes.
- It has to feel a lot lighter. Just like the handoff meeting where the presenter controls the pace, you can sit back and be passive. For a few minutes, you are not the one actively doing the work of figuring out where to pay the most attention to.
- It should also be an interactive medium. Something you can dig deep where necessary. As you do so, the interface changes with it to explain the behavior in the best form. It should feel like a casual meeting with materials prepared just for you, just in time.
I keep coming back to the word briefing. A briefing has a very specific job.
Its job is not to give you all available information, but it is to transfer enough information into your head that you can make a good decision.
And unlike a static summary, an AI briefing can be interactive and efficient. The default experience can be passive where you sit back and listen. But the moment something triggers your attention, you can go deeper.
You should not have to inspect every detail with equal intensity. The system should help you identify where your attention is actually needed.
One important point I want to make is that the briefing cannot become a replacement for the underlying evidence, every important statement should be inspectable.
The agent is not there to hide complexity. It is there to guide you through it.
This changes how I think about the "should humans still read code?" debate.
Maybe the goal is not to eliminate reading code. Maybe the goal is to change when we read it.
Today, reviewing unfamiliar work often looks like this:
raw diff → reconstruct context → understand what matters → review
I think the better sequence might be:
briefing → build mental model → ask questions → identify important areas → inspect relevant code → review
You still read code, but now you are reading a core or wherever you think matters most with context.
And hopefully you only spend your limited attention on the parts that deserve it.