Huzzah - A novel approach to coding with AI
Show HN: Huzzah – a novel approach to coding with AI
Huzzah is an experimental editor that offers a new paradigm for working with LLMs. Instead of writing longform, imperative prompts that are discarded after use, you write terse, declarative pseudocode that persists as the source of truth. This pseudocode acts as both the prompt and documentation, and Huzzah automatically generates real code from it. It's a more efficient, readable, and controllable way to leverage AI for coding, giving you the benefits of AI assistance without losing insight or control over your codebase.
With Huzzah, prompts are pseudocode, declarative, and persistent—giving you a reliable record of human intent and a more efficient way to work with AI.
- reticulates
I think you’re probably missing why it’s exhausting. The problem is not writing English, it’s the rate of change. Programming is meditative, it is a thinking process, the code you output is an artifact of your thinking. Agent-based development… there is no thinking, no meditation, you’re delegating the thinking to a machine, you’re just barking what you want at it, incessantly, endlessly.
For businesses it makes sense to abandon programming in favor of delegating to agents that can do more in less time, but for programmers, it is a loss. Either be a programmer and code, or be a delegator and delegate, you aren’t going to make the life of a delegator suck any less by trying to trick yourself into thinking you’re programming.
- avaer
I think the reverse direction is more important: taking a massive complex problem/codebase and decomposing it to short pseudocode. Then you could edit the pseudocode and compile it back into the system.
That's the way software engineers working on large projects work anyway: you first gather context on the state of the system and read it at a level you can understand. Then you propose a change on the simplified representation, and then holistically update the machine-runnable format ("implementation").
I'd be interested in tools that formalize/automate this process more.
- quasarj
I'm confused, it looks like you've just written a new terse language that now costs money to compile?
- smicallef
I’ve been thinking about something along these lines for some time. I really like the direction of this.
The challenge I see more broadly is we (as engineers now empowered by LLMs) are trying to find the right level of abstraction to operate in. Writing long form sentences and (sometime) reviewing the output feels too far away. But having an LLM work directly with you in an IDE feels too close to “the old way”.
Personally for me the approach here still feels a little too close to the lower level old way, but it’s better than the two approaches above.
Excited to see where you take it!
- broken-kebab
As I see it, there's a bit of internal contradiction: your declared intent is to not write code, but you had to circle back to code (albeit more relaxed and vague) because human English is (compared to proglangs) imprecise. Pseudocode, however, is not far away from it, still not strict, and LLM is still a stochastic generator. So it will continue to randomly deviate from what you want it to do. I guess it could be an enhancement, but who knows, maybe in a year from now, you will get tired with pseudocode not being precise, and go back to writing code :wink:
- amemi
It is useful to know the level of how "hands-off" to specify directions for each task. With some experience one can learn when to specify the high level requirements, and when to stop and think about the problem at hand.
For example, with frontend, I can get an LLM to design half a page 80% to my satisfaction with two paragraphs worth of a prompt. "It should look like so, and have a text box here, and room for a demo there".
With ML training or backend or user-facing code, I might instead spend a paragraph thinking out my design intentions for a single function or even a single line, more for myself than the LLM. A harness generates a plan based on that paragraph, which one can then comment on and review the pseudocode it provided, ensuring it aligns with expectations.
Lastly have the LLM output some sort of documentation and "here's what I did" after each change. Your final step is to handwrite (paraphrasing what it gave) into any docs or commit messages, and ensure your commits are small enough to keep this maintainable. Paraphrasing the LLM, rather than the LLM paraphrasing you, is helpful to ensure the commit messages make sense to you three months from now.
- wyum
I'm not sold on the pseudocode approach, but I agree with the declarative aspect. Declarative specs have become central to my process and I've built this tool to support it:
https://github.com/spekk-ai/spekk-cli
Rather than writing exhaustive specs, I preserve only the intent and what must be true as discrete assertions. This preserves the leverage you get from LLMs - anything it can reliably infer does not need to be specified. It also (mostly) separates intent from code or architecture decisions, which keeps specs flexible.
- leobg
Dumb question:
Why not just put an instruction into your favorite harness’ system prompt: “If I give you pseudo code, spell out my intent, and then write and test it in real code.”