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.

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!

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

There are good reasons for doing this: I might want to write something in Ruby (the way I think about problems might fit that language best), but might want the artefact I check in to be Python (my colleagues might prefer it), and my build pipeline might want to transpile it into C, and then throw it through a compiler with a pile of optimisations to make it all scream at 100x the performance my original code could run in, in Ruby.

Hell, why not make the Ruby interpreter just a call out to an LLM to get it turned into byte code?

Of course this is all starting to sound a little absurd because it is. We're reinventing a domain that has had decades of research into it using an expensive, slow, stochastic black box.

Where there's some utility is in a language where I can be a little vague, but that doesn't have all the semantic confusion of natural language. But without defining that as a formal grammar (and therefore implementable in LLVM, JVM, whatever), you may end up with the worst of both Worlds.

https://github.com/spekk-ai/spekk-cli

Rather than writing exhaustive specs, I preserve only the intent and what must be true as discrete assertions. This preserves the leverage you get from LLMs - anything it can reliably infer does not need to be specified. It also (mostly) separates intent from code or architecture decisions, which keeps specs flexible.

Lately I've been dreaming about a way of using LLMs that never (or in majority of the cases) results in chatting with an agent or checking its traces. Instead, you provide prompts in natural language, e.g. refactor these modules in this way ..., and the result is shown as a visual proposal (some kind of diff on a graph). Then you can select a region and provide another prompt like "this goes there instead". The raw prompt + visual markup is compiled to LLM insructions which results in another set of visual changes.

These changes can all be virtual (i.e. "plan mode"), until you are happy with them, at which point you press a button, which compiles the change to a fresh prompt which runs the implementation. And so on.

I.e. forget the idea that you have a "copilot" whose output tokens represent reasoning you can discuss, instead you have a black box which compiles your instructions to a visual markup on which you can iterate. Zoom into the nitty-gritty as required, and so on.

It makes sense if you want to sell a dream that now everyone can become developer and it is cool that non-tech people can now generate todo apps tailored for they own use. But when working on complex project, that is used by real paying customers you need to be responsible for the code you are producing no matter if it was written by AI or by hand.

Thats why i think we would be better with deep integration with IDEs instead of having separate window I need to alt-tab to to do something. I really liked first approaches (IIRC first release of Copilot worked like that) where you put comment inside code describing what function you need and AI would just fill it in. That way developer is still in charge of what is happening. For bigger tasks create new file and describe what should be happening and let AI go wild with it, splitting work into more files as needed.

Currently Jetbrains kinda supports that flow but it is clear that it is not their main focus, so I find it kinda lacking.

Although I like your direction, i would hate to see this become yet another programming language.

Also if your pseudocode has a definitive structure, why not write an interpreter or compiler ? And not waste AI cost? Like how traditional BDD stack works gherkin and cucumber and the likes?

Direction, I love. Approach, we can always change. Peace

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

For example, with frontend, I can get an LLM to design half a page 80% to my satisfaction with two paragraphs worth of a prompt. "It should look like so, and have a text box here, and room for a demo there".

With ML training or backend or user-facing code, I might instead spend a paragraph thinking out my design intentions for a single function or even a single line, more for myself than the LLM. A harness generates a plan based on that paragraph, which one can then comment on and review the pseudocode it provided, ensuring it aligns with expectations.

Lastly have the LLM output some sort of documentation and "here's what I did" after each change. Your final step is to handwrite (paraphrasing what it gave) into any docs or commit messages, and ensure your commits are small enough to keep this maintainable. Paraphrasing the LLM, rather than the LLM paraphrasing you, is helpful to ensure the commit messages make sense to you three months from now.

My project is a rich text editor SDK, with a considerable amount of code. AI tools are indeed very useful for writing glue code and generating boilerplate code. However, when faced with complex cross-browser compatibility issues (such as parsing mso-* CSS pasted from Word), AI is basically useless; I still have to understand the problem domain and write the code manually.

The idea of converting pseudocode to source code is interesting. The key is whether the pseudocode can clearly express the intent—if the intent itself is complex, the pseudocode may not be much shorter than the actual code.

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"

I love that you are trying something and you shared it, I relate very much to some parts of the post minus the fatigue part maybe I am it's because I am a very chatty person in general so prompting is not a problem who knows!

I had my own attempts to improve working with AI but to my fault I rarely commit to a project no matter if I wrote it or AI wrote it for me!

