[HN Gopher] ASCII-Driven Development
___________________________________________________________________
ASCII-Driven Development
Author : _hfqa
Score : 66 points
Date : 2026-01-08 08:18 UTC (2 days ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| damnitbuilds wrote:
| Nice ! 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.
| tptacek wrote:
| This 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.
| heliumtera wrote:
| Yeah, text was king yesterday, will be tomorrow
| eterps wrote:
| Would love to hear more about this approach.
| tptacek wrote:
| 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.
| ucarion wrote:
| It 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.
| mixmastamyk wrote:
| Like 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.
| kmoser wrote:
| 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.
| ehsanu1 wrote:
| It kind of makes sense if you relate it to ASCII art, which is
| very often not ASCII for similar reasons. The naming evokes
| that concept for me at least. Naming is hard in general, I'm
| sure they tried to find a name that they thought worked best.
|
| I agree that "TUI" is a better fit though. But not TUI-driven-
| development, more like TUI-driven-design, followed by using the
| textual design as a spec (i.e. spec-driven development) to
| drive GUI implementation via coding agents.
| _hfqa wrote:
| Author 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.
| 4b11b4 wrote:
| 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.
| NetOpWibby wrote:
| 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.
| jlundberg wrote:
| Neat 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?
| kmoser wrote:
| LLMs are surprisingly good at extracting data from other data,
| so at the end of the day there is no right or wrong, it's what
| works best for you use case.
| ehsanu1 wrote:
| It has to be suited for human consumption too though.
|
| I wonder if this has any real benefits over just doing very
| simple html wireframing with highly constrained css, which is
| readily renderable for human consumption. I guess pure text
| makes it easier to ignore many stylistic factors as they are
| harder to represent if not impossible. But I'm sure that LLMs
| have a lot more training data on html/css, and I'd expect them
| to easily follow instructions to produce html/css for a
| mockup/wireframe.
| sbondaryev wrote:
| Great idea, thanks for sharing! Tried your prompts with ChatGPT
| and Claude than iterated on it. The ASCII doesn't render
| perfectly in the web interface but looks good when copy/pasted
| into a text editor. Key benefit: I used to iterate on layout by
| generating HTML+Tailwind directly, which burns tokens fast. This
| ASCII approach lets you nail the structure first without the
| token cost. Much better for free tier usage. Appreciate the
| writeup!
| killerstorm wrote:
| OK but why not just go back to Balsamiq and make it 'executable'?
|
| You might believe that TUI is neutral, but it really isn't -
| there's a bajillion of different ways to make a TUI / CLI.
| arglebarnacle wrote:
| A 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 discomfort, and I don't even
| really know why. It's almost like a tightness in my jaw or a
| slight ache in my molars.
|
| Every time I read something like, "Not as an aesthetic choice.
| Not as nostalgia. *But as a thinking tool*" in an article I had
| until then taken on faith was produced in the voice of a human
| being feels like a let down. Maybe it's just the sense that I
| believed I was connecting with another person, albeit indirectly,
| and then I feel the loss of that. But that's not entirely
| convincing, because I genuinely found the points this article was
| making interesting, and no doubt they came originally from the
| author's mind.
|
| Since this is happening more and more, I'd be interested to hear
| what others' experiences with encountering LLM-seeming blog posts
| (especially of inherently interesting underlying content) has
| been like.
| iamanllm wrote:
| "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.
| oasisbob wrote:
| 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.
| rmunn wrote:
| 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 parts are
| hallucinations?" I care less about the "human voice" aspect
| than about the factual correctness of the technical facts
| presented in the article.
|
| In this particular case, if the facts about how many years ago
| various products came out are wrong, it doesn't matter since
| I'm never going to be relying on that fact anyway. The fact
| that what the author is proposing isn't ASCII, it's
| UTF-8-encoded Unicode (emojis aren't ASCII) doesn't matter (and
| I rather suspect that this particular factual error would have
| been present even if he had written the text entirely by hand
| with no LLM input), because again, I'm not going to be relying
| on that fact for anything. The _idea_ he presents is
| interesting, and is obviously possible.
|
| So I care less about the "voice" of an article, but a LOT about
| its accuracy.
| trollbridge wrote:
| 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.
| bccdee wrote:
| Trouble with this is, it's pretty much LLM-only. I don't want to
| type out a request for Clause to draw a box for me and describe
| where, and I don't want to be pasting box-drawing characters. I
| want to click & drag. This is just boxes, arrows, and labels,
| which are all WAY faster to make by hand.
| ftr1200 wrote:
| What tools can we actually use to draw ASCII manually if desired?
|
| None are mentioned. E.g I made https://cascii.app for exactly
| this purpose.
| majkinetor wrote:
| plantuml
| jph wrote:
| Monodraw for Mac is my favorite. I'm a customer. $10 license.
| https://monodraw.helftone.com/
| layer8 wrote:
| > Examples: UIs in ASCII
|
| The examples are using non-ASCII characters. They also don't
| render with a consistent grid on all (any?) browsers.
|
| Maybe they meant plain-text-driven development?
| nihiven wrote:
| I like to make these kinds of mock ups using
| https://asciiflow.com. Some of the components from the article
| paste nicely there.
| ftr1200 wrote:
| https://cascii.app many more features :)
| theturtle32 wrote:
| I 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.
| rmunn wrote:
| 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 are involved in the process. Because the LLMs
| never "see" the final visual representation that humans see.
| Their "view" of the world is text-based, and in the text file,
| those columns line up because they have the same number of
| UTF-8 codepoints in the row. So the LLMs do not realize that
| the right edges are misaligned visually. (And since the
| workflow described is for an LLM to take that text file as
| input and produce an output in React/Vue/Svelte/whatever, the
| visual alignment of the text file _needs_ to stay LLM-oriented
| for it to work properly. I assume, of course, since I haven 't
| tried this myself).
| kevin_thibedeau wrote:
| 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.
| rmunn wrote:
| 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 <pre> block. (I haven't looked at this
| article in other browsers but I bet they're the same since
| everyone's mentioning misalignment.)
| sedatk wrote:
| Off-topic but I'm so happy to have moved out of Medium.
| drob518 wrote:
| I really like this idea. I've seen teams get stuck quibbling
| about details too early while using Figma. I see how this totally
| sidesteps that problem, similar to working with analog drawings,
| but with the advantage that it's still electronic so you can
| stuff it into your repo and version it and also feed it into an
| LLM easily. I'm really curious how the LLM "sees" it. Sure, it's
| characters, but it's not language. Regardless, very cool idea.
| Can't wait to give it a try.
| ivanjermakov wrote:
| Wide character width is yet another billion dollar mistake.
| Impossible to make emojis look right together with monospaced
| font across devices/programs.
| bulletsvshumans wrote:
| 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.
| trollbridge wrote:
| Welcome 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.
| cjlm wrote:
| Spending a lot of time building tools inspired by and using ASCII
| nowadays...
|
| graph-easy.online printscii.com
___________________________________________________________________
(page generated 2026-01-10 23:00 UTC)