Flint is fine for doing predetermined chat types, with very low customization. But I found using an agent or sub agent to create the Vega spec directly allowed for a lot more flexibility, and ultimately that means higher quality visualizations (stuff like adding points for min and max on a timeseries, or adding a callout marker for a date where some event happened).
That being said, with Vega lite you have to validate your chart specs, provide specific guidance, and play whack a mole with Vega bugs/idiosyncrasies. So Flint is more reliable if you don’t want to dedicate a whole skill to making charts and want to get running quickly.
If AI is writing the "Flint", why not just have it write the backend code instead? I'm not sure why I would want pluggable charting backends.
I can see an argument for providing simpler APIs for LLMs, though, so that it can be more token efficient for example.
Microsoft/Flint-Chart
https://github.com/microsoft/flint-chart
https://news.ycombinator.com/item?id=48756577
[ok]
08 Jul 2026 17:46:12 UTC
Show HN: Microsoft releases Flint, a visualization language for AI agents
https://microsoft.github.io/flint-chart/#/
https://news.ycombinator.com/item?id=48834924
[ok]
Maybe a long term play would be putting this out and creating a "graphics bench" to entice the labs to overfit on your DSL but that seems like a lot of work
Switch backends to use their native strengths: ECharts for hierarchical sunbursts, Plotly for statistical and analytical traces, or Excel for editable charts embedded in a workbook.
Or just find a charting library that you like and actually get to know what it can do, vs mixing and matching presets from different libraries but never tweaking them.
But there’s not one word of why this is good for LLMs, or how they tested/measured that.
My gut would tell me that a new solution put up against all the vega lite specs it’s already be trained on would be a hard thing to win.
I'm 99% sure the verbosity required in the system prompt to teach non-M$ models this new ever-so-slightly-different-but-not-obviously-necessary chart def abstraction format, and the iterations required to get it right, will outweigh any supposed efficiency gains resulting from using it.
Just stating the obvious.
Used correctly, this hasn't been true for a quite a while. Most inference engines have a form of grammar constrained decoding. See, for example: https://vllm.ai/blog/2025-01-14-struct-decode-intro
I had the best success with popular and versatile packages like matplotlib and ggplot2 - even 1.5 ago (vide https://quesma.com/blog/which-chart-would-you-swipe-right/).
Now, frankly, my go-to visualization package is React, sometimes with a pinch of D3.js (e.g. https://p.migdal.pl/tree-of-tree/).
The linked website has only two mentions of AI, and one of them is the title, the approach isn't AI-centric in any meaningful sense either
LLMs are surprisingly bad at generating JSON.
But way less so in TS. Because the types/interfaces are there to guide it further.
So everyone’s adding types everywhere: “Agent friendly”
What would a CSS type system look like !
> for humans
And dare I say “agents” - it’d be nice to have very nuanced types
... as the kids would say: "weak sauce"
... and it's just a tool to create charts not a "visualization language"
you could probably vibeslop a pipeline from some ad-hoc DSL to excel or pandas or R and get a better integration with your business context
They even wrote a book about how they went about it (not that it speaks to the quality of the API) https://link.springer.com/book/10.1007/0-387-28695-0
I actually stumbled upon this book when I was trying to look up how draftsmen (with pens and pencils on paper) did qualitative graphics as I found they had a lot of charm as opposed to modern charting libraries. It's something I noticed when looking through a bunch of historical RBA (Reserve bank of Australia) annual reports, the 1960-1980 charts had a lot of character, but then you go into the early 2000s and its a stale chart from excel.
Anyways ggplot doesn't really recapture the magic of those older charts, but it seems use quite a few of those as a baseline for how to communicate information. Like in figure 20.1 they talk about efforts to replicate older inforgraphics that showed Napoleon’s March on Russia, this graphic here (I think the example in the book is a bit nicer than the one in this blogpost IMO)
https://www.andrewheiss.com/blog/2017/08/10/exploring-minard...
On top of the charts just look nicer than anything you could produce with pyplot (and any API built on top of it) as pyplot seems to be have some really limited raster based rendering or something and the text handling is incredibly limited, I've never had this issue in ggplot.
I feel like most software engineers aren't exposed to because it exists in the R ecosystem which is more so data scientist, econometricians, statisticians and other quantitative data professions, but it definitely one of the nicer APIs and I wish more people in the node and python ecosystem copied their homework. I see vega's full name is something to do with grammars, but idk it's for the same reason.
Wilkinson’s Grammar of Graphics inspired ggplot. The textbook doesn’t even mention ggplot.
Shameless plug for my own GoG inspired DSL, Algraf:
https://williamcotton.github.io/algraf/demos
There’s a Minard plot in the demos!
I wish I could edit my original comment to add this correction.
https://raw.githubusercontent.com/rstudio/cheatsheets/main/p... it's made by the same people behind ggplot. Hadley Wickham worked for RStudio which also created plotnine.
plotnine is currently sponsored by Posit where Hadley works.
In this vein, I think I prefer ggsql that made it to HN recently [0].
[0]: https://ggsql.org/
I dont see what this brings to the table
https://github.com/jemmybutton/fiziko
https://x.com/Angus_KST/status/2057757395196293262/video/1?s...
It’s incomplete but it show cases some of what I mean. There’s just a lot more charm in these earlier graphics. I’m fairly certain they had to consider how the different colours of ink bleed on one another.
Like take 1978 for example, this might be some kind of highlighter ink, and when the colours over lap the grid they interact in ways most overlapping geometry don’t in charting libraries (but in CSS you can get a similar effect with mix-blend-mode: multiply)
https://www.rba.gov.au/publications/annual-reports/rba/1978/...
If you go to page 159 of the most recent RBA report, you’ll see otherwise clean clear charts that do a good job of communicating the relevant information (perhaps that’s all there should do from such an institution), but it’s admittedly soulless compared to the charts from previous decades
https://www.rba.gov.au/publications/annual-reports/rba/2025/...