Automation

From prompt to architecture: building systems visually with AI

A practical walkthrough: describe a system in one sentence, get a first-draft architecture, then shape it into something you would actually put in a design doc.

The hardest box to draw is the first one. You know roughly what the system looks like in your head, but turning that into shapes on a canvas means dozens of small decisions before you have anything to react to. This is where describing it in words first genuinely changes the workflow: you get a draft in seconds, and drafts are much easier to argue with than blank space.

Here is the whole loop, start to finish, on a real example. The goal is not a magic finished diagram; it is a good enough first pass that you then make correct by hand.

Step 1: write one honest sentence

Do not overthink the prompt. Describe the system the way you would to a new teammate. Name the pieces and how they connect.

prompt
A web app with a CDN in front, a load balancer,
two stateless API servers, a Postgres primary
with one read replica, a Redis cache, and a
background worker reading from a queue.

That sentence carries everything a first draft needs: the components, the fan-out (two API servers), the data tier (primary plus replica), and the async path (worker plus queue). You are not asking the tool to be clever. You are asking it to place what you already said.

Step 2: get the draft

Paste that into the generate dialog and you get a laid-out diagram of real, editable shapes. The value here is speed and completeness: every component you named is on the canvas, roughly in the right relationship, in the time it took to read the sentence.

CDN balancer api 1 api 2 primary replica redis worker
Everything from the sentence, placed. Now the real work starts: making it correct.

Step 3: correct what the machine guessed

This is the step that separates a useful tool from a party trick. The draft is a guess, and guesses are wrong in small ways. Maybe the cache should sit in front of the database, not beside it. Maybe only one API server talks to the replica. Because the output is editable shapes, fixing it is dragging and clicking, not starting over.

  • Move the pieces the layout misplaced.
  • Draw the connection it missed, or delete one it invented.
  • Highlight the path that matters (the write path, say) so a reader's eye lands there first.
  • Group the pieces that belong to one service or one team.

The prompt gets you to a draft. Your edits get you to the truth. Only one of those steps needs a human, and it is the second.

Step 4: refine by asking, not just dragging

You do not have to do everything by hand. If the shape of the system is roughly right but you want a variation, ask for it: "add an object store for uploads," or "put an API gateway in front of the services." Treat the conversation as a fast way to reach the next draft, then go back to editing. The two modes, talking and dragging, reinforce each other.

Tip. Keep prompts small and iterative. One clear change per request beats a paragraph of instructions. It is easier to review, and easier to undo when the model guesses wrong.

Step 5: make it a real artifact

A diagram that lives only in your head does no one any good. Once the picture is right, put it where it will be used. Export to PNG, SVG or PDF for a design doc. Embed it in a README as a read-only view. Or export it to Mermaid or D2 so a text version lands in the pull request and gets reviewed like code.

That is the full loop: a sentence becomes a draft, the draft becomes correct through your edits, and the correct diagram becomes something your team can actually use. The AI removed the slowest, least valuable part (placing boxes) and left you the part that needs judgment. Describe your next system in a sentence and see how far the first draft gets you.

Describe a system, get a diagram to shape

Write one sentence, get a first-draft architecture in editable shapes, and make it yours in minutes.

Open LetDraw, free