Generating UML with AI
A language model will produce a UML diagram from two sentences of description, and most of it will be right. This is about the part that is not: the four mistakes generation makes every time, and the two-minute check that catches them before the diagram reaches a team.
9 min readUML 2.5.119 of 23
01What generation is actually good at
Two things, and they are the two that cost the most time. The first is the blank page: naming the eight nouns in a domain and putting them on a canvas is half an hour of work that produces nothing anyone will argue about, and a model does it in seconds. The second is notation lookup - which arrowhead means realization, which end the diamond goes on, what a multiplicity of 0..* looks like next to 1. That knowledge is in the spec, the spec is in the training data, and remembering it was never the interesting part of the job.
The diagram at the top of this article came from a description two sentences long. The classes are right, the attributes are plausible, and a person who knows the domain can read it and start arguing about the parts that matter - which is exactly what a first draft is for.
02The four failures, in order
These repeat across models and across prompts, because they are all the same failure underneath: the generator is picking the most common answer, and your system is not the most common system.
- Composition drawn as aggregation, or as a plain association. The hollow diamond is the safe-looking choice, so it is the one that comes back. It is also the one that says the parts survive the whole, which is a claim about deletion and about ownership that nobody checked.
- Multiplicities defaulted to one-to-many. Unasked, almost every association comes back
1to0..*. Sometimes that is right. When it is not, it is the kind of wrong that survives into a schema. - Interfaces invented for single implementations. Models have read a great deal of enterprise Java. If your domain has one payment provider, an
«interface» IPaymentProviderin the draft is decoration. - The wrong diagram kind entirely.Ask about behaviour over time and a class diagram comes back, because class diagrams dominate the training data. If the question was "what happens when the payment fails", you wanted a sequence diagram.
None of these are hard to fix. All of them are hard to notice, because a wrong relationship kind looks exactly as confident as a right one, and the diagram is tidy either way.
03Prompting for something checkable
Three ingredients, and the third is the one people leave out.
- Name the diagram kind."A class diagram", not "a UML diagram". If you are not sure which kind you want, that is a modelling question and the fourteen kinds are here.
- Give it your nouns. The words your team already uses, spelled the way your code spells them. A model that invents
BorrowRecordwhen you sayLoanproduces a diagram nobody can map onto anything. - State the question the diagram must answer."...that shows what happens to loans when a copy is withdrawn." This is what turns a plausible picture into a checkable claim, and it is the single highest-value sentence in any prompt.
04The two-minute review
Run this before the diagram leaves your screen. It maps one-to-one onto the four failures above, and it is the whole difference between a generated diagram that helps and one that quietly misinforms a team for a year.
Reach for it when
- Every diamond: does the part really die with the whole? Filled if yes, hollow if not
- Every multiplicity: read it aloud as a sentence and check it against a real case
- Every interface: is there a second implementation, or could there plausibly be one?
- The diagram kind: does this shape answer the question you asked, or a different one?
Reach for something else when
- Accepting attribute types - they are guesses, and cheap to correct later
- Arguing about layout before the relationships are right
- Asking for a redraw when a single edge is wrong - fix it in the editor
- Circulating it before somebody who knows the domain has read it once
Two minutes is not an exaggeration: on a diagram of eight boxes it is four glances. What makes it work is knowing what you are looking for, which is why the list is short and specific rather than "review carefully".
05How this works in Archyno
Archyno generates into a model rather than into a picture, and that difference is the reason this article can end where it does. The AI is handed the same metamodel the editor enforces, so what comes back is elements and relationships the notation actually permits - a realization can only land on an interface, an ArchiMate serving relationship can only connect the layers the spec allows. The categories of error above shrink to the ones no tool can catch: the ones about your system.
Because it is a model and not an image, the correction is an edit rather than a re-prompt. Change the diamond, change the multiplicity, rename the class - and the rename reaches every view the element appears on. The result exports as PNG, SVG, Mermaid, XMI or a Sparx .qea file, which is what makes a generated diagram something you can hand to a team that does not use the same tool as you.
In one line each
- 01Generation is excellent at the blank page and at notation, which is most of the friction.
- 02It is unreliable about ownership, multiplicity, invented interfaces and diagram kind.
- 03Name the diagram kind, supply your own nouns, and state the question it must answer.
- 04Review four things: diamonds, multiplicities, interfaces, and whether the kind fits.
- 05Generate into a model rather than an image, or every correction is another prompt.
- 06Nothing about generation replaces somebody who knows the domain reading it once.
The ArchiMate half of this - where the layer rules make generation both harder and more useful - is in generating ArchiMate diagrams with AI. What the tool does and does not do is set out plainly in why Archyno.
06Common questions
Can AI generate a UML diagram from a text description?
Yes, and the first draft is usually structurally sound: the right classes, sensible names, and relationships that mostly point the right way. What it cannot do is know which of several defensible models matches your system, so treat the output as a draft written by somebody who has read the spec but not your codebase.
What do AI-generated UML diagrams get wrong most often?
Four things, in order: composition drawn as aggregation or plain association, multiplicities that default to one-to-many without being asked, interfaces invented for classes that have one implementation, and a class diagram returned when the question needed a sequence or component diagram. All four are visible in under two minutes if you know to look.
How should I prompt for a UML diagram?
Name the diagram kind, list the nouns you already use, and state the question the diagram has to answer. "A class diagram of library lending - members, loans, copies, titles - that shows what happens to loans when a copy is withdrawn" produces something checkable, where "draw UML for a library" produces a plausible diagram of a library nobody runs.
Is a generated diagram good enough to hand to a team?
After a review, yes, and that is the honest position. Generation removes the blank page and the notation lookup, which is most of the friction; deciding whether the model matches your system is judgement nobody can generate for you. The diagrams that cause damage are the ones nobody read before circulating.
Related reading