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.

I'm confused, it looks like you've just written a new terse language that now costs money to compile?

Terse pseudo code > verbose prose

Coding Encoding Think about the terms

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!

I think "the pseudocode is persisted alongside the generated code" just reinvented jira/linear tickets and PR descriptions. We have ways of using git and tracing the code write to the thought process behind it.

What I find interesting about this + a random bucket of associations because I’ve fallen under the spell of Satan’s Lettuce:

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.

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.”

I think the idea of having a human-written persistent document describing the operation of the code is a great idea. This document acts as the prompting interface instead of the chat window and changes can still be tracked. Surely something as simple as a skill.md can be made for such a setup, right? I think the pseudocode style is a seperate axis to this setup.

Hmm. Interesting idea.

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?

Isn't this just spec-driven development in a different language?

curious if you’ve tried Kiro or spec-driven development? that seems like it would solve at least some of the issues you raised with agent based development, albeit in a different way without the emphasis on pseudo code

> There’s no reliable record of human intent.

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.

not sure if the hz file artifact is needed, you can enter pseudocode directly into chat or even on an existing code file and with minor comment agents will be able to work with it. i write this type of pseudocode to existing code files often to great results.

This is basically a compiler, but we’re moving up a layer of abstraction.

Are we supposed to be able to read the examples with our eyes? It looks like black text on a very dark grey background on my iPhone.

EDIT: same on Firefox on my Mac (macOS Ventura).

I just use a lot of folders, like folder for ever class and manager class with it and anything else. So its kind of organized by folders like plugins. Much easier to reason about. The biggest problem is the central class that glues everything is now 30 thousand lines, but its mostly repetitive delegation, init update, draw, delete. Still should be some nicer solution than having a huge class in center.

I'd call this one Micropilot.

As in micromanagement.

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.

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.

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.

[flagged]