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.
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.
You install a fancy chrome extension or custom browser.
You go through the app on this browser. You notice something you want to change. You can then submit a prompt via this extension saying the change you want.
The trick is, the chrome extension has been following your movements through the app. This way the chrome extension can generate a lot of data the AI can use for a good prompt. I.e. The extension can get a screenshot of where you are in the app and all the pages you went through to get there. The extension can get the console logs and traces and stuff.
So with all this, the AI system gets all the material needed for a good prompt to make a good change.
In an ideal world, the AI system could then save all these details and when the change is made, guide you through the UX again. And you can check if the change was made as you wanted.
So kinda like AI flavored manual UX testing where you click around and record your findings.
Though catching back up on that project- it seems it's evolved pretty substantially, becoming much higher level than the initial pseudocode driven version I remember
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.
I'm not totally convinced this is a useful way to express something like "Change the data flow so that we bulk query from the DB upfront and pass it down to all callsites"
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.
Sometimes you might also want examples and then BDD testing software (like Yadda) might make sense?
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.”
The issue is that with very large or complex codebases, you tend to forget what was AI generated and what was written by a human. And it's also extremely tedious and difficult to read AI generated code. So if you want to _understand_ a complex bit of code, the natural tendency is to ask an agent to summarize it for you. This can work but also has lots of problems.
What you really want is a system that persists both your written intent, and the actual source code. And you want to provide a source map between them, so that you can understand which bits of human pseudocode are responsible for which bits of generated code.
The real value is in persisting your expressed intent.
I think it will be interesting to see how this plays out when it comes time to debug.
At that time, someone else may be reading my pseudo code and implicitly assuming that the code was translated correctly. If the code wasn't translated correctly, wouldn't the human who naturally assumes it was miss the bug every time?
Huzzah would benefit from having a guard identify pseudo code with two potential interpretations and ask the human to clarify so the reliability of the interpretation does not suffer.
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.
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.
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.
Nice work.
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.
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.
> 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
EDIT: same on Firefox on my Mac (macOS Ventura).
I wrote this but as a compiler. It was ~2 years ago and local models have gotten WAY better; I was having too many issues with adherence (syntax errors, etc) and dropped it.
The compiler comes with a model embedded or can use an external model. It uses Cosmopolitan Libc and can zip things together into one binary. I will take some time to dust it off and share it.
But the idea was basically, you have your natural language source files or a one-shot prompt and it "compiles" them into a single, shareable fat binary that works across all popular platforms and architectures.
It was pretty fun to use with remote frontier models but the local model story simply wasn't good enough at the time for me to feel proud releasing it. I think that's probably changed now and passable results can be had even with small modern 7B/14B models.
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.
You can already retrieve the session associated with a given line of 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.