Show HN: Huzzah – a novel approach to coding with AI

Posted by danielvaughn 2 hours ago

Show HN: Huzzah – a novel approach to coding with AI(www.danielvaughn.dev)

Hello everyone. I've been working on this experimental editor called Huzzah.

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.

It may not work for every use case, but in my initial playthroughs I've found it very enjoyable.

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!

50 points | 24 commentspage 2

apex_sloth 1 hour ago|

Definitely an approach worth exploring! I actually started to look into semi formal spec language like Quint because I wanted something more structured then prose, so I feel like this goes into the right direction.

paretolaw 1 hour ago||

Writing fizzbuzz requires that you understand algo + you credit card, while agent requires only your credit card. I believe most of people will pick the 2nd one.

danielvaughn 1 hour ago|

Yes for many non-technical people who are building stuff for the very first time, this is absolutely true. Natural language will always be easier for them. But experienced engineers are wanting to use AI for very complex codebases, and AI struggles significantly beyond a certain point.

paretolaw 1 hour ago||

Would need to try out in a complex project to have opinion. However I already see few problems. Slower development due this loop of generating code from you mini spec. I would snap and start writing code at one moment. Different agent different code, off by one errors that agent deducts itself, and you miss because spec doesn't force you to write correct code. Those might be caught by unit tests, but then why not generate code based on tests, as uncle Bob does...

With scale problems arise.

esafak 1 hour ago||

You seem to be conflating two things: how to prompt, and how to share sessions. You can already use pseudo-code today if you want to. As for sharing, you can commit (a link to) it, use `git notes` (as I do), or a service like entire.io.

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.

danielvaughn 1 hour ago||

Help me understand - what do you mean be "share sessions"? And yes you can definitely use pseudo code today - that in and of itself is not a novelty at all. The specific novelty is the fact that the editor assumes two equivalent sources - your pseudocode which acts as a prompt, and the source code generated from that prompt. The editor also provides a source map for the two, so that as a codebase grows in size and complexity, it's trivial to link a specific section of code back to a human's written intent.

esafak 1 hour ago||

Sharing sessions means providing full visibility into what you did with the agent to the team. See https://entire.io/ or https://usegitai.com/

You can already retrieve the session associated with a given line of code.

danielvaughn 1 hour ago||

I see, thank you. So the difference in this case is that you're effectively writing very terse documentation. If I as a human interpreter want to understand why a range of code came into existence, I'm very unlikely to want to read another engineer's session. I'd have no way of knowing how far back into the session to read - some conversations can be very complicated. It also requires persisting everyone's sessions, which I'm sure is a pretty pricey problem. The truth is that for a given chat session, the messages themselves aren't extremely valuable, because they're part of the working development of the code.

What I'm after is a condensed distillation of human intent using semi-formal symbolic language, which should be vastly easier to read and understand for engineers and teams.

promptspheree 1 hour ago|

[flagged]