I tried this over a year ago https://github.com/ramigb/promachos (before I found out about spec kit and similar solutions) Then I tried this https://github.com/ramigb/groundcheck recently which is to actually help me in the review process specially if there is intent documentation like ADRs or similar.

Your post inspired me to try from a different angle. Thank you.

It always seemed to require extra effort to "program myself", maybe because it requires questioning whether I'm doing it the right way and what would be some alternative ways of doing it. It's almost like "out-of-box thinking".

Whereas basic coding is often as easy as writing this note here, just write what comes to my mind. Coding tasks are often trivial, but they must be done. But they don't really burden our mind too much, not too often.

But with AI, it's all about "programming the programmer".

And that requires more thinking, asking more questions like is this really what we need to accomplish, or would some alternative way be better? What alternative way?

Asking questions like that was always part of the work but with AI it seems to be the only type of work. And it is more difficult, more exhausting, than basic coding.

- a whole generation of you guys are going to regret this decision very seriously 5 years down the line

- mark my words

- just like how studies are being published currently on how meta algorithms are designed to have you hooked and causes brainfart, 5 yrs down the line , studies ll come out showing how LLMs have caused degradation in critical thinking and coding for programmers

- A whole batch of people ll be forced to go back to the basics is how this ll end

None of the existing ones (that I've used at least) are good editors designed to work with agents.

Personally, I’d feel much more confident to use a vibe-coded library where I can read the human-written intentions than one where I just see a lot of AI-written code. Maybe it feels more like there is still a programmer/engineer/architect behind it who knows what they’re doing and what exactly they want to achieve.

To me, vibe-coding always feels a bit like this weird transition into something else that is more precise and reliable. It feels backwards to give up on our achievements in formal language for the comfortable vagueness of everyday speech.

Also it creates a uniform level of granularity. The great thing about AI coding is that you can go deep and detailed in hard sections and just plain ignore the simple stuff.

What if the "pseudocode" were real code, but in a higher level language than we have today that can actually be compiled deterministically?

the hardest part of programming is the logic errors, as a result i tried a few times to use a formal verifier to write the pseudo code and have the llm translate it into the language i wanted. the problem with this however is that llms do not necessarily know the best techniques for speed and like to overcomplicate the problem/solution.

how does this language help with prevention of overcomplication?

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?

Sometimes you might also want examples and then BDD testing software (like Yadda) might make sense?

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.

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 had this issue before AI too. Staring at code I wrote, wondering what the hell I was thinking...

I'd often start a project or file with a big pseudocode comment block at the top. But I'd rarely keep it! After reading your post, I'm thinking that may have been a mistake...

Very cool project.

I agree, but I just log all user messages in a chat_log.md and review them regularly with an agent to detect deviation from user intent.

I find it bonkers most coding harnesses simply discard one of the most valuable streams of information, those user messages can also identify harness weaknesses and project issues by reflection.

https://en.wikipedia.org/wiki/Program_Design_Language

https://codecourse.sourceforge.net/materials/Code-Complete-A...

I guess you still need the chat to discuss with the AI? For example, ask it to compare solution A and B, or to explain how to do X. A bit like you can use plan mode today. Then given the result, you can write the hz file (or even have an agent write it).

But I wonder how it works on a more complicated project than fizzbuzz. Can I suggest you use Huzzah to develop itself, and then share the hz file(s)? That will show both how it works on a more complicated project, and something that is developing over time.

i have Reviewer bot, Developer bot and DevOps bot that listen to any @mention and each of them is just wrapper around pi harness with capability to read/write through Gitlab issues, MR and comments.

So i can choose whenever i want to vibe code the whole feature or when i want to co-develop or review the code line by line through Gitlab issues or MR.

It feels more natural to me to navigate through my past 'prompt' just like another Gitlab comment.

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.

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

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.

what you did is spec-driven development, instead of use-cases and requirements you have pseudo-code.

spec-driven did not work in my case, likely yours suffer the same "issue of walls of text no one wants to read".

Then probably do some fuzzing or SAT solving to formally enumerate the known-good cases and possible edge case exceptions. That was before I knew about ranged variables, category theory, etc.

Unfortunately the real world got in the way, and I spent a quarter century treading water to survive, which was exacerbated by CPTSD amplifying ADHD and OCD symptoms many fold before I knew what they were. So now any great ideas I might have had are rendered obsolete because an LLM can synthesize them in a matter of minutes. It may be time to let go and hand things over to the next generation.

-

I think maybe the goal now is to keep building on these ideas until we achieve creating digital assistants that can manage all of the aspects of our lives that interfere with our goals. That's a controversial statement because the political right doesn't distinguish between setbacks and goals (it's all discipline) while the political left embraces a kind of learned helplessness as controlled opposition. Change comes glacially or not at all. In other words, help isn't coming from above - we have to pick ourselves up by our bootstraps like we always do.

A few things that AI might help solve by rendering the conditions of their existence obsolete:

- Money

- Hunger

- Illness

- Exploitation

- Pollution

The list goes on. Unless we're actively working to solve these things, then whatever we come up with is frankly a distraction. I consider just about all tech innovation since the 1990s to be a waste of time for that reason. It all just made some guy rich. Yawn.

Huzzah however, is great. I hope it leads to something wonderful.

It has two problems though: if my approach has flaws the agent would implement it as-is even if could instead suggest an improvement. Also, an advantage of agents in huge codebases is that they can find where to make the change and draft it, which wouldn't work with this system.

Am i missing anything?

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.

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.

Coding Encoding Think about the terms

As in micromanagement.

I could also use a Cucumber (or your favorite BDD) approach, writing out user stories and then have Claude build the code that satisfies them

But this primarily works for smaller self-contained pieces. If you're working on a larger code base with knock-on effects, you can't express it in pseudocode -- unless you maintain a whole "pseudocode twin" of your codebase, which seems like a lot of extra work.

You can get close, but things will be missed. So you'll edit, or provide more info to the AI outside your pseudocode, and maybe get to what you want. But another change will undo the fix you made, because whatever hidden AI context was needed for that first fix is gone now.

The pseudocode isn't a bad idea in terms of trying to visualize a complex idea. But just like writing code, humans suck at truly groking all the implications of their complex ideas, and make mistakes. We need formal methods to double-check those complex ideas to avoid the mistakes. Some kind of formal representation of your idea, in something like a cyclical graph, could have checks on it, to make editing it less error-prone. But you need to get the human out of the loop, or you'll be trapped in the same world we've always been in.

My concern, however, is that all of these options might ultimately be slower than just prompting.

I mean, at this point, another option would be to just go back to actually writing the code ourselves, like we did back then in 2024 ??

Also, it seems one could get Claude to do this in 2 mins without making a whole IDE specifically for it?

Now days I use the LLM wiki idea to build a detailed spec up front before getting the agent to build the system. Keeps a record of the intent and you can get the agent to keep this updated with every change request.

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.

Keep your toolchain as simple as possible.

A really nice rig, which you can use in an existing repo, is to have ollama and aider simply log everything that happens in the session, through tee, into a log directory which you do - indeed - check into the repo.

> almost exclusively with coding agents

Do your own commits too (don't just let the ML do them), and in those commits, keep your prompts.

Learn to use your AI skills with succinct and calculated, forthright projection.

Which is to say, it is your own personal set of words now which define your control over your computer.

The words are tools. But what are your methods?

> .. tedious to write full sentences for every change I want .. interaction paradigm ..

Your own command of your speaking/thinking language can be extended as far and as wide, now, as you can possibly imagine. In fact, you must control AI/ML with imagination now, in multiple ways.

One of those ways is to iterate on expansion of your own ontology. There has to be an input from the AI before an adequate human output can send the AI directly at the heart of it. This improvement loop is on you. Get smarter with the loop.

> pseudo-code -> sync -> record of intent

[1] "Idea -> Description -> Result -> Build -> [human] (use)"

Well, I get this by checking all my aider logs into a submodule of my main source tree. All my prompts, all the happy little mistakes and bright, shiny things, commit by commit. Sure, the logs grow and grow, but you know what .. I learn a hell of a lot by reading them.

Time-stamped. So, nice graphs if I wanted them, one of these days we'll do it, me and the AI.

The commit point for where I cut the exhaustion between me and the immense power of the AI/ML tooling, is when there is a new build, and I have tested it, personally.

I get exhausted if there is no delivery factor, to me personally, from whatever method I'm wrangling the tools with. Like if I really push too hard on the prompt, things get gnarly.

But, I've been here before over the decades, there are methods.

Even in the AI/ML age .. tooling and methodology requires a discipline - what is true now more than ever is that if a method fails, the usual approach of building another tool is not necessarily the best approach.

Methods can be sharpened just like tools. But every tool carries a cognitive load.

The methods are there to make that load useful. Are you a user?

So then just do a build and run it. See if is worth it.

Goto [1].