August 2026
A new experimental way to code with AI
If you’re a software engineer like me, the first few months of 2026 were incredible. Coding agents suddenly became good enough that we no longer needed to manually write code. But if you’re like me, then sometime later you hit a wall. The honeymoon period ended, and the novelty wore off. No more dopamine hits.
It’s August, and I feel utterly fatigued. To be honest, I’m sick to death of writing longform English to describe every change I want to my codebase. However, I also don’t want to go back to writing all my code manually. There was real tedium in that practice that I’d prefer to avoid for…well, the rest of my life.
And yet, I sense that I need to have better insight and control over what my code is doing. I want to know that my output is high quality, reliable software. I want to feel good about myself as a professional. So I’m trying to find a way to have my cake and eat it too.
My problem with coding agents is that
- There’s no reliable record of human intent. Prompts are discarded, and the code may or may not have been generated by AI. We’ve lost the central authority that expresses what the human wants out of the machine, and I think it’s important to contend with that fact.
- AI chats are imperative, step-by-step instructions that describe changes to the application, not the application itself. This means instructions are often repeated, and thus consume tokens, many times over the course of development. This is inefficient.
- Much of natural language exists for social reasons, not informational. The average sentence is scarce in real information. Writing in this manner, to a machine, is cumbersome.
To address these problems, I’m building an experimental editor. I’m calling it Huzzah, and it poses an alternative paradigm for working with LLMs.
With coding agents, prompts are (a) longform, (b) imperative, and (c) transient. With Huzzah, prompts are (a) pseudocode, (b) declarative, and (c) persistent.
It’s easier if I just show you.
Comparing fizz buzz
Let’s take a very simple example - say you want to use AI to create fizz buzz. We’ll do this twice - once with coding agents and another with Huzzah.
With coding agents
You start a chat in your tool of choice, and type something like the following:
Create a function that loops 100 times. If the number is divisible by 3, print “fizz”. If the number is divisible by 5, print “buzz”. If the number is divisible by both (like 15 for example), print “fizz buzz”.
If you need to make an edit, you’d send a follow up message to the chat:
Instead of looping 100 times, the function should take a number input and the function should loop that amount of times.
You repeat this process until you’re satisfied.
With Huzzah
You create a new file called fizz_buzz.hz.
In it, you write a pseudocode representation, however you like.
This is how I’d do it, personally:
fizz_buzz()
loop 100
modulo 3 ? "fizz"
5 ? "buzz"
both ? "fizz buzz" You save the file, and Huzzah automatically generates real code from it.
If you need to make an edit, simply update your file:
fizz_buzz(n)
loop n
modulo 3 ? "fizz"
5 ? "buzz"
both ? "fizz buzz" When you save the file, Huzzah captures the diff and uses it as the prompt to the LLM. The affected source code is thus regenerated.
Some other examples
To give you a better sense for what this could look like in other scenarios, here are some alternative examples.
1. Shopping cart
list cart
list inventory
mock_data = // include some mock data
init()
inventory.fill(mock_data)
add_item(id)
cart.add(item by id)
remove_item(id)
cart.filter(item by id)
checkout()
return cart.sum(item by price) and format as price 2. Todo List
Todo {
id: int
text: str
completed: bool
}
add_todo(text)
todos.add(text, completed = false)
toggle_todo(id)
todo = todos.get by id
todo.completed = NOT .completed
remove_todo(id)
todos.filter by id Benefits
You should be able to see some benefits already. Notice how much more terse and readable the pseudocode is than the longform prompts? Here are some more:
- Writing prompts this way engages your mind, because it feels much more like you’re designing the shape of the code.
- You can be as terse or as verbose as you like.
- The pseudocode acts as developer documentation because a human wrote it to express their intent.
- You could write a language agnostic pseudocode and use it as the basis for multiple language or environmental targets. Think complex algorithms, like a CRDT.
Caveats
There are no silver bullets, of course. Some exceptions:
- It’s entirely possible that there are issues with this approach at scale.
- This is obviously more ideal for new codebases than existing ones.
- If you lack domain expertise, natural language is probably the easier interaction method.
- Some things may be more difficult to reliably express, like cross-file dependencies.
- LSP-type features would not be available (though this could plausibly be generated).
Current state
Huzzah is actively being developed, and exists only in an experimental state for now. You can find the source code and setup instructions here. Please give it a spin and let me know what you think!
Cheers.