An LLM writes a Bubble Tea app - go build decides whether it counts (teatest next?)

[in5devilinspace]

I built a small generator with a Bubble Tea twist: it studies this repo, has an LLM write an original Bubble Tea program — and refuses to call the result "done" unless it compiles.

The pipeline: shallow-clone a TUI repo → detect the framework with plain heuristics (extension counts + import grep; a tree full of .go files importing charmbracelet/bubbletea reads as Bubble Tea — no AI in that step) → feed the README plus a few key source files to Claude → ask for an original program following the Model/Update/View structure → gate the output on go mod tidy && go build ./.... If it doesn't compile, the run fails.

The committed example it produced is a little Pomodoro timer, checked in verbatim: https://github.com/in5devilinspace/tui-master-agent/tree/main/examples/bubbletea (repo README has an uncut demo recording of the full pipeline).

What struck me building this: the Elm architecture is remarkably LLM-friendly. The Model/Update/View shape gives the model a rigid skeleton to fill in, and most of what compilation catches is exactly the failure mode I worried about — plausible-looking code referencing an API that doesn't exist.

A question for people deeper in the ecosystem: is go build an honest enough "it works" bar for generated Bubble Tea, or does the interesting breakage live downstream — Update loops that never quit, blocking tea.Cmds? I've been eyeing teatest for driving the generated programs headless the way I drive generated Textual apps through their run_test() pilot. If anyone has a pattern for asserting "this program runs and quits cleanly" without a human at the terminal, I'd love to steal it.

(Backstory, if you're curious — the project sat dead as a spec for 4.5 months before a deadline forced a scope-down: https://dev.to/matt_b650aa89776af88513ae/i-scoped-a-multi-agent-tui-system-in-january-it-sat-dead-for-4-months-here-is-the-comeback-jp8)