UML has a reputation for being heavyweight, but most engineers still reach for it when they need to be precise: a class diagram to pin down a model, a sequence diagram to nail an interaction, a state machine to make the transitions explicit. The problem was never UML. It was the drawing. Laying out a dozen classes with their fields and relationships by hand is exactly the kind of fiddly, mechanical work nobody wants to do twice.
That makes it an almost perfect fit for AI. The structure is well defined, the notation is standard, and the layout is rules-based. You bring the intent; the tool does the placement.
Two ways in: describe it or point at code
There are two honest starting points for an AI-generated UML diagram, and they suit different moments.
- From a description, when the design is still in your head. "A User has many Orders; each Order has Line Items; a Line Item references a Product." You are sketching the model out loud and want to see it.
- From existing code or schema, when the design already exists and you want the picture. Your classes, your SQL tables, your types already encode the relationships. Generating from them means the diagram matches reality instead of your memory of it.
The second one is the quiet superpower. A class diagram derived from the actual types cannot lie about the fields, and an ER-style model generated from real DDL cannot invent a relationship that is not there.
A class diagram, from a sentence
Say you describe a small ordering model. The generated diagram gives you real boxes: each class with its attributes, and the associations drawn with proper multiplicity, not just plain lines.
Sequence diagrams: the interaction, not the objects
Class diagrams show structure; sequence diagrams show behaviour over time. They are even more tedious to draw by hand because every message is a precisely placed arrow between lifelines. Describe the flow instead: "The client calls the API, which checks the cache, misses, queries the database, writes the cache, and returns." You get lifelines and ordered messages you can then trim and annotate.
The notation is standard and the layout is rules-based. That is precisely why a machine can draft it and you can trust yourself to fix it.
Keep it honest: generate from the real thing
The most durable UML is not drawn from imagination; it is derived from what already exists. If your models drift, so does a hand-drawn diagram. Generating the class diagram from your actual types, or a data model from your real schema, means the picture updates when the code does. Regenerate instead of redraw, and the diagram stops being a museum piece.
Then make it readable, because UML can get dense
Full UML can become a wall of boxes fast. The advantage of editable output is that you can prune it to the point you are actually making. Hide the attributes that do not matter for this diagram. Group the classes in one aggregate. Highlight the relationship the reader needs to notice. A diagram that says one thing clearly beats a complete one nobody reads.
Generate the structure, correct the details, trim to the message, and export a version that lasts. UML stops being a chore and goes back to being what it was for: a precise, shared picture of how the system is put together.