Yes. That looks like a nice basis for reverse engineering :)

"how can we build frameworks and tooling that expose our system as a graph of dependencies?"

The raw data about these is already in the system; the only question is how to detect it. Making the system more uniform is certainly relevant. But there will always be a need to have a translating tool.

"Build verification agents or swarms"

Most questions about systems require deterministic answers, and those are best addressed by deterministic tools. Agents can be used to produce such tools, but that's merely an optimization. The essential practice is the building of the contextual tools.

"Avoiding the need to reverse engineer these flows will be key."

Software engineering is primarily made out of answering questions about systems to learn what to do next. Those should be mediated by tools. Some level of reverse engineering is essential.

"Sometimes we don’t need perfect accuracy — as long as the agent picks the right path it can re-inspect certain details or dive deeper as needed"

It's true that we don't always need perfect accuracy. But we should distinguish between knowing the accuracy error or not knowing it as with LLMs.

I did read it.

I see several points differently.

People entertain something the LLM summaries in the same way as they entertain people drawing on the whiteboard what the current system is. Neither are more than hypotheses and neither should qualify as engineering answers.

The next chapter of Rewilding Software Engineering book will tackle why LLMs shouldn't be used to summarize the architecture directly. Answering system questions is essential but the answers should be mediated by deterministic tools. LLMs can be used to generate the tools. @swardley.bsky.social

That statement is not quite correct. With tools, we can perceive software quite well.

Congratulations.

Writing code hasn’t been a bottleneck since a very long time. The bottleneck was and still is figuring the system out.