In 2022, AI writing tools became useful enough to change how people write. In 2023, AI coding tools became useful enough to change how people build software. In 2026, the same shift is happening to visual communication. It is moving more slowly, and less loudly, than the other two. But the change is more significant.

This is an opinion. Some of it is observable, some of it is a bet. I will try to be clear about which is which.

What is observable

AI has already made diagrams easier to create. Tools that used to require an hour of manual layout now produce a starting point in thirty seconds. The friction of diagramming has dropped substantially.

The result, for teams that have adopted these tools, is that diagrams are used more often. Not because people became more disciplined about visual communication, but because the cost of a diagram dropped below the threshold where it felt worth skipping.

This is a meaningful change. When diagrams are cheap to produce, they get produced earlier in the design process. Problems that used to be discovered during implementation get discovered during planning. That is not a marginal improvement. Fixing a design problem in a diagram costs minutes. Fixing the same problem in shipped code costs days.

The gap between writing and diagramming

AI writing tools went from "useful novelty" to "professional default" in about eighteen months. AI coding tools followed a similar curve. AI diagramming tools are further behind, for two reasons.

First, the training data problem. Language models were pre-trained on enormous amounts of text and code. Diagrams are sparse in that corpus. The structural understanding required to produce a good architecture diagram is harder to acquire from text alone.

Second, the evaluation problem. "Is this a good sentence?" is a question humans can answer in a second. "Is this a good architecture diagram?" requires domain knowledge and context. The feedback loop for improving diagram generation is slower.

Both of these gaps are closing. But the closing is happening in years, not months.

What comes next (the bet part)

The first generation of AI diagramming is generation. You describe, it draws. That is useful. The second generation is collaboration: the AI participates in the diagramming process the way a good colleague would.

This means the AI notices when a diagram has a pattern it has seen fail before. It asks whether you have accounted for the error case on this edge. It suggests that this component is doing two things and might want to be two components.

This is not search and retrieval. It is reasoning about structure, applied in context. The technical requirements are higher than generation. The tools that do this well will change how systems are designed.

A speculative diagram of the collaborative AI diagramming loop: human describes intent, AI generates structure, AI identifies gaps, human refines, repeat.

The third generation is proactive: the AI generates diagrams from the codebase, the API spec, the incident history. Not because you asked, but because the documentation is missing and it knows. The diagram of your architecture as it actually runs, updated continuously, linked to the services it describes.

That third generation is five or more years away. The second generation is closer.

Why visual communication is the right frontier

Text is the medium of record for most organizations. Documents, emails, pull request descriptions, Notion pages. Text scales. Text searches. Text is easy to version and review.

But text is a poor medium for structure. The shape of a system, the flow of a user experience, the dependencies between components: these are not well expressed in text. They are well expressed in diagrams. And most organizations produce far too few of them.

The reason is cost. Making a good diagram takes time. Time that most teams do not have, and so the diagram does not get made. The meeting happens without the diagram. The spec ships without the flow. The architecture grows without documentation.

When AI eliminates the cost of making a diagram, organizations will make more diagrams. When they make more diagrams, they will communicate more clearly. When they communicate more clearly, they will make fewer expensive mistakes.

That is not a small change in how work gets done. It is a large one.

The compounding effect of visual documentation

There is a long-term effect of diagram-heavy teams that does not show up in productivity metrics: institutional knowledge becomes transmissible.

Text documents are hard to onboard from. They are long, context-dependent, and require a reader who already understands enough of the domain to parse what is important. A new engineer joining a team with years of text documentation faces months of reading before they have a working model of the system.

A team with a maintained diagram library is different. The new engineer can look at the architecture diagram and understand the shape of the system in an hour. They can look at the API flow diagrams and understand which services talk to each other. They can look at the user flow diagrams and understand what the product is supposed to do. The diagrams compress years of accumulated context into visual representations that bypass the reading tax.

This is the compounding effect. Teams that diagram consistently produce not just better systems, but more transferable knowledge. They onboard faster, recover from attrition more quickly, and make better decisions because more people have an accurate model of the system.

AI accelerates this effect by making diagram creation so cheap that teams can document decisions they previously would not have bothered with. The threshold for "is this worth diagramming?" drops from "only if we have time" to "yes, always." When that threshold shifts, the knowledge base grows in ways that were not possible when diagramming required dedicated effort.

What this means for DrawIt

How diagram-heavy teams compound knowledge over time. Each sprint adds to an accessible visual library. New team members onboard from diagrams rather than documentation debt.

We built DrawIt around one belief: diagramming should be as fast as thinking. Not faster, not as a replacement for thinking, but as a way of making thinking visible without slowing it down.

The AI features in DrawIt today are the beginning of that. The AI features in DrawIt two years from now will look different, because the underlying technology is moving and our understanding of how people actually use diagrams is deepening.

The question we are asking is not "how do we make AI generate better diagrams." It is "how do we make visual thinking a first-class mode of technical communication." The AI is in service of that goal, not the goal itself.

If we get that right, the next generation of engineers and product builders will find it strange that anyone ever tried to design a system without drawing it first.