Dale Spoonemore
โ† All posts

Writing ยท Dale Spoonemore

How I use AI to visualize complicated things

November 4, 2026

Detail from our Untangle process diagram, showing roles and handoffs between agents.
A closer look at the process diagram we worked through with Devin. Open the full diagram.

I've been using AI to turn complicated things into pictures so I can understand them better and work through them with the AI. A process spread across several documents might make sense when I read each piece, but I have a harder time seeing how everything fits together. Having the AI draw it gives us something we can both refer to while we talk through it.

Then I can point to a step and ask why it's there, what's supposed to happen next, or who's responsible for it. As we make changes, the AI updates the picture, and I can see whether it understood what I meant. That has been useful in a lot of different situations. Our development process at Untangle is one example.

A product change at Untangle passes through a lot of hands, and most of them are AI agents. There's a delivery desk I talk to, a product manager that writes the ticket, a designer, lane managers, builders, an independent QA reviewer, and GitHub's merge queue at the end. The instructions for how work moves between them are written in AGENTS.md and a set of skills in our repo.

There's a lot going on in those files. I could read an individual rule and understand it, but I wanted to see the whole path a ticket takes. Who has it right now? What happens when they're done? Where does it come back to me for a decision? Where could it get stuck?

So I had Devin draw a sequence diagram, with columns for the different roles and arrows showing the handoffs between them.

The first version was too detailed to read easily, so I asked it to simplify it. Then I spent most of a day going through the picture step by step, asking questions and having Devin make changes as I went. The diagram gave us a shared reference for that conversation. I could point to the part I was trying to understand, and we could work on it together.

One of the things we found was a missing cycle assignment. The instructions for creating a ticket included checking Linear for duplicates and setting a title, owner, priority, and status. Nothing said whether the ticket belonged in the current cycle. Looking at that step in the picture made it easier to notice what wasn't there.

We also made the human review points clearer. For anything with a screen, I want to see a mockup in the real app before the builder goes too far. Once the basic feature works, I want a short video before it moves through QA and the rest of the process. Putting those on the chart as separate steps let us work through when they should happen and who should bring them back to us.

Another thing we changed was the merge handoff. We had a separate merge-manager session sitting between the lane manager and GitHub's merge queue. Once I could see that extra hop, it was easier to work through whether we needed it. Now the lane manager that already owns the work submits the approved commit to the queue and records the receipt.

Here's the chart we're using now.

Sequence diagram of the Untangle development process, showing roles in columns and ticket handoffs through production.
Untangle development process. Diagram created with Devin. Open the original image.

You don't need to read every row to get the idea. Each column represents a role or a place where work gets recorded, and each arrow shows how it moves from one to another. I can follow a ticket from the original request through production and see where decisions, reviews, and handoffs happen.

Each row also links back to the instructions behind it. That matters because I want to be able to move between the picture and the details. If a step looks wrong, we can open the rule that produced it, talk through the change, and update both.

I used the same approach to work through our documentation. I had Devin make charts of the docs we had, then used those to help decide what belonged in a skill and what could go. I also went through AGENTS.md line by line. The pictures helped me get oriented and ask better questions as I worked through the text.

For this particular example, we took it a little further and made the chart generated from a file in the repo. That file identifies each step, its owner, and the skill section containing the rule. When the process changes, we can regenerate the picture and review it alongside the changes to the instructions. I also added a skill in our Devin org so any session can refresh it when asked.

I've been doing this with other things, too. We have a ticket map that shows dependencies as connections we can move around. I keep a merge-queue board on the TV above my desk so I can see what's happening without opening every thread. Each view helps me work with information that would take more effort to follow as a list or a series of messages.

What I like about doing this with AI is that I can keep working with the picture. I can ask for less detail, expand one section, question a connection, or try a different arrangement. Sometimes the first version is hard to follow, and figuring out why helps me explain what I'm actually trying to understand.

That's become a useful way for me to work with AI as a thought partner. When something is complicated and spread across a bunch of text, I'll ask it to draw what we're talking about. Then we have something we can look at together, question, and change until we're on the same page.

โ† All posts