ASCII-Driven Development
medium.com
ASCII-Driven Development
1–10 of 97 posts
Re: ASCII-Driven Development
#2Nice !
Very true that if you, for example, show a group a button with a given color, they will waste the meeting discussing the color and not what the button should do, so ASCII is a nice way to not have to do that.
Re: ASCII-Driven Development
#3This 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 technology.
Re: ASCII-Driven Development
#4It is news to me that manipulating ASCII art is something AI can do well! I remember this being something LLMs were all particularly horrible at. But I just checked and it seems to work at least with Opus 4.5.
claude(1) with Opus 4.5 seems to be able to take the examples in that article, and handle things like "collapse the sidebar" or "show me what it looks like with an open modal" or "swap the order of the second and third rows". I remember not long ago you'd get back UI mojibake if you asked for this.
Goes to show you really can't rest on your laurels for longer than 3 months with these tools.
Re: ASCII-Driven Development
#5Like the idea, but this is definitely Unicode and not ASCII. It's hard to believe someone finished a piece of this length but still misunderstood, especially when some examples have emoji in them. Alternately, they chose a misleading name on purpose. Why? Someone mentioned TUI, which sidesteps the issue entirely.
Re: ASCII-Driven Development
#6Author 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 → generate ASCII → iterate on structure/states → feed into v0/Lovable/Bolt/etc → polish visuals last
It also facilitates discussion:
- everyone argues about structure/decisions, not pixels
- feedback is concrete (“move this”, “add a section”), not subjective
More advanced setups could integrate user/customer support feedback to automatically propose changes to a spec or PRD, enabling downstream tasks to later produce PRs.
Re: ASCII-Driven Development
#7Neat concept and very inspirational.
Is ascii/unicode text UI the way to go here or is there other UI formats even more suited for LLMs?
Re: ASCII-Driven Development
#8This 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…
Yeah, text was king yesterday, will be tomorrow
Re: ASCII-Driven Development
#9Author 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…
While I agree a text representation is good for working with LLMs... most of the examples are mis-aligned?
Even the very first one (ASCII-Driven Development) which is just a list.
I guess this is a nitpick that could be disregarded as irrelevant since the basic structure is still communicated.
Re: ASCII-Driven Development
#10Like the idea, but this is definitely Unicode and not ASCII. It's hard to believe someone finished a piece of this length but still misunderstood, especially when some examples have emoji in them. Alternately, they chose a misleading name on purpose. Why? Someone mentioned TUI, which sidesteps the issue entirely.
You're technically right, but I think that's a minor quibble. They could have indeed limited it to ASCII (7-bit if you really want to be a purist) and everything would still work just as well.