Show HN: Huzzah – a novel approach to coding with AI (danielvaughn.dev)
I've been working almost exclusively with coding agents since January of this year, and over the past few months I began to feel utterly exhausted by them. They're great, but I'm finding it more and more tedious to write full sentences for every change I want. Not only that, but it seems there's a complexity limit for codebases - beyond a certain point the agent begins confusing itself.
I'd like to go back to writing code, but I don't want to go all the way back to fully manual coding. So I've come up with this interaction paradigm where you:
1. write pseudocode in whatever way makes the most sense to you
2. on save, the editor synchronizes your work to real source code
3. the pseudocode is persisted alongside the generated code, making your prompt effectively a stored record of intent.
Right now it's just a proof of concept - installation instructions are here in the readme: https://github.com/danielvaughn/hz
You can also watch a video of it in action here: https://x.com/danielvaughn/status/2090456808431165715
Cheers!
203 comments
[ 0.31 ms ] story [ 8.7 ms ] threadEDIT: same on Firefox on my Mac (macOS Ventura).
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!
At what point will you need formal rigid syntax? Or is not having rigid syntax the point? If the latter, how much "informational noise" or ambiguity can you inject before the "DSL compiler" gets confused?
Scaling is another bit. Convertible Psuedocode a great pattern for writing functions, but is it useful for writing modules? If you're writing a paragraph to change behavior of a function, you're underutilizing LLMs. Paragraphs are best for spec'ing modules, and the LLMs already fill in the blanks. Not sure if it would be faster to psuedocode the entire module (although maybe just the interface would be a sweet spot...)
My guess is that if you simply write `use some_fn from $repo/some/path`, the LLM _should_ be smart enough to infer in most cases. But we'll have to see how reliable that is.
With scale problems arise.
I think you should work on your differentiation. The session management stuff is the greater concern, in my opinion; pseudo code is not a novelty.
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.”
What about multi-file / larger changes? How would you express files being connected, imports, and exports? Or are you thinking the hz files are disposable per change?
I'll be looking into multi-file stuff soon - it's an interesting can of worms to think through.
After the last year, I feel like this sentence could replace half my outbound emails.
Fully manual coding is the most reliable but extremely slow and costly.
Fully LLM driven coding is extremely fast, but for serious work is too unreliable.
Spec-driven development might be viable, but too often the specs end up being LLM maintained, which defeats the purpose.
You need some hard boundary in the codebase where only human hands touch the files. And you want to enable the velocity that AI allows. So yes, semi-formal programming does seem like a promising solution.
You might think, well code is perfect. But code is syntactically perfect, because it has to be. Because compilers can handle very little ambiguity. But that doesn't mean it's a perfect representation of your thoughts. A huge part of language design is for the compiler, not for the author.
And I'm not 100% sure of this, but I'm fairly confident that this approach would be far more token efficient than the way we currently use AI for programming.
Helps me think about the problem, like your post mentioned, but I don't have to pay a tax on converting a prototyping language to a different language.
As in micromanagement.
Every engineer I have ever mentored got a lesson on how to write a good commit message that included this. This is exactly that.
Further Huzzah from skimming it over seems to be re-inventing documenting your code.
Together I can only surmise that the author is new out of school or has simply not yet worked on a team with good coding practices.
> Welcome to my Github! I'm a web engineer who's been building front-ends since 2009. Most of my work is either closed source or behind paywalls, but here is where I tinker on side projects in my spare time.
No need to dismiss the person - you can just say you don't like the approach
But before AI arrived on the scene, source code was a single artifact that directly expressed the intended behavior of a piece of software as it currently exists. After AI, the artifact is still there, but it's no longer the true record of human intent.
What the author is proposing has a long history of similar ideas: Literate Programming, UML modeling, DSL crazes, and now to LLM-generated abstractions. AI isn't special. They always fail in the same ways as basic "commenting your code". One can even argue that unit tests are a close cousin to this same problem. Taken one step further how is Huzzah better than just using property tests?
Just a few days ago someone was talking about a machine - human patois.
This (your project) sits somewhere between Lean and BDD cucumber syntax.
At the same time Claude spits out phrases like “a container paying the price of -42px”.
Recently I was listening to a lecture about metaphor in poetry, the misconception that poems are riddles whereas we use metaphors all the time in our language because they convey the meaning more precisely.
Also love the BDD reference - this is in fact an evolution of an earlier approach where I was trying to combine DDD event storming with Gherkin Rules. Very keen observation.
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.
Difficult! :(
The biggest issue is you end up leaning heavily on the quality of the model. Lower fidelity models tend to make a mess and add tech debt that you must frequently repay with intentional cleanup passes from a higher quality model, or else the rate of useful progress will fall off a cliff. At least that's my experience.
The fact that you don’t think this is particularly difficult makes me questions everything after that statement.
We all know how badly that failed once we started coming up with AI, and could outsource dealing with all that bullshit.
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. The exact opposite of what I was going for!
I didn't put much effort into it, maybe it was solvable with prompting (or more likely, more human effort on the spec phase), but it looks like the LLM has the same problem as the human, it can't know what the intention was, and it can't know what's relevant, what's essential and incidental.
But basically, what I needed wasn't a spec but user stories. (And probably multiple prototype outputs to choose from...)
I should definitely give it another crack though...
---
P.S., Spoiler for next ten years: software as biology (esp. crossbreeding, mutation, selection pressure...)
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.
https://ctx.company/blog/introducing-ctx-traits/
Coding Encoding Think about the terms
It's cool that with a tool like this you don't NEED to get all aspects of your code finalized and ready. It's possible to be vague when you want to and specific when you need to.
I'm not sure if that itself would work well in practice, but the project is still quite cool nonetheless.
Let's look at your fizzbuzz example. Unfortunately, if you wanted to have the agent implement fizzbuzz for you, it looks like, in your example, you would have to already know how to effectively write fizzbuzz. Specifically, you call out the use of the modulo.
In your prompt, for the traditional agentic development path, you already declared the intent. There is some imperative language in there, sure, "Create a function that ...", but also there is the declarative state, that doesn't require knowledge of specific programming syntax or semantics.
What I've relied on is a more formal location/syntax for acceptance criteria are in code. These are then used to generate tests, and implementations. It isn't perfect, and more investment is needed, but it starts getting at the root of the problem.