Show HN: Huzzah – a novel approach to coding with AI
TL;DR
Daniel Vaughn got tired of prompting coding agents in long English sentences. He built Huzzah, an experimental editor where an LLM regenerates real code from freeform pseudocode on every save. The pseudocode stays in the repo as a human-written record of intent, mapped line by line to the code it produced.
The article
- Coding agents got good enough in early 2026 that Vaughn stopped writing code by hand. By August he was sick of writing longform English for every change. He still doesn't want to go back to writing every line himself.
- Vaughn names three problems with agent chats. Prompts get thrown away, leaving no record of what the human wanted. Chat messages describe changes to the app, not the app itself. The same instructions get repeated and cost tokens each time. Most natural language also carries social padding, not information.
- Huzzah flips each property: prompts become pseudocode instead of prose, declarative instead of step-by-step, and persistent instead of transient. You write a .hz file in whatever notation you like. On save, the editor sends the diff to the LLM, which regenerates only the affected code.
- His fizz buzz, shopping cart and todo-list examples are a few terse lines each. The same fizz buzz in a chat agent took a paragraph of prompt plus follow-up messages.
- Vaughn claims the pseudocode keeps the developer engaged in designing the code. It doubles as documentation written by a human. One language-agnostic source could also target several languages.
- Vaughn lists the caveats himself. The approach may not hold up at scale, and it suits new codebases better than old ones. People without domain expertise are better off with natural language. Cross-file dependencies are hard to express, and there is no LSP support.
Why it matters
Read the original for the demo video and the side-by-side examples, which show what freeform pseudocode looks like in practice. The post doesn't mention the source map. Vaughn explains it only in the comments, and calls it the part that sets Huzzah apart.
The discussion
A busy and split thread. Its top thread ignored Huzzah and argued over why agent coding is exhausting and whether it still counts as programming. Most of the rest asked how Huzzah differs from existing tools, and Vaughn gave dozens of replies with one answer: persisted, source-mapped human intent.
Why agent coding wears people out
The top comment says the problem isn't typing English. Agents take away the thinking that made programming satisfying, and no pseudocode trick will bring it back. Others replied that agent work is still thinking, of a manager's kind: architecture, review and planning, which many programmers are bad at and find draining. A third camp said fundamentals matter less if agents plan and review their own work, and Vaughn said this breaks badly beyond CRUD apps.
Programming is meditative, it is a thinking process, the code you output is an artifact of your thinking.
For many people who went in programming thats not their strong suite and hence is really exhausting. Instead of living in the code you are managing the code and using a part of the brain you are not good at.
Isn't this just an old idea?
Commenters matched Huzzah to spec-driven development, BDD with Gherkin, Code Complete's Program Design Language, literate programming, UML, transpilers and Python itself. The sharper objection: precise pseudocode calls for a deterministic compiler, and vague pseudocode leaves the LLM making decisions for you. Vaughn answered that compilers force authors to write for the machine, while pseudocode lets them choose how precise to be. He said Gherkin specs and spec-driven development failed for him because nothing tied the specs to the code.
If the pseudocode is precise, what you want is a compiler. Otherwise the LLM is still making decisions for you.
We're reinventing a domain that has had decades of research into it using an expensive, slow, stochastic black box.
A human-only record of intent
Vaughn kept pointing to two features: the .hz files persist, and the editor maps each pseudocode line to the code it generated. Commit messages, tickets and PR descriptions record changes, he said, while the pseudocode describes what the app should be now. His rule is that only humans edit it, and he told one commenter not to have an agent rewrite the pseudocode for big changes. Several liked it, one would trust a vibe-coded library more with readable intent, and skeptics expected it to go stale like comments.
I came to the conclusion that *something* in the codebase needs a hard boundary, where the team agrees that *only human hands* touch it. Otherwise the entire repo becomes untrustworthy as far as discovering intent goes.
Plus, it'll go stale as quickly as comments do.
Does it scale past fizz buzz?
Commenters asked about cross-file changes and abstract instructions, such as bulk-querying the DB up front and passing results to every call site. Vaughn said the multi-file case stays untested until a desktop version with filesystem access exists. One commenter wanted the reverse, distilling a big codebase into pseudocode to edit. Another got bloated results round-tripping code through an LLM-written spec, which Vaughn said matched his own experience and partly motivated Huzzah.
The results were disgusting: the spec would encode all sorts of irrelevant implementation details, and then the new version would reimplement them faithfully, *and* be 3x more bloated than the original.
If you're working on a larger code base with knock-on effects, you can't express it in pseudocode -- unless you maintain a whole "pseudocode twin" of your codebase, which seems like a lot of extra work.
Why not just prompt, or just code?
Many asked why you'd need a dedicated editor when any agent accepts pasted pseudocode, or why not write real code if you can write pseudocode. Others said Huzzah gives up the agent proposing a better approach, finding where a change belongs in a large codebase, and brainstorming design in chat. Vaughn agreed that chat still helps for rubber-ducking, and said he had pasted pseudocode into Cursor before. What Huzzah adds, he said, is keeping the prompt and tying it to the exact code.
I mean if you can write pseudocode then just code it yourself, very often that would be almost the same number of tokens/lines
It has two problems though: if my approach has flaws the agent would implement it as-is even if could instead suggest an improvement.
Consensus
Most agreed the problem is real. Chat prompts disappear, LLM-generated code is hard to read, and a human should write down what the code is for. Even the critics mostly liked keeping a durable record of intent.
Dissent
Many argued that pseudocode adds little. Either it is precise enough to compile without an LLM, or vague enough that the LLM still guesses. Prompting, specs, BDD, commit messages and literate programming already cover the same ground.