When I was an engineer, I thought the document or diagram was the hard part.
That was not an unreasonable conclusion. A good diagram takes time. You have to decide what belongs, choose the right level of abstraction, represent the relationships, and understand what the audience actually needs. A good technical document has the same problem. The author has to organize the design, explain the assumptions, expose the trade-offs, and make the reasoning clear enough for someone else to follow.
Those things are genuinely difficult.
However these are only some of the difficult things.
The document is not the architecture. The diagram is not the decision.
They are artifacts that help people have a conversation about the architecture or the decision. That distinction has become more obvious as LLMs have made it easier to create material that looks like architecture work. A model can produce a framework, template, diagram, technical memo, platform comparison, or plausible first recommendation. The output may even be good.
But the existence of the output does not mean the organization has moved. Writing something does not mean anyone read it. Reading it does not mean they understood it. Understanding it does not mean they agree with it. Even agreement does not mean people accepted the operational consequences, established ownership, committed resources, or decided to act.
AI can accelerate production of the artifact. It does not automatically accelerate the path from artifact to action.
Documents give the conversation somewhere to start
I do not mean to imply that documents and diagrams are unimportant. Quite the opposite.
A documented idea gives people something stable to react to. Without it, the proposal may exist as several slightly different versions in several people’s heads. One person remembers the meeting one way. Someone else interpreted the decision differently. Another person heard about it secondhand and is operating from an incomplete summary.
Writing the idea down creates a shared reference point. It lets someone challenge an assumption, question the risk, identify an existing investment, or explain that the technical design works but the ownership model does not.
That is useful. It is also the beginning of the work rather than the end.
In my experience, almost every meaningful proposal follows some version of this path. The document gets shared. Comments arrive. Informal messages follow. Someone forwards it to a stakeholder who was not originally involved. Eventually, written comments may stop being enough to reveal where the disagreement actually sits.
Then the proposal changes. It may get stronger or narrower. A constraint may appear that the original author did not know about. Sometimes everyone understands the proposal and still does not agree with it.
That does not necessarily mean the document failed. The artifact gave the conversation somewhere to start.
Cheaper production can move work downstream
I use AI throughout architecture work. It helps me find useful frameworks, create document templates, draft memos, experiment with workflow diagrams, and challenge my assumptions. I can ask it to argue against a position, identify missing context, or explain how someone with different expertise might interpret the same proposal. I have also used agents across a large knowledge environment to surface relevant work before someone formally asks for architectural involvement.
All of those uses have value. They also make it easier to produce more material than an organization can realistically understand.
LLM-generated documents are often thorough and polished. They are also often verbose. Decisions get buried under background material. Sections appear because they seem defensible in isolation, not because they help this audience make this decision. A template quietly grows new headings, terminology drifts, and the familiar structure that once reduced cognitive load becomes slightly different in every document.
The author may have saved an hour while ten reviewers each spend extra time finding the actual decision. That is not an empirical calculation, but it illustrates the problem: a productivity gain for one author can create more aggregate work downstream.
AI has made production cheaper. Attention and understanding remain expensive.
Understanding is necessary, but alignment is different
Geoffrey Litt recently argued that understanding is becoming a bottleneck in AI-assisted software development. His point is not only that humans need to verify agent-written code. We need enough understanding to participate meaningfully—to form the mental models that let us review, change, and imagine what should happen next.
That argument resonates with me. I think enterprise architecture adds another constraint.
A group of people can understand the same proposal and still disagree. They may have different incentives, own different consequences, control different resources, or carry different risks. One team may focus on security exposure. Another may be responsible for operational stability. Another controls the budget. Another takes the first support call when the system fails.
The disagreement may not come from confusion. It may come from each group correctly understanding what the decision means for them.
Understanding is required for participation. Alignment is what allows the organization to move. That does not require universal enthusiasm. It may mean the trade-offs are visible, objections have been heard, decision rights are understood, ownership is established, and the organization is prepared to proceed.
Litt’s argument concerns understanding and participation in AI-assisted software development. The extension to organizational alignment is mine. Generating an artifact that everyone understands is still different from reaching a decision people are prepared to execute.
Architecture artifacts are conversation infrastructure
I have started thinking about architecture artifacts as conversation infrastructure.
Their purpose is not merely to preserve information. Their purpose is to make a useful conversation possible. A strong artifact should make the decision easy to locate, expose the assumptions behind it, show the trade-offs and unresolved uncertainty, state what feedback is needed, and help the right people disagree productively.
That framing changes what good looks like.
The most complete document may not be the most useful. A document can be technically correct and still fail because it is too dense, arrives too late, reaches the wrong audience, or ignores the operating consequences for the teams expected to implement it. A lightweight artifact may succeed because it creates enough shared context for the right decision.
Completeness and usefulness are not the same. More content is not necessarily more clarity.
AI around the artifact
The obvious use of AI in architecture is producing artifacts faster. I will continue using it that way. But I am increasingly interested in what AI can do around the artifact.
Can it identify assumptions likely to be challenged? Can it distinguish technical disagreement from an ownership disagreement? Can it surface a missing stakeholder before the final review? Can it reconcile reviewer feedback that uses different language for the same concern? Can it summarize meaningful changes between versions or shorten a document without hiding the trade-offs required for a decision?
Those uses may be more valuable than asking a model to produce a longer, more polished document. The opportunity is not only to maximize output. It is to reduce the cost of participation.
AI can adapt a proposal for audiences with different levels of context. It can make assumptions easier to find and likely objections easier to anticipate. It can support the conditions under which alignment becomes possible.
It cannot complete the social and organizational decision by itself. AI cannot resolve incompatible incentives, assign authority, create operational capacity, establish accountability, or make a team accept a trade-off it does not have the resources to support.
At some point, people still have to talk to each other. They have to decide. They have to accept that the chosen direction may not satisfy every preference.
AI may make that process clearer. I am not convinced it can make the process disappear.
The hard part was never just the diagram
Looking back, I understand why the document or diagram once looked like the work. It was visible, reviewable, and finishable. You could point to it and say it was done.
Architecture is less legible. Much of its value exists in conversations, context, decisions, visible trade-offs, reduced uncertainty, and problems that never became worse. The artifact is often just the visible trace of that work.
LLMs are making the distinction harder to ignore. If almost anyone can create a credible-looking architecture document, the architect’s value cannot be the existence of the document. It has to include knowing what requires a decision, which context matters, who needs to participate, what consequences have been hidden, and how the organization can move from a plausible proposal to something it is prepared to execute.
The document still matters. The diagram still matters.
But neither one is the work by itself.
The work is what happens around them.
References: