Diagrams AI can, and cannot, generate

Yup.

Inasmuch as these are collaborative document generators at their core, "minimally ambiguous prompt and conforming reply" is a strongly represented document structure and so we benefit by setting them up to complete one.

Likewise, "tragi-comic dialog between increasingly frustrated instructor and bumbling pupil" is also a widely represented document structure that we benefit by trying to avoid.

Chatbot training works to minimize the chance of an LLM engaging in the latter, because dialog is a intuitive interface that users enjoy, but we can avoid the problem more successfully by just providing a new and less ambiguous prompt in a new session, as you suggest.

This means the leading UI for LLMs - the chat - is the wrong UI, at least for some of the tasks. We should instead have a single query text field, like in search engines, that you continue to edit and refine, just like in complex search queries.

I've also started adding "Ask any questions you think are relevant before starting" to the end of my prompts. It usually results in at least one question that addresses something I didn't think to add to my prompt.

It seems like the author in fact did do this. They asked Claud the same message. I really doubt they repeated the entire conversation to get to that point, but I may be wrong.

From personal experience, I agree with you, but I wouldn't make the critique here as it is far from a magic bullet. Honestly, with the first stuff it seems faster to learn mermaid and implement it yourself. Mermaid can be learned in a rather short time, the basic syntax is fairly trivial and essentially obvious. As an added benefit, you then get to have this knowledge and use it later on. This will certainly feel slower than the iterative back and forth with a LLM -- either by follow-up conversations or refining your one shot -- but I'm not convinced it will be a huge difference in time as measured by the clock on the wall[0]

[0] idk, going back and forth with an LLM and refining my initial messages feels slow to me. It reminds me of print statement debugging in a compiled language. Lots of empty time.

100%

To be honest, this would help a lot of person-implemented iteration too, if it was biologically feasible to erase a conversation from a brain.

I built Plandex[1], an open source AI coding agent, partly to enable this workflow.

It has `log` and `rewind` commands that allow you to easily back up to any previous point in the conversation and start again from there with an updated prompt. Plandex also has branches, which can be helpful for not losing history when using this approach.

You’re right that it’s often a way to get superior results. Having mistakes or bad output in the conversation history tends to beget more mistakes and bad output, even if you are specifically directing the LLM to fix those things. Trial and error with a new prompt and clean context avoids this problem.

1 - https://plandex.ai

P.S. I wrote a bit about the pros and cons of this approach vs. continuing to prompt iteratively in Plandex’s docs here: https://docs.plandex.ai/core-concepts/prompts#which-is-bette...

I tried this approach when attempting to get Deepseek-r1 and GrokV3 to create a simple CUDA application. It was necessary because the iterative approach kept leading to hangs and divergent behaviors. I still wasn't able to get a working application, however.

I love Claude, but whomever works on their UI needs to be slapped a bit. Code output covering the stop button on my laptop, page lockups on iPhone/Chrome with certain artifacts (even after reload), crazy slow typing on the computer and refusal to “continue” chat with a cheaper model. Simply providing a summary of the chat on running out of tokens would let me start another conversation, or at least a warning I was getting close.

Neat idea!

Could you go into a bit more detail on how you encode the intent?

Any simple examples?

Oh wow, thank you for linking that paper. I've been working an interactive tool for a while and have been musing on new constraint and layout types to add. Anecdotally it seems a lot of mainstream graph layout algorithms work well for small to mediumish complexity inputs, but then quickly start generating visual spaghetti. So this looks incredibly apropos for me.

App is unavailable in the US :(

Thanks for link to the Monash's paper.

>LLMs seem ill-suited to solving the optimization of combinatorial and geometric constraints and objectives required for good diagram layout.

I think this is where LLM distance NLP cousin can be of help namely CUE since fundamentally it's based on feature structure from the deterministic approach of NLP unlike LLM that's stochastic NLP [1],[2],[3].

Based on the Monash's paper, Constraint Programming (CP) is one of the popular approaches that's being used for the automatic grid layout.

Since CUE is a constraint configuration language belong to CP, and its NLP background should make it easier and seamless to integrate with LLM. If someone somehow can crack this then it will be a new generation LLM that can perform good and accurate diagramming via prompts and it will be a boon for the architect, designer and engineer. Talking about engineer, if this approach can also be used for IC layout design (analog and digital) not only for diagrams, it will easily disrupt the multi-billion dollars industry for the very expensive software for IC design and man powers.

I hope I'm not getting ahead of myself, but ultimately this combo can probably solve the "holy grails" problem mentioned towards the end of the paper's conclusions regarding layout model that somehow incorporates routing in a way that is efficiently solvable to optimality. After all some people in computer science consider CP as "holy grails" of programming [4].

Please someone somehow make a start up, or any existing YC startup like JITX (Hi Patrick) can look into this potential fruitful endeavor of hybrid LLM combo for automated IC design [5].

Perhaps your random thoughts are not so random but deterministic non-random in nature, pardon the pun.

[1] Cue – A language for defining, generating, and validating data:

https://news.ycombinator.com/item?id=20847943

[2] Feature structure:

https://en.m.wikipedia.org/wiki/Feature_structure

[3] The Logic of CUE:

https://cuelang.org/docs/concept/the-logic-of-cue/

[4] Solving Combinatorial Optimization Problems with Constraint Programming and OscaR [video]:

https://m.youtube.com/watch?v=opXBR00z_QM

[5] JITX: Automatic circuit board design:

https://www.ycombinator.com/companies/jitx

Comments like these are why I come to hacker news! I'm working on a project right now where I've been learning mermaid, but have gotten to the point where it would be easier for me to draw it out and convert this way by a lot. I'll try this!

Printing?

Ive had similar results asking chatgpt to generate inout files for graphviz "dot". Pretty good. E.g. i asked it to summarize a complex article and draw the people named and their relationships. I also got it embellish the diagrams a little but, but it needed a lot of guidance to know what kind of nodes to add.

But it was good at arranging the elements in timeline order for example.

I talk about this, kind-of, in my article about process visualization (in German, available behind paywall and in print). It‘s not rigorous in the sense that I give points, but a picture emerges along the way. Based on the full set of practical examples there, I would recommend the „v1“ of Claude 3.5 Sonnet. GPT 4.5 also looks good, but I haven‘t run the full suite.

https://www.heise.de/ratgeber/Prozessvisualisierung-mit-gene...

Bpmn diagrams from prompt? Did you try any that was good?

Plantuml works pretty well with openai models.

plantuml also supports AWS icons