Give AI the context a teammate would need.

Start with the goal and boundaries

Say who will read the diagram and what question it should answer. Name the cloud or runtime if it matters. Describe the system boundary, external actors, main services, and data stores. Include important constraints such as private data access, expected scale, or an asynchronous workflow.

Describe the connections

Write relationships as actions: the browser calls the API, the API publishes a job, workers consume it, and the worker writes a result. Tell the model which boundaries or connection labels should be visible. Avoid relying on component names alone to imply the whole topology.

Use a concrete prompt

Example: Create a diagram for a small job-processing app. A browser calls an authenticated API. The API stores metadata in PostgreSQL and publishes jobs to a queue. Two workers consume jobs and save results to object storage. Show the async flow, private data stores, and the user-facing result request.

Do not paste credentials, production tokens, or personal records. Use generic names or redacted examples when a real value is unnecessary.

Iterate with a bounded change

Ask for one change at a time: add a retry queue between the workers and the main queue; keep all other components. Inspect the proposed changes before applying them. Check disconnected nodes, unsupported assumptions, and whether every important arrow still makes sense.

A rendered diagram is not evidence that the architecture is secure or deployable. Validate engineering decisions with the actual system configuration.