Huzzah turns AI coding prompts into persistent pseudocode
A software engineer's Show HN post presents Huzzah, an experimental code editor built around a different way of prompting AI to write software. The author says the first months of 2026 felt like a honeymoon period once coding agents got good enough that manual coding was no longer necessary, but the novelty wore off: by August the author feels utterly fatigued with typing out lengthy English descriptions of every codebase change, while still not wanting to go back to writing all the code by hand. The stated goal is to keep the benefits of AI-generated code while regaining insight and control over its quality, and while still feeling good about the work as a professional.
The post lists three problems with today's coding agents. First, there is no reliable record of human intent: prompts get discarded, leaving no way to tell whether a given piece of code was written by a human or generated by AI. Second, AI chats are imperative, step-by-step instructions describing changes to an application rather than the application itself, so the same instructions are often repeated over a project's development, consuming tokens inefficiently. Third, natural language is largely built for social rather than informational purposes, so the average sentence carries little real information, which the author calls a cumbersome way to communicate with a machine.
Huzzah proposes an alternative: whereas coding-agent prompts are longform, imperative and transient, Huzzah's prompts are pseudocode, declarative and persistent. Instead of chatting with an agent, a developer writes a pseudocode representation of the program in a file with the .hz extension, for example fizz_buzz.hz, and saving the file makes Huzzah generate the corresponding real code automatically. The post's fizz buzz walkthrough starts with a loop hardcoded to 100 iterations that prints fizz for multiples of 3, buzz for multiples of 5, and fizz buzz for multiples of both; changing the pseudocode to take a number as input and loop that many times instead is enough of an edit for Huzzah to capture the diff, use it as the prompt to the LLM, and regenerate the affected source code. The post sketches two further examples in the same terse, declarative style: a shopping cart built from cart and inventory lists with add, remove and checkout operations, and a todo list built around a Todo record with add, toggle and remove operations.
The author lists several benefits of writing prompts this way: pseudocode reads as more terse and readable than longform prompts; writing it feels more like designing the shape of the code, which engages the mind; it can be written as tersely or as verbosely as the developer likes; and because a human wrote it to express their own intent, the pseudocode doubles as developer documentation. The author also suggests a language-agnostic pseudocode file could serve as the basis for generating the same logic across multiple programming languages or environments, citing complex algorithms such as CRDTs as an example.
The post is equally direct about the limits. The author admits the approach may run into problems at scale, is a better fit for new codebases than for existing ones, and is likely harder to use well without domain expertise, in which case natural language stays the easier route. Some things, like cross-file dependencies, may be difficult to express reliably in pseudocode, and Huzzah does not currently offer LSP-type editor features, though the author considers those plausible to add later. Huzzah is described as actively being developed and existing only in an experimental state; the source code and setup instructions are linked from the post, and the author invites readers to try it and share feedback.
Key facts
- Huzzah is an experimental code editor where a developer writes pseudocode in a file with the .hz extension, such as fizz_buzz.hz, and saving the file makes Huzzah generate the corresponding real source code.
- Editing that pseudocode file, instead of chatting with an agent, triggers Huzzah to capture the diff between old and new pseudocode and use it as the prompt to the LLM, regenerating the affected source code.
- The author built Huzzah after growing tired of retyping longform English instructions to coding agents, arguing that where agent prompts are longform, imperative and transient, Huzzah's pseudocode prompts are terser, declarative and persistent.
- Beyond the fizz buzz walkthrough, the post sketches a shopping cart (cart and inventory lists, add, remove and checkout operations) and a todo list (a Todo record with add, toggle and remove operations) in the same pseudocode style, and suggests a language-agnostic pseudocode could target multiple programming languages for complex algorithms such as CRDTs.
- The author flags real limits, including possible issues at scale, a better fit for new codebases than existing ones, harder-to-express cross-file dependencies, and no LSP-type editor features yet, while describing Huzzah as actively developed but still purely experimental, with source code and setup instructions linked from the post.
Why it matters
The post frames Huzzah as a response to three concrete problems the author has with AI coding agents: prompts are discarded, so there is no lasting record of why a piece of code exists or whether it was AI-written; agent chats give imperative, step-by-step instructions about changes rather than about the application itself, so the same ground gets covered again and again, burning tokens; and natural language, built mostly for social communication, is a low-information way to talk to a machine. Huzzah's answer is to make the prompt itself the artifact: a declarative pseudocode file that persists in the codebase, gets diffed like any other source file, and stands in as documentation of the developer's own intent. That reframes the interaction from a transient conversation into a durable, versionable representation of what the software is supposed to do, which is the idea the rest of the post works out through examples.
Who it affects
The audience is software engineers already relying on AI coding agents who have grown tired of re-explaining changes in longform natural language, especially on new projects where establishing a pseudocode structure from scratch is easier than retrofitting one onto an existing codebase. The author explicitly sets the approach aside for people who lack domain expertise, for whom natural language is called the easier route. Right now the direct audience is limited to whoever is willing to try an experimental, individually built editor: the post links to the source code and setup instructions and asks readers to test it and send feedback, rather than describing any existing user base.
How to use it
In practice, a developer creates a file with the .hz extension, such as fizz_buzz.hz, and writes a pseudocode description of the desired behavior in whatever style suits them; saving the file makes Huzzah generate the corresponding real source code automatically. To change the behavior, the developer edits that same pseudocode file rather than opening a chat; on save, Huzzah captures the diff between the old and new pseudocode and feeds it to the LLM as the prompt, and the affected source code is regenerated accordingly. The post's own example changes a fizz buzz function from a hardcoded 100-iteration loop to one that takes a number as input, which is enough of a diff to trigger regeneration; the same file-per-unit pattern is shown again in pseudocode sketches for a shopping cart and a todo list.
How solid is it
The evidence in the post is illustrative rather than empirical: one worked example, generating fizz buzz from a pseudocode file and then editing it, shown in full, plus two further pseudocode sketches, a shopping cart and a todo list, that are presented but not walked through step by step. The post gives no user count, download count, adoption figures, or benchmark or comparison data for Huzzah. The author's own caveats describe the approach as unproven at scale, calling it entirely possible that issues turn up as codebases grow, while noting it fits new codebases far better than existing ones, and describes Huzzah as actively being developed and existing only in an experimental state for now. The case for the approach, that it is terser, more documentation-like, and better preserves intent, rests on the author's own reasoning about the three problems it responds to and on the worked examples, not on any independent measurement or outside evaluation.
Risks and caveats
The author lists specific limits directly: the pseudocode approach may run into unspecified issues at scale, suits new codebases far better than existing ones, is likely harder to use well without domain expertise, and struggles with some patterns, cross-file dependencies among them. Huzzah currently has no LSP-type editor features such as autocomplete or inline errors, though the author considers adding them plausible. Beyond the author's own list, the post leaves several practical questions unanswered: it does not name the programming language the generated code targets, the LLM or provider behind the generation, any pricing or licensing terms, or a timeline for leaving the experimental stage, and the source code link in the post carries no URL, repository name or hosting platform in the text itself.
“I'm sick to death of writing longform English to describe every change I want to my codebase.”
— the author