I think this a good technique to be familiar with, although in a lot of situations I've achieved similar value by simply feeding the underlying JSON data objects corresponding to the intended UI state back into the coding agent. It doesn't render quite as nicely, but it is often still human-readable, and more importantly both LLM and procedurally interpretable, meaning you can fold the results back into your agentic (and/or conventional testing) development loop. It's not quite as cool, but I think a bit more practical, especially for earlier stage development.
ASCII-Driven Development
31–40 of 97 posts
Re: ASCII-Driven Development
#32A really interesting article, and I'm likely to give it a shot a work. I'm grateful for it, and yet I found it difficult to get through because of a sense of "LLM style" in the prose. I won't speculate on whether the post is AI-written or whether the author has adopted quirks from LLM outputs into their own way of writing because it doesn't really matter. Something about this "feeling" in the writing causes me discom…
I've had too many LLMs tell me that software product ABC can do XYZ, but when I actually read the ABC documentation I discover that that hallucination was the opposite of reality: the docs say "we cannot do XYZ yet but we're working on it." So for me, the question at the back of my mind when I encounter an obviously LLM-generated article is always, "So which parts of this article are factually correct, and which part…
[deleted]
Re: ASCII-Driven Development
#33Author here. High-level: - Problem: AI UI generators are high-fidelity by default → teams bikeshed aesthetics before structure is right. - Idea: use ASCII as an intentionally low-fidelity “layout spec” to lock hierarchy/flow first. Why ASCII: - forces abstraction (no colors/fonts/shadows) - very fast to iterate (seconds) - pasteable anywhere (Slack/Notion/GitHub) - editable by anyone Workflow: - describe UI → generat…
The problem with ASCII-driven development for me is that emoji ruin the alignment. It’d be nice if they could be forced into monospaced. Emoji aren’t ASCII so maybe that’s the problem too.
Re: ASCII-Driven Development
#34A really interesting article, and I'm likely to give it a shot a work. I'm grateful for it, and yet I found it difficult to get through because of a sense of "LLM style" in the prose. I won't speculate on whether the post is AI-written or whether the author has adopted quirks from LLM outputs into their own way of writing because it doesn't really matter. Something about this "feeling" in the writing causes me discom…
"Not as an aesthetic choice. Not as nostalgia. But as a thinking tool " is a perfectly normal sentence, and I think there is an equally bad trend of people assuming things are AI written and forget that AI was trained on human writing. But to your point, agreed there is a disconnect when things are in fact written by AI, but I skimmed the article anyway so to me it didn't matter lol.
Those are sentence fragments, not perfect sentences. They're useful in some contexts, but are inappropriate for more formalized writing.
When LLMs reuse the same patterns dozens of times in a single article, the patterns stops being interesting or surprising and just become obnoxious and grating.
Re: ASCII-Driven Development
#35This is a tangential point (this post is not really about TUIs; sort of the opposite) and I think lots of people know it already but I only figured it out last week and so can't resist sharing it: agents are good at driving tmux, and with tmux as a "browser", can verify TUI layouts. So you can draw layouts like this and prompt Claude or Gemini with them, and get back working versions, which to me is space alien techn…
Would love to hear more about this approach.
Re: ASCII-Driven Development
#36This is a tangential point (this post is not really about TUIs; sort of the opposite) and I think lots of people know it already but I only figured it out last week and so can't resist sharing it: agents are good at driving tmux, and with tmux as a "browser", can verify TUI layouts. So you can draw layouts like this and prompt Claude or Gemini with them, and get back working versions, which to me is space alien techn…
Would love to hear more about this approach.
It's actually really easy in Claude Code. Get a TUI to the point where it renders something, and get Claude to the point where it knows what you want to render (draw it in ASCII like this post proposes, for instance).
Then just prompt Claude to "use tmux to interact with and test the TUI rendering", prompt it through anything it gets hung up on (for instance, you might remind Claude that it can create a tmux pane with fixed size, or that tmux has a capture-pane feature to dump the contents of a view). Claude already knows a bunch about tmux.
Once it gets anything useful done, ask it to "write a subagent definition for a TUI tester that uses tmux to exercise a TUI and test its rendering, layout, and interaction behavior".
Save that subagent definition, and now Claude can do closed-loop visual and interactive testing of its own TUI development.
Re: ASCII-Driven Development
#37Welcome to the 1970s, when IBM published design guidelines that went along with the then-new 3270 terminal, including trying to keep response times very prompt (under a second) to prevent minds from wandering. This was supposed to allow non-technical users to use the full power of customers without having to master a command-line teletype style interface.
GUIs were supposed to the big huge thing that would let non-technical staff use computers without needing to grasp TUIs.
Re: ASCII-Driven Development
#38A really interesting article, and I'm likely to give it a shot a work. I'm grateful for it, and yet I found it difficult to get through because of a sense of "LLM style" in the prose. I won't speculate on whether the post is AI-written or whether the author has adopted quirks from LLM outputs into their own way of writing because it doesn't really matter. Something about this "feeling" in the writing causes me discom…
I've had too many LLMs tell me that software product ABC can do XYZ, but when I actually read the ABC documentation I discover that that hallucination was the opposite of reality: the docs say "we cannot do XYZ yet but we're working on it." So for me, the question at the back of my mind when I encounter an obviously LLM-generated article is always, "So which parts of this article are factually correct, and which part…
This is an ongoing problem for those of us who use LLMs every day. I have to check and recheck what it claims is possible.
Re: ASCII-Driven Development
#39I love it conceptually, but I can't get past the abject failure of the right edges of boxes to be properly aligned. Because of a mishmash of non-fixed-width characters (emoji, etc.), each line has a slightly different length and the right edges of boxes are a jagged mess and I can't see anything else until that's cleaned up.
Emojis mixed with ASCII-era characters are hard to get right. Some terminal emulators get it right nearly all the time (e.g. Ghostty, which has had a lot of thought and effort put into getting it right) and yet there are still open issues in the Ghostty repo about inconsistent character width. There are just so many corner cases that it's hard. That said, the edge alignment is, I believe, caused by the fact that LLMs…
They are treated like double width characters. All it takes is a Unicode aware layout algorithm that tracks double width codepoints. The tricky part is older single width symbols that were originally not emoji and now have ambiguous width depending on the terminal environment's default presentation mode.
Re: ASCII-Driven Development
#40Earlier quoted context omitted.
Emojis mixed with ASCII-era characters are hard to get right. Some terminal emulators get it right nearly all the time (e.g. Ghostty, which has had a lot of thought and effort put into getting it right) and yet there are still open issues in the Ghostty repo about inconsistent character width. There are just so many corner cases that it's hard. That said, the edge alignment is, I believe, caused by the fact that LLMs…
They are treated like double width characters. All it takes is a Unicode aware layout algorithm that tracks double width codepoints. The tricky part is older single width symbols that were originally not emoji and now have ambiguous width depending on the terminal environment's default presentation mode.
That's how it should work, and does in terminals that are doing it right. Browsers, however, are looking at the monospaced font and saying "Okay, Source Code Pro doesn't have the U+2192 codepoint," (the → arrow) "so let me find a font that does." On my Linux+Firefox setup, the browser chose Menlo to render the → in the "The fastest way to go from 0 → 1" banner. Menlo's width isn't quite identical to Source Code Pro, so the ┃ character on the right of the box was every so slightly misaligned. Because Firefox isn't following strict fixed-width layout rules, and is allowing itself to use other fonts with different horizontal widths even inside a
block. (I haven't looked at this article in other browsers but I bet they're the same since everyone's mentioning misalignment.)