I think you’re probably missing why it’s exhausting. The problem is not writing English, it’s the rate of change. Programming is meditative, it is a thinking process, the code you output is an artifact of your thinking. Agent-based development… there is no thinking, no meditation, you’re delegating the thinking to a machine, you’re just barking what you want at it, incessantly, endlessly.
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.
I would disagree that there is no thinking. I think a strong understanding of the fundamentals of coding are still wildly important to get good quality code, and a big part of that is thinking or reasoning through a particular problem. It’s just now we have a way of using common language in order for that to happen instead of having to learn or keep up with every new tool and framework in order to do so. The new programming language is just in your native tongue.
I’m not a full time dev, but I code quite a bit doing Systems and OPs stuff, but AI has opened up an entirely new world to me and it has expanded my ability to think through a problem. It’s the ultimate rubber ducky. I love to watch the reasoning process while I’m in opencode so I can interrupt if I see it going down a path that doesn’t make sense.
It’s opened another world to me that allows me to implement ideas I’ve had for years without the time to invest in the skills needed to even try the idea.
I don’t mean to imply that making things with these tools is lesser, or that it doesn’t require some skill, but it is fundamentally different to programming. I’m glad you’re able to bring new things to life with these tools, that’s a great thing :)
My broader philosophical take is that we, programmers, lived through a golden age where our skills used on our terms were some of the most valuable skills. The golden age is over, our skills aren’t useless, they can still be applied to making things with modern tools, but it is no longer on our terms, no longer programming, no longer the meditative thinking process it once was.
For non-programmers, this is their golden age, the reign of programmer tyranny is over.
I'd argue that this is the golden age for consultants.
The old equation was several expensive programmers per project. The new equation is a clown with a token budget plus an expensive rescue operation. In either case, the project will still be late, and it'll cost roughly the same.
> I don’t mean to imply that making things with these tools is lesser, or that it doesn’t require some skill,
But it doesn't require some skills. People have posted showing their 7 year old turning out some game using AI; if your software requires the literacy of the average 7 year old to produce some target, trust me - it doesn't require skills.
It requires a different but somewhat overlapping set of skills, and the barrier to entry is much lower. It's neat that 7 year olds can make games, but they're probably not publishing polished and marketable products.
barrier to entry what? to entry having some (seemingly) working code has lowered. But barrier to enter software marketplace with that has not -- that may have been only increased due to the supply pressure. Having working code was always the easier part, but knowing what to write, and what to do with that later is not solved by whatever coding improvements.
> I don’t mean to imply that making things with these tools is lesser, or that it doesn’t require some skill, but it is fundamentally different to programming.
Exactly, it is a skill, and it is different from programming, but in the age of cars why train to outrun them on foot? train to drive the car.
Using AI for hours and hours every day has got to leave a new skill set in the human users. It's hard to sit there and steer every minute, just the volume of verbiage and speed of change is amazing. That time and effort spent into AI steering is your new training.
I sympathize with this take but I think it’s conflating programming as a hobby vs code needed to run a business.
I always believed that programming was solving problems and building things. With AI, you can still solve problems - the better your questions/ prompts the faster you get to your answer. To ask those questions you need to probably have that meditative thinking to grasp the crux of what you’re trying to solve.
On the business side, paying a programmer for their meditative time would be the first line item to cut, when you can bark orders at an idiot savant instead.
When a business pays me to develop software, that's a lot more than coding. Sometimes it takes weeks to just translate the business needs into a plan, budget, and timeline (not that I ever meet it). Often that includes documentation, training, infra, and a maintenance contract (hopefully with retainer).
The coding really is such a small part of that process.
Absolutely. And honestly, I don't think AI can really replace that. It can execute a plan, but it can't really figure out the best plan from a sea of unknowns strewn within people's minds. There's a certain meditative aspect to this stream of work still, but I would hesitate to call it "programming".
The age of "programmer tyranny", as you call it, was over long ago. Product manager tyranny has been the de facto regime in Big Tech for years. That's how we ended up with subscription models everywhere, enshittification, and infinite data tracking. Imagine that x1000. That's where we're heading, IMO.
The current biggest problem is reputation and QA. Ie I see hundreds of same kind of apps when I search for open source stuff on F-Droid, but I can't really say whether it was properly audited with current influx of vibe-coded stuff, whether it contains malware, is it fully vibe-coded or human evaluated the result, etc. which one of those hundreds is actually good?
When we solve the slop recognition problem, we can actually see a positive turn from enshittification, because copying products overnight without spyware became almost trivial.
"The new programming language is just in your native tongue."
False. Engineering was about implementation, not about result. "How to get there"?
Now "thinking" is to check that model actually understood what you want. We are much closer to product manager who's testing new product with his hands and giving feedback to engineers, rather than to engineers who's thinking "how we implement that"?
"but AI has opened up an entirely new world" - i hear this all the time exactly from "not a full time dev's". This is FOR SURE opened whole new world to people who didn't code and collapsed whole old world for people who loved to code.
Maybe it is just me, but creating simple CRUD application pre-llm required more cognitive ability from me than to "implement" whole CRM system with UI and multiple integrations right now. It is not hard, just tiring in a boring sense, like finding needle in a haystack
When I read stuff like this people I feel like people haven't yet accepted reality. I think knowing how to write code made a lot of people feel very special. Like the could do something magical, and now feel like that's being taken a way from them. I've been writing code since I was a child and spent my entire career as a software engineer, so I understand where these people are coming from, but the reality is AI has changed this profession and this skill set forever. People need to deal with this and move. You can still do very special things with AI that a "normal" person cannot do, so focus your energy there.
What is your point? That coding was easy and nothing special? It wasn't. That programming changed forever? No one arguing. That all of us should enjoy new world order? Nah, this work isn't fun for me anymore. I will do something else for the living
I never said it was easy but it's clear that you're not coping well with new world order. Unfortunately for a lot people, it's here to stay do get used to it.
I agree with you but for a different reason. When the ai generates exactly what I asked it to but it isn't working, I need to think and figure out what I really want rather than what I previously thought I wanted.
> I think a strong understanding of the fundamentals of coding are still wildly important to get good quality code
I don't think this is true any more; you need to ask the agent to inspect the system, draw up plans with the system's current shape in mind, then after it's done writing the code, ask for it to review the code, and make sure it's as minimal and high quality as possible a couple of times.
Creating programs really doesn't need deep understanding of the fundamentals any more. It needs a shallow understanding, and a willingness to manually test a lot.
And I'm personally not happy with that. To manually test something, we have QA, to shape business requirements, we have a business analyst and a product owner. Now a developer needs to be a 3-in-1 person?
For software within a certain complexity scope, this is true. Like the average SaaS CRUD experience that many web developers were building before AI - a lot of that can be handled almost entirely by agents, with very little human in the loop activity. But past a certain point of scale/complexity, this breaks down rapidly. In the past 8 months I've seen this occur several times, and if you only rely on agents to get you to that point, then you're in a heap of trouble when you do reach it, because it's very hard to backtrack.
AI has mostly been improving faster than the complexity of the projects people are capable of handling has increased. The lines are going to cross soon.
Agree with programming is meditative but disagree that agent-based development means there is no thinking. Agent-based development means more thinking like a lower level manager. You spend more time making architecture decisions, making decisions on the user interface, trying to manage your time and your agents time to increase the amount of work produced in the same time, asking the agent about the code and making new decisions. For many people who went in programming thats not their strong suite and hence is really exhausting. Instead of living in the code you are managing the code and using a part of the brain you are not good at.
> Agent-based development means more thinking like a lower level manager. You spend more time making architecture decisions, making decisions on the user interface,
Whose manager is making these decisions? My managers have always been concerned with how much workload everyone has, delegating tasks at an extremely high level that they barely understand, and handling the messy human interface between their reports and senior leadership so that everyone on their team is kept happy and properly compensated.
I have been in this industry for almost twenty years and I have NEVER had an engineering manager making architecture decisions (that's either my job or the lead engineer's job, depending) or UX interface decisions (that's the realm of Product).
If my LLM agents start taking sick leaves and pager duty rotations then I'll start entertaining this bullshit line about being a manager
You should probably be deferring to the agent on nearly all architecture decisions; it's trained on a lot more architectures than you'll ever see in your life, and it does a better job of designing architectures for common problems than many engineers at this point.
You have to ask it to consider the architecture, or it'll cut the shortest path to any solution, but if you ask it, it'll come up with likely a better approach than you would have invented.
Your job is mostly to ask it to think about all the aspects, and then do manual testing on the output. The agent can take care of the rest.
But how many "architecture decisions" do you really have to make when it comes to any proper project? Also "making decisions on the user interface" is literally what frontend engineers have done for years (so you're still working as an engineer while you claim to be a "manager"). If you are in programming and programming is not your strong suite, the moral thing to do is either get better at programming or seek an actual manager job where it makes sense to use the "part of the brain" you are good at. Why do you need to pretend that being a good manager = being a good programmer? Why do you not care about being a good programmer and just the output of waht the agents are doing? You're purely thinking of it from a business pov and optimizing time but you're missing the individual programmer who actually sees value in programming and wants to get better.
For me thinking and understanding is the primary bottleneck. Sure I could spin up 4-5 more parallel things but it doesn't matter because they're soon bottlenecked by my writing/review of their input or output. I can manage 1-2, maybe 3 if one is a long term running task. And having thinking be the bottleneck makes for a very taxing workload...
I tend to work like this:
1. Write a very vague spec of what I want
2. Iterate on that with claude until there's no major open questions.
3. Depending on the size either turn that into a requirements file (large things), a design (medium things) or an implementation plan (small things). Implementation plans for large / medium tasks are split into phases.
4. Once all the plans are iterated on and approved I send claude off to implement with subagents, but not commit. I usually find some weird stuff when reviewing the code to fix before commit. Any time I've let claude commit I've ended up with weird stuff.
If we really could develop in UML, that'd be a nice sweet spot.
But everything I read about the rise and fall of UML is: it's great to start, but never keeps pace with day to day code changes and becomes almost useless out of the gate as real edges force different paradigms.
Now, if you could wake my AI up in the middle of the night and by morning my UML is is perfectly aligned, or the reverse, my UML realigns the code, that'd probably be a sweet deal.
The AIs can read images and charts. If you want to try programming with UML, you should absolutely try it. My guess is that you'll initially be absolutely gobsmacked, but then the problems will start to show and it'll be frustrating as well.
Yeah. I think it'd be fun to watch an LLM try, though. I'm imagining that it'll really show all the things in the UML that don't fully make sense, but look great at first.
i think this is a fascinating cognitive dissonance on display:
> there is no thinking, no meditation, you’re delegating the thinking to a machine, you’re just barking what you want at it, incessantly, endlessly.
why do you think software teams exist? it was exactly for that purpose for non developers to do what you described but perhaps varying degree of politeness and professionalism.
> For businesses it makes sense to abandon programming in favor of delegating to agents that can do more in less time,
business operators were never in the business of coding. code never had any value to them. code isn't what they interact with.
I think a lot of software engineers confuse intrinsic value of the thing they produce with the interface that ultimately drives them. It was never code.
And now AI agents replace a large portion of what software engineers used to do. I've already seen many shops with 20~30 full stack teams downsize by 80% . You just don't need that many people anymore. A competent engineer, AI budget can absolutely replace large teams because the size of the thing never really mattered beyond what they can intake in terms of natural language demands.
Where is the cognitive dissonance? You're just repeating what they said but from a negative angle of saying programmers enjoying coding means they are confused about its worth.
They pretty clearly say they enjoyed the intrinsic value of writing code and do not enjoy the act of piloting AI minions.
> Either be a programmer and code, or be a delegator and delegate
Even if you just enjoy programming for the sake of programming, you can use it to review your code and then hand verify its findings, or prototype and explore feasibility of something you will in the end fully code yourself. For most people that enjoy programming there are still tasks they don't enjoy, like making a bunch of cross-language bindings for something that doesn't have an automatic way to generate them.
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 had a LLM based prototype called "cleanroom" which would convert a program into a spec and then back into a program.
The results were disgusting: the spec would encode all sorts of irrelevant implementation details, and then the new version would reimplement them faithfully, and be 3x more bloated than the original. The exact opposite of what I was going for!
I didn't put much effort into it, maybe it was solvable with prompting (or more likely, more human effort on the spec phase), but it looks like the LLM has the same problem as the human, it can't know what the intention was, and it can't know what's relevant, what's essential and incidental.
But basically, what I needed wasn't a spec but user stories. (And probably multiple prototype outputs to choose from...)
I should definitely give it another crack though...
---
P.S., Spoiler for next ten years: software as biology (esp. crossbreeding, mutation, selection pressure...)
This largely matches my experience, and was one of the motivators behind this project. For some reason, LLMs are still very bad at distillation. We had a really large and complex codebase at my job that I had to quickly ramp up on. I asked an LLM to generate product docs from it, and it barely helped me.
I came to the conclusion that something in the codebase needs a hard boundary, where the team agrees that only human hands touch it. Otherwise the entire repo becomes untrustworthy as far as discovering intent goes.
Yeah I'm not opposed to bi-directionality, though right now there are a ton of projects attempting to do some variation on that theme. Extracting specs from code, producing short summaries, etc. I've tried a few ideas at the company I work for, and they never seem to pan out. At the end of the day, you need something that was simply written by human hands.
I don't think it's particularly difficult, or clever. You can prompt your way into this with frontier models, especially if your codebase is designed for it from the ground up (architecture well factored, documented, tested, harnessable, so that it even has a pseudocode representation in the first place).
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.
This is the entire domain of programming language design, except with the goal of doing it reliably and deterministically enough that you didn't need to look past the short version of the code at the compiled output.
We all know how badly that failed once we started coming up with AI, and could outsource dealing with all that bullshit. Nobody wants this -- they ran screaming as soon as it was viable.
Afaik there's no language - the pseudocode can be written however you want. And the costing money to compile? If you're prompting an llm you're already doing that, just with prose instead of pseudocode. I'm not sure this approach is a good idea, but it might be - and imo it's worth trying :)
Yes exactly. Except now, the language has zero constraints. It can be a perfect distillation of your intentions.
You might think, well code is perfect. But code is syntactically perfect, because it has to be. Because compilers can handle very little ambiguity. But that doesn't mean it's a perfect representation of your thoughts. A huge part of language design is for the compiler, not for the author.
And I'm not 100% sure of this, but I'm fairly confident that this approach would be far more token efficient than the way we currently use AI for programming.
I could do this before too. The way I work is that I just write some functions, fully annotated, in whatever language the project is in, with a comment on what I expect the code to do, and an empty return. Then get an LLM to fill in the functions.
Helps me think about the problem, like your post mentioned, but I don't have to pay a tax on converting a prototyping language to a different language.
That’s exactly what this editor is for, except that your original written version is retained and source-mapped to the code that it generated. So as a project grows in size and complexity, you have a smaller foot print of human-written intent that acts as a reference. There’s no “prototyping language”, it’s just whatever you want to write.
This is how I liked to write software pre-LLM. Top down. Write the interface and tests first, implementation second. I think I got it from SICP. "Wish-driven programming" I think I heard once.
Basically yes that’s what I’m proposing. Not sure if I’d describe it as a loop though - more like returning to some midway point after having traveled too far in one direction.
Fully manual coding is the most reliable but extremely slow and costly.
Fully LLM driven coding is extremely fast, but for serious work is too unreliable.
Spec-driven development might be viable, but too often the specs end up being LLM maintained, which defeats the purpose.
You need some hard boundary in the codebase where only human hands touch the files. And you want to enable the velocity that AI allows. So yes, semi-formal programming does seem like a promising solution.
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.
Right level of abstraction is a good way of putting it. It's basically like creating a custom DSL, but flexibility of LLMs allow the DSL to be ad-hoc.
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...)
Yeah exactly. The module/directory level is currently untested. I'm working on a desktop version so I can talk to a file system, and then I'll be able to explore those problems.
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.
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.”
Not a dumb question - you can totally do this. I was doing this for a while. Before Claude Code really took off, this was my primary way to use Cursor. I'd write some pseudocode, highlight it, and just write to the AI "make it real". Works like a charm.
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 there's a lot to like about this approach, especially persisting my 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.
Yep one of the things a real version would need (this is just a proof of concept) is a kind of safeguarding and error handling. You could easily write code that the LLM couldn't feasibly implement, and it would need some way to mitigate that with you.
Okay, but then why not make this a new sort of fuzzy language, rather than building a new app with it's own UI?
I think having to open a web interface is a big entry barrier.
Imagine if those pseudocode files could live in your codebase, and the CLI tool would just “build” the actual code, with sourcemaps. You could edit the code in your favorite editor and run “build” commands in your favorite shell.
(TBH, I haven't looked deeply inside the repo and maybe it's exactly how it works. I just saw that demo and readme tell you to open a http://localhost:5173 as if you can use it only via custom UI.)
I'm not sure how to do syntax highlighting for this pseudocode in any IDE, but you could start with supporting something like Alabaster theme, the whole point of which is to highlight as little as possible.
I say this because I really think that if the setup was simpler lots of people would use it. It's a kind of concept that when you read about it, you think “Wait, how did I not came up with this”. Finally some interesting concept in this endless stream of skills, MCPs, loops etc.
I mentioned it was an experimental proof of concept, but I didn't specify what that means. Right now it's just a web app, but yes exactly as you said, the goal is to turn it into a desktop application where the files live alongside your code (somehow) and can write to a file system. That's the natural spot for it, I think.
As for why it needs a dedicated UI, there's a few reasons. First, the syntax highlighting as you mentioned is a wickedly difficult problem. I'm super stoked that it even works at all, tbh. Another reason (which I didn't showcase) is that the editor builds source maps from your pseudocode to the real code. So you'll be able to uniquely trace each part of your prompt to the line it generated.
That kind of thing might be able to be implemented in a plugin, but at the moment it's way easier if I just control the entire environment. I'm not opposed to it, though - this could go in lots of different directions and I'm open minded.
I think that just adds another unnecessary level of abstraction that you then have to understand before you can approve. It feels like taking a half-step backwards before moving forwards again.
As I see it, there's a bit of internal contradiction: your declared intent is to not write code, but you had to circle back to code (albeit more relaxed and vague) because human English is (compared to proglangs) imprecise. Pseudocode, however, is not far away from it, still not strict, and LLM is still a stochastic generator. So it will continue to randomly deviate from what you want it to do. I guess it could be an enhancement, but who knows, maybe in a year from now, you will get tired with pseudocode not being precise, and go back to writing code :wink:
I'm not sold on the pseudocode approach, but I agree with the declarative aspect. Declarative specs have become central to my process and I've built this tool to support it:
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.
I share the same sentiment here, pseudocode is just basically prompts all over the place, rather what I think is much more valuable are oracles that can only come after the LLM has written something not before it.
As someone who collaborates with AI programming tools daily, I understand this feeling of exhaustion.
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.
For a long time now i thought that AI tooling went wrong way. Or at least it went way that makes sense from valuation and selling business point of view, instead of what actually would make developers better at their jobs point of view. We started with chats then someone invented harness which is just chat window with few additions and it separated us from actual code.
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.
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
Codespeak looks cool! For a while I was playing around with something similar - like a mix between DDD Event Storming and Gherkin Rules. But I found it didn't really work because you need to sourcemap it to code - looks like that's what Codespeak is trying to do. Neat, thanks for sharing!
" I also don’t want to go back to writing all my code manually "
- 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
- it is going to be so bad that vast majority of these "i dont write code anymore" guys are going to be unable to write even a c++ hello world program without an LLM
- the argument these guys come up with all the time is "I dont need to"
- Big assumption there buddy, big assumption. Lets play both cases shall we.
- Case 1: LLMs infinitely improve and nobody has to code anymore. Yea well, writing a paragraph spec isnt that hard for me bro, I already do it for every project while not using an LLM
- Case 2: LLMS go bust completely for whatever reason. We have a whole generation of mass programmers and 99% of them cant add 2 numbers in c++. Guess what? I am now one of the most sought after programmers in the entire world and part of an absolute minority
Doing lots of programming over the years I've realized that I often need to write "code for myself", in my head, to think what I should do and in what order, and also why. I write to-do notes and notes on why something was best done or had to be done in a given way. Code is instructions for the computer, but developers need instructions too.
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.
Are there examples of how this would work when you need the pseudocode to reference abstract application concepts?
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"
Not yet, it's still a proof of concept. The next iteration will be a desktop app with filesystem access, so I'll be able to test out that scenario, as well as a few others.
At first I thought spec driven development would be an obvious solution to the deficiencies you’d laid out, but thinking a little more I’m concerned my original words and prompts which are “captured” in the roadmap, tech-stack, mission and the in subsequent feature documents doesn’t always preserve the exact prompt I’ve given and I’m concerned that something I said would be lost and then forgotten.
Yeah for sure. I think I made a mistake in neglecting to mention the core differentiator in this editor, which is that it maintains a source map from your pseudocode to the generate source. So as a codebase grows, you'll be able to point to the exact lines of your written prompt for any given line in the codebase. This way it acts as a frame of reference, for both agents and humans.
It is useful to know the level of how "hands-off" to specify directions for each task. With some experience one can learn when to specify the high level requirements, and when to stop and think about the problem at hand.
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.
As I was reading and seeing the video, which is easier to demonstrate as you guessed, I was asking my self the same questions you answered in the "Caveats" section.
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.
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.
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.
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.
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.
I really like the “persisting of intent” part of this approach. I don’t have any experience with coding agents, but it seems to me that this could make it much easier/quicker for others to understand an AI-written codebase (or even PR) and maybe also for agents to better pick up on the “human context” of a project.
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.
We'd end up back where we started. One reason code is slow and expensive is that programmers have to tailor the syntax to precisely satisfy the compiler. The benefit of pseudocode is that you can choose how precise or imprecise you want to express your intent.
What you've done here is build a transpiler that takes a lightweight pseudocode representation and turns it into a concrete and executable form in another language.
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.
I feel like many of the comments are skeptical or dismissive but this seems like a really clever idea.
So many classic textbooks use pseudocode to get the gist of an algorithm across, so this isn’t an unprecedented level of abstraction to be working at.
It makes sense that there would exist a middle ground of abstraction between an English essay and actual running code.
Another interesting thought about this: it’s almost like a quick and dirty transpiler for your own programming language design ideas. I’ve toyed with writing my own ”perfect language” and this seems like a quick and dirty way to test out the ergonomics of various syntaxes and concepts via pseudocode.
Preface: unpolished thoughts — it is refreshing to see so many people working on this issue!
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.
Check out Plannotator. It’s not exactly visual, but instead of chats you just give something more like an inline code review. Highlight text, add emoji reactions, contextual comments. This is my preferred way of reveling AI plans. Now I’ve started using it to open planning sessions on existing files and annotating them instead of starting from a prompt, in some cases.
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.
The difference is that linear tickets, PR descriptions, git commits etc all track changes to the code, but not the code itself. You could read a changelog to understand the evolution of an application, but it wouldn't give you a stable, clear sense of what the intended product is right now.
Plus, it'll go stale as quickly as comments do. Some might be correct, but I think a lot of code gets fixed or changed pretty quickly, meaning the pseudocode is basically useless afterwards, unless it's updated... And that's a whole new effort.
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?
The intention is for the files to persist, and I didn't mention it, but a core part of the system is that the editor persists source maps. So at any point in time, you can map any generated line back to the line of pseudocode that generated it.
I'll be looking into multi-file stuff soon - it's an interesting can of worms to think through.
It seems very close to Spec driven development. Here the spec is the pseudocode.
I slightly disagree with people on the thought that we don't think when we do agent based development. Most of my Agent based development is me specifying a change(lose one line or full fledged PRD) and most of what agent based development solves for me is being thorough with the rest of the codebase.
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
To me it's not useful because the level of granularity is off from the level I am currently working with.
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.
A do-what-I-mean interface using pseudocode seems like an interesting idea to explore, but perhaps it should be automatically reformatted by the AI to conform to some grammar? The idea would be a documentation standard (like Markdown), not an actual programming language.
Sometimes you might also want examples and then BDD testing software (like Yadda) might make sense?
I think the way I would want to work with AI for web apps would be like this:
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.
I like the direction of capturing the human intent as a durable artifact, but I dislike how you've gotten there.
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 also tried spec-driven development, and also found that it did not work. I don't want to read a wall of text, and they also fell out of parity with the code, so engineers ended up just having the LLM update the specs. But now the specs are not only a wall of text, they're LLM-generated and we have no idea whether they reflect the real intent.
This project maintains a mapping of each line of pseudocode to every line of real code it generates. It's also terse, because it's code, and in my initial tests I've found it dramatically easier to read than a big list of longform specs.
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.
I understand your approach and applaud it. I have been doing two things that keep me doing the parts I love. Instead of pseudo code I write in a simple managed language like JavaScript or Python. My instructions to the agent is simple. Code gets no comments. It is intentionally brief and for me at least understandable. Second. I have a document for each code file that holds the an enumerated list of rules used to develop the file - The comments if you will but in a format I can deal with line by line, just like the code. This is substantially more rewarding for me as I change both the code and the document and limit terminal interactions to must-see/do stuff.
This approach reminds me of PDL (Program Design Language), described in Steve McConnell's excellent book Code Complete (1993). He recommended writing code using PDL pseudocode first. People can review your PDL before you write the code implementing the PDL, leaving the PDL as code comments.
> 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.
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...
Hello.
If I may, the way I solved your problem of "you lost the prompt" and "prompts describe changes not state" is by using a technology which was actually born 15 years ago: Behaviour Driven Development. I write (or make the AI write but then I review them carefully) features files with the Gherkins syntax. Then I ask the AI to implement the tets and then make them green. It works very well because they are both a description of the application and actual executable tests so they also spot regression. It's a very nice way to work with AI.
My main problem with the current state of the editors is that either they're are bloated i.e. VS Code or they've drift out of being editors i.e. Claude Code desktop or the new agents panel that Cursor/Antigravity and others have introduced
None of the existing ones (that I've used at least) are good editors designed to work with agents.
I think its an interesting approach, much more than most other new agent harnesses at least.
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.
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.
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.
Appreciate the new word in my lexicon - had to google "patois", and I love thinking about this as a way towards code "dialects." Even the example I gave sits somewhere between python and, idk, something else. In other examples I wrote, I found myself intermixing Rust and Lisp.
Also love the BDD reference - this is in fact an evolution of an earlier approach where I was trying to combine DDD event storming with Gherkin Rules. Very keen observation.
I'm rarely vibing at the individual function level these days. If I was I'd probably use this to do the unit tests and then get the LLM to write the function from that.
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.
> There’s no reliable record of human intent. Prompts are discarded
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.
I like the pseudocode approach I think there is some gold there. I been thinking a lot about it (https://www.generativenetworks.com/blog/do-we-still-need-to-...) but working on small apps I never need it only in bigger apps or when you need an extra level of precision in the prompt
It was a very nice post, at least I learned that I was not the only one in a vacuum in this regard. I will try Huzzah and share my views under this topic.
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.
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.
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...
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.
The downside is that... you don't get to brainstorm with the agent about ways to implement stuff. Architecture, design etc. It would feel like.. you're on your own. Of course you could just a regular chat interface alongside but theb you deal with two interfaces. Maybe this could be a target format for another chat agent that you talk to.
Yeah totally - I want to be clear that what's in the video and repo is just a proof of concept. I'm not adamant about it being the only interface through which to communicate with an LLM. I do the same as well; using a chat for rubber ducking is absolutely incredible.
I think that this would be easy to criticize without interfacing with their underlying idea here.
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.
"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."
I use voice input, when I get tired of typing, it is helping me really well. yes agree that, typing long form of English is very tiresome
Pseudocode -
- My question would be can it scale for all types of logic, and do we endup creating syntax similar to python.
Behaviour -
In the vibe coding , most of the time we also give behavior. I feel Gherkin syntax is best form to describe the behavior.
I had this idea 25 years ago, except that I wanted to use the AI available at the time, which would have probably been genetic algorithms. The idea was to write the expected outputs for some input examples and have a Lisp-like language use evolution/mutation to generate a paragraph or so of code that meets the spec.
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.
Fascinating! I haven't been in the industry as long as you, but I can empathize with the sense of obsoletion. I was working on a design tool for over 10 years, with a goal of building a coding language that was understandable by designers. Once I tried ChatGPT for the first time back in 2021, I knew immediately that it was game over. All my work had gone down the drain.
For a while people were talking about the necessity of UBI in response to the potential elimination of jobs. I tend to take your view (I think it's your view) that it's more worthwhile to automate our basic necessities. Food, water, shelter - use technology to drive those costs down to zero or near zero so that an economically risky solution like UBI doesn't even need to be proposed.
attempted this approach before, fails in low level programming situations.
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?
When the project scales, the transformation of intent into such pseudocode becomes a big deal. Having the pseudocode as an intermediate level to check agents' artifacts is interesting media, but I couldn't see how this would actually work with Huzzah tbh.
I've settled into a habit of asking codex to write down summary of key decisions in a ledger as I end a unit of work. It keeps iterating natural but maintains a system of record on decisions in the same repo. The "ledger" is the new code.
I believe these are called Architectural Decision Records. Matt Pocock's skills [0] make use of them. They're one of the more useful things I've gotten out them.
for me i just make all my prompt through self hosted Gitlab.
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.
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
yeah in the blog post I should have outlined the things I first tried to solve the problem. I tried a variant of gherkin rules, using them for the behavioral spec for a project. It works reasonably well, but without a direct source map from the rules to the code, you still end up with a very difficult-to-understand codebase.
I like the distinction between imperative and declarative styles, but I still use imperative chat sessions to work through what the declarative plan should look like. I feel like this approach loses that.
You are like that bad manager who will hire 10x super engineer and then stifle their work with useless policies and meetings and team building activities “to make sure the productivity are better and work is consistent and team harmony is there!!”. The whole idea of using multi billion weight model is you don’t restrict it with your limited knowledge, you only guide it and review after to make sure it aligns with your goals, definitely the model will bring new tools or tricks you never knew it existed let alone they are useful, just like that super engineer doing things on their own approach, you only guide and align to the goal, here in building your software and in the company to your business goals.
the endgame is a team whose git history is all generated commits, while the one file that actually captures intent is a terse text nobody thought to commit.
This is a step in an interesting direction for many reasons. First of all it reduces the "conversation in english" aspect and goes back to kinda "writing code" which I think would reduce a lot of fatigue and bring back some joy in making software. But then it also gives more control over the output in a way that makes sense: I know how i want to code this, but I can save time not having to deal with the syntax/boilerplate/actual writing. Also since I structured everything precisely, reviewing is going to be way easier.
It requires though yet another mental shift in how to code: you stop chatting and you go back to writing in a text editor similarly to what you did before, the difference is that now you write some kind of scaffold instead than the actual code.
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.
In practice I think a lot of engineers would do this. My recommendation would be to avoid this at all costs. In my opinion, the way to scale a codebase with AI is to have some part of the codebase that is reserved only for human hands. You need to be able to look at something written, and to know that it expresses human intent. Once you deviate from that constraint, then you might be even worse off than before, because now you have 2 sets of generated source code to sift through, not 1.
the difference is that you lose the prompt, and even if you kept the prompt around, there's no built-in mechanism that ties your prompt to the exact code that it produced. with this editor, that's all automated for you.
That's definitely the goal. If the pseudocode is only ever touched by humans, then it will act as a frame of reference that could keep the LLM generated code in check.
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.
Yes, I also wrote this kind of pseudocode. But to make full use of it, you'd want to persist it, and to maintain a map between the lines of your pseudocode and the lines of your real code. It's not practical to do this manually, you'd want these mechanics built into your editing system.
It takes a great deal of bravery to publish work like this. I see the comments are filled with people who have never used an agent to develop code and are quite sure this is the dumbest thing they've ever seen.
A good commit message is not a record of human intent, it's a record of changes in human intent. You can read a change log to see the evolution of a codebase, sure.
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.
A good commit message will survive longer than this proposal is the point.
What the author is proposing has a long history of similar ideas: Literate Programming, UML modeling, DSL crazes, and now to LLM-generated abstractions. AI isn't special. They always fail in the same ways as basic "commenting your code". One can even argue that unit tests are a close cousin to this same problem. Taken one step further how is Huzzah better than just using property tests?
> 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
Congrats, it's 1991 and you've invented Python. Except Python is deterministic, ran on computers in 1991, doesn't require a subscription and doesn't burn the world in the process.
I agree with the intent (and I am also exhausted), but not sure Huzzah is needed. you can already do this using any language or no language. I can write some quick python pseudocode that demonstrates what I want but probably is broken, and then ask Claude/etc to write real code in X language that actually works and is more elegantly or efficiently written than my example.
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.
There's a problem being missed here. You're trying to make a big complex thing from a little simple thing. It's like trying to take a hash and turn it back into the original data, without knowing what the original data looked like.
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.
Yes, human imperfection is and will always be an issue. I think humans should get out of the loop for finite tasks, but the problem specifically with software creation is that it's inherently unbounded. You need a human somewhere to reign it in and ensure it's aligned with intent.
A good example of a finite task is like something we're working on at my company. We're building a multi-agent orchestration engine for large scale offensive network ops. Think like an Active Directory attack. This kind of thing is extremely complex, and involves lots of ambiguity and cross-referencing. You couldn't deterministically program a machine to do this attack, but you could definitely coordinate a bunch of agents to work together to do it. And you don't need a human in the loop outside of some lightweight scoping and gating procedures.
This isn't a rant, this is an observation or conclusion. I'm amused how clueless people really are. I mean, it's mind boggling how vast the desert of the emptymindedness is in this forum.
My solution? I'm waiting for someone to make it, since I'm lazy... until then that's my secret.
Another LLM could use the pseudocode to generate black box test cases without access to the generated code. How to define the API between tests and the implementation would require some more work.
I was pretty tired a month in, but this new way of coding felt so much fun that I was along for the ride. But now it's really starting to weigh me down and I feel like I need something new.
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.
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.
I think you’re probably missing why it’s exhausting. The problem is not writing English, it’s the rate of change. Programming is meditative, it is a thinking process, the code you output is an artifact of your thinking. Agent-based development… there is no thinking, no meditation, you’re delegating the thinking to a machine, you’re just barking what you want at it, incessantly, endlessly.
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.
I would disagree that there is no thinking. I think a strong understanding of the fundamentals of coding are still wildly important to get good quality code, and a big part of that is thinking or reasoning through a particular problem. It’s just now we have a way of using common language in order for that to happen instead of having to learn or keep up with every new tool and framework in order to do so. The new programming language is just in your native tongue.
I’m not a full time dev, but I code quite a bit doing Systems and OPs stuff, but AI has opened up an entirely new world to me and it has expanded my ability to think through a problem. It’s the ultimate rubber ducky. I love to watch the reasoning process while I’m in opencode so I can interrupt if I see it going down a path that doesn’t make sense.
It’s opened another world to me that allows me to implement ideas I’ve had for years without the time to invest in the skills needed to even try the idea.
I think it’s just how you use the tool.
I don’t mean to imply that making things with these tools is lesser, or that it doesn’t require some skill, but it is fundamentally different to programming. I’m glad you’re able to bring new things to life with these tools, that’s a great thing :)
My broader philosophical take is that we, programmers, lived through a golden age where our skills used on our terms were some of the most valuable skills. The golden age is over, our skills aren’t useless, they can still be applied to making things with modern tools, but it is no longer on our terms, no longer programming, no longer the meditative thinking process it once was.
For non-programmers, this is their golden age, the reign of programmer tyranny is over.
I'd argue that this is the golden age for consultants.
The old equation was several expensive programmers per project. The new equation is a clown with a token budget plus an expensive rescue operation. In either case, the project will still be late, and it'll cost roughly the same.
> I don’t mean to imply that making things with these tools is lesser, or that it doesn’t require some skill,
But it doesn't require some skills. People have posted showing their 7 year old turning out some game using AI; if your software requires the literacy of the average 7 year old to produce some target, trust me - it doesn't require skills.
It requires a different but somewhat overlapping set of skills, and the barrier to entry is much lower. It's neat that 7 year olds can make games, but they're probably not publishing polished and marketable products.
barrier to entry what? to entry having some (seemingly) working code has lowered. But barrier to enter software marketplace with that has not -- that may have been only increased due to the supply pressure. Having working code was always the easier part, but knowing what to write, and what to do with that later is not solved by whatever coding improvements.
That's exactly what I mean.
> I don’t mean to imply that making things with these tools is lesser, or that it doesn’t require some skill, but it is fundamentally different to programming.
Exactly, it is a skill, and it is different from programming, but in the age of cars why train to outrun them on foot? train to drive the car.
Using AI for hours and hours every day has got to leave a new skill set in the human users. It's hard to sit there and steer every minute, just the volume of verbiage and speed of change is amazing. That time and effort spent into AI steering is your new training.
I sympathize with this take but I think it’s conflating programming as a hobby vs code needed to run a business.
I always believed that programming was solving problems and building things. With AI, you can still solve problems - the better your questions/ prompts the faster you get to your answer. To ask those questions you need to probably have that meditative thinking to grasp the crux of what you’re trying to solve.
On the business side, paying a programmer for their meditative time would be the first line item to cut, when you can bark orders at an idiot savant instead.
When a business pays me to develop software, that's a lot more than coding. Sometimes it takes weeks to just translate the business needs into a plan, budget, and timeline (not that I ever meet it). Often that includes documentation, training, infra, and a maintenance contract (hopefully with retainer).
The coding really is such a small part of that process.
Absolutely. And honestly, I don't think AI can really replace that. It can execute a plan, but it can't really figure out the best plan from a sea of unknowns strewn within people's minds. There's a certain meditative aspect to this stream of work still, but I would hesitate to call it "programming".
The age of "programmer tyranny", as you call it, was over long ago. Product manager tyranny has been the de facto regime in Big Tech for years. That's how we ended up with subscription models everywhere, enshittification, and infinite data tracking. Imagine that x1000. That's where we're heading, IMO.
It became much easier to make open source too.
The current biggest problem is reputation and QA. Ie I see hundreds of same kind of apps when I search for open source stuff on F-Droid, but I can't really say whether it was properly audited with current influx of vibe-coded stuff, whether it contains malware, is it fully vibe-coded or human evaluated the result, etc. which one of those hundreds is actually good?
When we solve the slop recognition problem, we can actually see a positive turn from enshittification, because copying products overnight without spyware became almost trivial.
What were programmers' terms?
The code
"The new programming language is just in your native tongue." False. Engineering was about implementation, not about result. "How to get there"? Now "thinking" is to check that model actually understood what you want. We are much closer to product manager who's testing new product with his hands and giving feedback to engineers, rather than to engineers who's thinking "how we implement that"?
"but AI has opened up an entirely new world" - i hear this all the time exactly from "not a full time dev's". This is FOR SURE opened whole new world to people who didn't code and collapsed whole old world for people who loved to code.
Maybe it is just me, but creating simple CRUD application pre-llm required more cognitive ability from me than to "implement" whole CRM system with UI and multiple integrations right now. It is not hard, just tiring in a boring sense, like finding needle in a haystack
When I read stuff like this people I feel like people haven't yet accepted reality. I think knowing how to write code made a lot of people feel very special. Like the could do something magical, and now feel like that's being taken a way from them. I've been writing code since I was a child and spent my entire career as a software engineer, so I understand where these people are coming from, but the reality is AI has changed this profession and this skill set forever. People need to deal with this and move. You can still do very special things with AI that a "normal" person cannot do, so focus your energy there.
What is your point? That coding was easy and nothing special? It wasn't. That programming changed forever? No one arguing. That all of us should enjoy new world order? Nah, this work isn't fun for me anymore. I will do something else for the living
I never said it was easy but it's clear that you're not coping well with new world order. Unfortunately for a lot people, it's here to stay do get used to it.
I agree with you but for a different reason. When the ai generates exactly what I asked it to but it isn't working, I need to think and figure out what I really want rather than what I previously thought I wanted.
> I think a strong understanding of the fundamentals of coding are still wildly important to get good quality code
I don't think this is true any more; you need to ask the agent to inspect the system, draw up plans with the system's current shape in mind, then after it's done writing the code, ask for it to review the code, and make sure it's as minimal and high quality as possible a couple of times.
Creating programs really doesn't need deep understanding of the fundamentals any more. It needs a shallow understanding, and a willingness to manually test a lot.
And I'm personally not happy with that. To manually test something, we have QA, to shape business requirements, we have a business analyst and a product owner. Now a developer needs to be a 3-in-1 person?
No, the AI takes care of everything but the final manual testing, mostly. It's improving on all aspects over time, too.
It's not that much work.
For software within a certain complexity scope, this is true. Like the average SaaS CRUD experience that many web developers were building before AI - a lot of that can be handled almost entirely by agents, with very little human in the loop activity. But past a certain point of scale/complexity, this breaks down rapidly. In the past 8 months I've seen this occur several times, and if you only rely on agents to get you to that point, then you're in a heap of trouble when you do reach it, because it's very hard to backtrack.
AI has mostly been improving faster than the complexity of the projects people are capable of handling has increased. The lines are going to cross soon.
Agree with programming is meditative but disagree that agent-based development means there is no thinking. Agent-based development means more thinking like a lower level manager. You spend more time making architecture decisions, making decisions on the user interface, trying to manage your time and your agents time to increase the amount of work produced in the same time, asking the agent about the code and making new decisions. For many people who went in programming thats not their strong suite and hence is really exhausting. Instead of living in the code you are managing the code and using a part of the brain you are not good at.
> Agent-based development means more thinking like a lower level manager. You spend more time making architecture decisions, making decisions on the user interface,
Whose manager is making these decisions? My managers have always been concerned with how much workload everyone has, delegating tasks at an extremely high level that they barely understand, and handling the messy human interface between their reports and senior leadership so that everyone on their team is kept happy and properly compensated.
I have been in this industry for almost twenty years and I have NEVER had an engineering manager making architecture decisions (that's either my job or the lead engineer's job, depending) or UX interface decisions (that's the realm of Product).
If my LLM agents start taking sick leaves and pager duty rotations then I'll start entertaining this bullshit line about being a manager
designers, team leads, tech leads, architects, senior devs are all doing this kind of formal or informal management work
just because someone doesn't have the "manager" in their job title they might still do a lot of supervision
You should probably be deferring to the agent on nearly all architecture decisions; it's trained on a lot more architectures than you'll ever see in your life, and it does a better job of designing architectures for common problems than many engineers at this point.
You have to ask it to consider the architecture, or it'll cut the shortest path to any solution, but if you ask it, it'll come up with likely a better approach than you would have invented.
Your job is mostly to ask it to think about all the aspects, and then do manual testing on the output. The agent can take care of the rest.
But how many "architecture decisions" do you really have to make when it comes to any proper project? Also "making decisions on the user interface" is literally what frontend engineers have done for years (so you're still working as an engineer while you claim to be a "manager"). If you are in programming and programming is not your strong suite, the moral thing to do is either get better at programming or seek an actual manager job where it makes sense to use the "part of the brain" you are good at. Why do you need to pretend that being a good manager = being a good programmer? Why do you not care about being a good programmer and just the output of waht the agents are doing? You're purely thinking of it from a business pov and optimizing time but you're missing the individual programmer who actually sees value in programming and wants to get better.
For me thinking and understanding is the primary bottleneck. Sure I could spin up 4-5 more parallel things but it doesn't matter because they're soon bottlenecked by my writing/review of their input or output. I can manage 1-2, maybe 3 if one is a long term running task. And having thinking be the bottleneck makes for a very taxing workload...
I tend to work like this:
1. Write a very vague spec of what I want
2. Iterate on that with claude until there's no major open questions.
3. Depending on the size either turn that into a requirements file (large things), a design (medium things) or an implementation plan (small things). Implementation plans for large / medium tasks are split into phases.
4. Once all the plans are iterated on and approved I send claude off to implement with subagents, but not commit. I usually find some weird stuff when reviewing the code to fix before commit. Any time I've let claude commit I've ended up with weird stuff.
If we really could develop in UML, that'd be a nice sweet spot.
But everything I read about the rise and fall of UML is: it's great to start, but never keeps pace with day to day code changes and becomes almost useless out of the gate as real edges force different paradigms.
Now, if you could wake my AI up in the middle of the night and by morning my UML is is perfectly aligned, or the reverse, my UML realigns the code, that'd probably be a sweet deal.
but complexity is hidden in there either way.
The AIs can read images and charts. If you want to try programming with UML, you should absolutely try it. My guess is that you'll initially be absolutely gobsmacked, but then the problems will start to show and it'll be frustrating as well.
Let's be honest, programmers can't program from UML specs.
Yeah. I think it'd be fun to watch an LLM try, though. I'm imagining that it'll really show all the things in the UML that don't fully make sense, but look great at first.
From a great lecture on agentic SLDC:
„Checking the work is not the same as doing the work.“
It‘s different. There are people who love coding but don‘t like checking written code. Or the other way around.
Also there’s difference in mental load: checking a finished program or algorithm can be harder than working through it while producing it.
i think this is a fascinating cognitive dissonance on display:
> there is no thinking, no meditation, you’re delegating the thinking to a machine, you’re just barking what you want at it, incessantly, endlessly.
why do you think software teams exist? it was exactly for that purpose for non developers to do what you described but perhaps varying degree of politeness and professionalism.
> For businesses it makes sense to abandon programming in favor of delegating to agents that can do more in less time,
business operators were never in the business of coding. code never had any value to them. code isn't what they interact with.
I think a lot of software engineers confuse intrinsic value of the thing they produce with the interface that ultimately drives them. It was never code.
And now AI agents replace a large portion of what software engineers used to do. I've already seen many shops with 20~30 full stack teams downsize by 80% . You just don't need that many people anymore. A competent engineer, AI budget can absolutely replace large teams because the size of the thing never really mattered beyond what they can intake in terms of natural language demands.
Where is the cognitive dissonance? You're just repeating what they said but from a negative angle of saying programmers enjoying coding means they are confused about its worth.
They pretty clearly say they enjoyed the intrinsic value of writing code and do not enjoy the act of piloting AI minions.
> Either be a programmer and code, or be a delegator and delegate
Even if you just enjoy programming for the sake of programming, you can use it to review your code and then hand verify its findings, or prototype and explore feasibility of something you will in the end fully code yourself. For most people that enjoy programming there are still tasks they don't enjoy, like making a bunch of cross-language bindings for something that doesn't have an automatic way to generate them.
Nope. You can't. Expectations and deadlines aligned with code agent usage. No one let you spent x5 time coding things yourself
"We're reinventing coding from first principles" /s
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 think you might be interested in what I’m working on:
https://ctx.company/blog/introducing-ctx-traits/
I'm working on a bidirectional version of this! The big challenge is keeping the various versions of the thing in sync through edits.
Care to share a link? This sounds neat
I had a LLM based prototype called "cleanroom" which would convert a program into a spec and then back into a program.
The results were disgusting: the spec would encode all sorts of irrelevant implementation details, and then the new version would reimplement them faithfully, and be 3x more bloated than the original. The exact opposite of what I was going for!
I didn't put much effort into it, maybe it was solvable with prompting (or more likely, more human effort on the spec phase), but it looks like the LLM has the same problem as the human, it can't know what the intention was, and it can't know what's relevant, what's essential and incidental.
But basically, what I needed wasn't a spec but user stories. (And probably multiple prototype outputs to choose from...)
I should definitely give it another crack though...
---
P.S., Spoiler for next ten years: software as biology (esp. crossbreeding, mutation, selection pressure...)
This largely matches my experience, and was one of the motivators behind this project. For some reason, LLMs are still very bad at distillation. We had a really large and complex codebase at my job that I had to quickly ramp up on. I asked an LLM to generate product docs from it, and it barely helped me.
I came to the conclusion that something in the codebase needs a hard boundary, where the team agrees that only human hands touch it. Otherwise the entire repo becomes untrustworthy as far as discovering intent goes.
Yeah I'm not opposed to bi-directionality, though right now there are a ton of projects attempting to do some variation on that theme. Extracting specs from code, producing short summaries, etc. I've tried a few ideas at the company I work for, and they never seem to pan out. At the end of the day, you need something that was simply written by human hands.
Clever! :)
Difficult! :(
I don't think it's particularly difficult, or clever. You can prompt your way into this with frontier models, especially if your codebase is designed for it from the ground up (architecture well factored, documented, tested, harnessable, so that it even has a pseudocode representation in the first place).
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.
Massive, complex codebase…short pseudocode.
The fact that you don’t think this is particularly difficult makes me questions everything after that statement.
This is the entire domain of programming language design, except with the goal of doing it reliably and deterministically enough that you didn't need to look past the short version of the code at the compiled output.
We all know how badly that failed once we started coming up with AI, and could outsource dealing with all that bullshit. Nobody wants this -- they ran screaming as soon as it was viable.
I'm confused, it looks like you've just written a new terse language that now costs money to compile?
Afaik there's no language - the pseudocode can be written however you want. And the costing money to compile? If you're prompting an llm you're already doing that, just with prose instead of pseudocode. I'm not sure this approach is a good idea, but it might be - and imo it's worth trying :)
Yes, there's no language. And exactly - we're effectively already doing this, but with waaay more words.
> I'm not sure this approach is a good idea, but it might be
After the last year, I feel like this sentence could replace half my outbound emails.
Yes exactly. Except now, the language has zero constraints. It can be a perfect distillation of your intentions.
You might think, well code is perfect. But code is syntactically perfect, because it has to be. Because compilers can handle very little ambiguity. But that doesn't mean it's a perfect representation of your thoughts. A huge part of language design is for the compiler, not for the author.
And I'm not 100% sure of this, but I'm fairly confident that this approach would be far more token efficient than the way we currently use AI for programming.
I could do this before too. The way I work is that I just write some functions, fully annotated, in whatever language the project is in, with a comment on what I expect the code to do, and an empty return. Then get an LLM to fill in the functions.
Helps me think about the problem, like your post mentioned, but I don't have to pay a tax on converting a prototyping language to a different language.
That’s exactly what this editor is for, except that your original written version is retained and source-mapped to the code that it generated. So as a project grows in size and complexity, you have a smaller foot print of human-written intent that acts as a reference. There’s no “prototyping language”, it’s just whatever you want to write.
This is how I liked to write software pre-LLM. Top down. Write the interface and tests first, implementation second. I think I got it from SICP. "Wish-driven programming" I think I heard once.
I have to admit, I am unsure if this article was some sort of parody.
Same, I am still thinking that it's a parody: going full loop back to programming
Basically yes that’s what I’m proposing. Not sure if I’d describe it as a loop though - more like returning to some midway point after having traveled too far in one direction.
Fully manual coding is the most reliable but extremely slow and costly.
Fully LLM driven coding is extremely fast, but for serious work is too unreliable.
Spec-driven development might be viable, but too often the specs end up being LLM maintained, which defeats the purpose.
You need some hard boundary in the codebase where only human hands touch the files. And you want to enable the velocity that AI allows. So yes, semi-formal programming does seem like a promising solution.
Technically speaking everything costs money to compile in the form of electricity. This is just...inefficient compilation.
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!
Right level of abstraction is a good way of putting it. It's basically like creating a custom DSL, but flexibility of LLMs allow the DSL to be ad-hoc.
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...)
Yeah exactly. The module/directory level is currently untested. I'm working on a desktop version so I can talk to a file system, and then I'll be able to explore those problems.
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.
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.”
Not a dumb question - you can totally do this. I was doing this for a while. Before Claude Code really took off, this was my primary way to use Cursor. I'd write some pseudocode, highlight it, and just write to the AI "make it real". Works like a charm.
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 there's a lot to like about this approach, especially persisting my 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.
Yep one of the things a real version would need (this is just a proof of concept) is a kind of safeguarding and error handling. You could easily write code that the LLM couldn't feasibly implement, and it would need some way to mitigate that with you.
Okay, but then why not make this a new sort of fuzzy language, rather than building a new app with it's own UI?
I think having to open a web interface is a big entry barrier.
Imagine if those pseudocode files could live in your codebase, and the CLI tool would just “build” the actual code, with sourcemaps. You could edit the code in your favorite editor and run “build” commands in your favorite shell.
(TBH, I haven't looked deeply inside the repo and maybe it's exactly how it works. I just saw that demo and readme tell you to open a http://localhost:5173 as if you can use it only via custom UI.)
I'm not sure how to do syntax highlighting for this pseudocode in any IDE, but you could start with supporting something like Alabaster theme, the whole point of which is to highlight as little as possible.
I say this because I really think that if the setup was simpler lots of people would use it. It's a kind of concept that when you read about it, you think “Wait, how did I not came up with this”. Finally some interesting concept in this endless stream of skills, MCPs, loops etc.
I mentioned it was an experimental proof of concept, but I didn't specify what that means. Right now it's just a web app, but yes exactly as you said, the goal is to turn it into a desktop application where the files live alongside your code (somehow) and can write to a file system. That's the natural spot for it, I think.
As for why it needs a dedicated UI, there's a few reasons. First, the syntax highlighting as you mentioned is a wickedly difficult problem. I'm super stoked that it even works at all, tbh. Another reason (which I didn't showcase) is that the editor builds source maps from your pseudocode to the real code. So you'll be able to uniquely trace each part of your prompt to the line it generated.
That kind of thing might be able to be implemented in a plugin, but at the moment it's way easier if I just control the entire environment. I'm not opposed to it, though - this could go in lots of different directions and I'm open minded.
I think that just adds another unnecessary level of abstraction that you then have to understand before you can approve. It feels like taking a half-step backwards before moving forwards again.
As I see it, there's a bit of internal contradiction: your declared intent is to not write code, but you had to circle back to code (albeit more relaxed and vague) because human English is (compared to proglangs) imprecise. Pseudocode, however, is not far away from it, still not strict, and LLM is still a stochastic generator. So it will continue to randomly deviate from what you want it to do. I guess it could be an enhancement, but who knows, maybe in a year from now, you will get tired with pseudocode not being precise, and go back to writing code :wink:
I'm not sold on the pseudocode approach, but I agree with the declarative aspect. Declarative specs have become central to my process and I've built this tool to support it:
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.
I have a pretty similar approach to this. I built a sexp DSL for spec and I have a "compiler" which does static analysis checks and linting.
I share the same sentiment here, pseudocode is just basically prompts all over the place, rather what I think is much more valuable are oracles that can only come after the LLM has written something not before it.
As someone who collaborates with AI programming tools daily, I understand this feeling of exhaustion.
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.
For a long time now i thought that AI tooling went wrong way. Or at least it went way that makes sense from valuation and selling business point of view, instead of what actually would make developers better at their jobs point of view. We started with chats then someone invented harness which is just chat window with few additions and it separated us from actual code.
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.
I'm surprised it wasn't mentioned yet, but it seems pretty similar in concept to codespeak https://news.ycombinator.com/item?id=47350931
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
Codespeak looks cool! For a while I was playing around with something similar - like a mix between DDD Event Storming and Gherkin Rules. But I found it didn't really work because you need to sourcemap it to code - looks like that's what Codespeak is trying to do. Neat, thanks for sharing!
" I also don’t want to go back to writing all my code manually "
- 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
I don't think we need to wait 5 years, we can already see it know
- it is going to be so bad that vast majority of these "i dont write code anymore" guys are going to be unable to write even a c++ hello world program without an LLM
- the argument these guys come up with all the time is "I dont need to"
- Big assumption there buddy, big assumption. Lets play both cases shall we.
- Case 1: LLMs infinitely improve and nobody has to code anymore. Yea well, writing a paragraph spec isnt that hard for me bro, I already do it for every project while not using an LLM
- Case 2: LLMS go bust completely for whatever reason. We have a whole generation of mass programmers and 99% of them cant add 2 numbers in c++. Guess what? I am now one of the most sought after programmers in the entire world and part of an absolute minority
Doing lots of programming over the years I've realized that I often need to write "code for myself", in my head, to think what I should do and in what order, and also why. I write to-do notes and notes on why something was best done or had to be done in a given way. Code is instructions for the computer, but developers need instructions too.
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.
Are there examples of how this would work when you need the pseudocode to reference abstract application concepts?
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"
Not yet, it's still a proof of concept. The next iteration will be a desktop app with filesystem access, so I'll be able to test out that scenario, as well as a few others.
At first I thought spec driven development would be an obvious solution to the deficiencies you’d laid out, but thinking a little more I’m concerned my original words and prompts which are “captured” in the roadmap, tech-stack, mission and the in subsequent feature documents doesn’t always preserve the exact prompt I’ve given and I’m concerned that something I said would be lost and then forgotten.
Yeah for sure. I think I made a mistake in neglecting to mention the core differentiator in this editor, which is that it maintains a source map from your pseudocode to the generate source. So as a codebase grows, you'll be able to point to the exact lines of your written prompt for any given line in the codebase. This way it acts as a frame of reference, for both agents and humans.
It is useful to know the level of how "hands-off" to specify directions for each task. With some experience one can learn when to specify the high level requirements, and when to stop and think about the problem at hand.
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.
As I was reading and seeing the video, which is easier to demonstrate as you guessed, I was asking my self the same questions you answered in the "Caveats" section.
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.
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.
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.
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.
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.
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.
Isn't this just spec-driven development in a different language?
I really like the “persisting of intent” part of this approach. I don’t have any experience with coding agents, but it seems to me that this could make it much easier/quicker for others to understand an AI-written codebase (or even PR) and maybe also for agents to better pick up on the “human context” of a project.
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.
For sure - reading LLM-generated code is extremely painful for me, and it's one of the big motivations behind this project.
Cool idea, but let's take it to the next step:
What if the "pseudocode" were real code, but in a higher level language than we have today that can actually be compiled deterministically?
We'd end up back where we started. One reason code is slow and expensive is that programmers have to tailor the syntax to precisely satisfy the compiler. The benefit of pseudocode is that you can choose how precise or imprecise you want to express your intent.
What you've done here is build a transpiler that takes a lightweight pseudocode representation and turns it into a concrete and executable form in another language.
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.
I feel like many of the comments are skeptical or dismissive but this seems like a really clever idea. So many classic textbooks use pseudocode to get the gist of an algorithm across, so this isn’t an unprecedented level of abstraction to be working at. It makes sense that there would exist a middle ground of abstraction between an English essay and actual running code.
Another interesting thought about this: it’s almost like a quick and dirty transpiler for your own programming language design ideas. I’ve toyed with writing my own ”perfect language” and this seems like a quick and dirty way to test out the ergonomics of various syntaxes and concepts via pseudocode.
Preface: unpolished thoughts — it is refreshing to see so many people working on this issue!
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.
Check out Plannotator. It’s not exactly visual, but instead of chats you just give something more like an inline code review. Highlight text, add emoji reactions, contextual comments. This is my preferred way of reveling AI plans. Now I’ve started using it to open planning sessions on existing files and annotating them instead of starting from a prompt, in some cases.
Interesting, thanks!
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.
The difference is that linear tickets, PR descriptions, git commits etc all track changes to the code, but not the code itself. You could read a changelog to understand the evolution of an application, but it wouldn't give you a stable, clear sense of what the intended product is right now.
Plus, it'll go stale as quickly as comments do. Some might be correct, but I think a lot of code gets fixed or changed pretty quickly, meaning the pseudocode is basically useless afterwards, unless it's updated... And that's a whole new effort.
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?
The intention is for the files to persist, and I didn't mention it, but a core part of the system is that the editor persists source maps. So at any point in time, you can map any generated line back to the line of pseudocode that generated it.
I'll be looking into multi-file stuff soon - it's an interesting can of worms to think through.
Having hz files also opens a really interesting idea of using them as a form of static analysis and CI validation.
It seems very close to Spec driven development. Here the spec is the pseudocode. I slightly disagree with people on the thought that we don't think when we do agent based development. Most of my Agent based development is me specifying a change(lose one line or full fledged PRD) and most of what agent based development solves for me is being thorough with the rest of the codebase.
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
To me it's not useful because the level of granularity is off from the level I am currently working with.
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.
A do-what-I-mean interface using pseudocode seems like an interesting idea to explore, but perhaps it should be automatically reformatted by the AI to conform to some grammar? The idea would be a documentation standard (like Markdown), not an actual programming language.
Sometimes you might also want examples and then BDD testing software (like Yadda) might make sense?
I think the way I would want to work with AI for web apps would be like this:
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.
Playwright Codegen?
I like the direction of capturing the human intent as a durable artifact, but I dislike how you've gotten there.
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.
this is a question whole software industry is trying to solve. "how can we make sense of the ai generated codebase"
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".
I also tried spec-driven development, and also found that it did not work. I don't want to read a wall of text, and they also fell out of parity with the code, so engineers ended up just having the LLM update the specs. But now the specs are not only a wall of text, they're LLM-generated and we have no idea whether they reflect the real intent.
This project maintains a mapping of each line of pseudocode to every line of real code it generates. It's also terse, because it's code, and in my initial tests I've found it dramatically easier to read than a big list of longform specs.
Nice work!
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.
I understand your approach and applaud it. I have been doing two things that keep me doing the parts I love. Instead of pseudo code I write in a simple managed language like JavaScript or Python. My instructions to the agent is simple. Code gets no comments. It is intentionally brief and for me at least understandable. Second. I have a document for each code file that holds the an enumerated list of rules used to develop the file - The comments if you will but in a format I can deal with line by line, just like the code. This is substantially more rewarding for me as I change both the code and the document and limit terminal interactions to must-see/do stuff.
This approach reminds me of PDL (Program Design Language), described in Steve McConnell's excellent book Code Complete (1993). He recommended writing code using PDL pseudocode first. People can review your PDL before you write the code implementing the PDL, leaving the PDL as code comments.
https://en.wikipedia.org/wiki/Program_Design_Language
https://codecourse.sourceforge.net/materials/Code-Complete-A...
> 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.
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.
Hello. If I may, the way I solved your problem of "you lost the prompt" and "prompts describe changes not state" is by using a technology which was actually born 15 years ago: Behaviour Driven Development. I write (or make the AI write but then I review them carefully) features files with the Gherkins syntax. Then I ask the AI to implement the tets and then make them green. It works very well because they are both a description of the application and actual executable tests so they also spot regression. It's a very nice way to work with AI.
My main problem with the current state of the editors is that either they're are bloated i.e. VS Code or they've drift out of being editors i.e. Claude Code desktop or the new agents panel that Cursor/Antigravity and others have introduced
None of the existing ones (that I've used at least) are good editors designed to work with agents.
I think its an interesting approach, much more than most other new agent harnesses at least.
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.
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.
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.
Appreciate the new word in my lexicon - had to google "patois", and I love thinking about this as a way towards code "dialects." Even the example I gave sits somewhere between python and, idk, something else. In other examples I wrote, I found myself intermixing Rust and Lisp.
Also love the BDD reference - this is in fact an evolution of an earlier approach where I was trying to combine DDD event storming with Gherkin Rules. Very keen observation.
I'm rarely vibing at the individual function level these days. If I was I'd probably use this to do the unit tests and then get the LLM to write the function from that.
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.
> There’s no reliable record of human intent. Prompts are discarded
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.
I like the pseudocode approach I think there is some gold there. I been thinking a lot about it (https://www.generativenetworks.com/blog/do-we-still-need-to-...) but working on small apps I never need it only in bigger apps or when you need an extra level of precision in the prompt
I do dearly miss the days of only having access to copilot and the acceleration being available, but the intention that was still necessary.
Agree; something got lost in the sauce when we moved to the terminal.
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).
Pushing a fix now - thanks for letting me know.
edit: fixed
It was a very nice post, at least I learned that I was not the only one in a vacuum in this regard. I will try Huzzah and share my views under this topic.
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.
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.
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.
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.
The downside is that... you don't get to brainstorm with the agent about ways to implement stuff. Architecture, design etc. It would feel like.. you're on your own. Of course you could just a regular chat interface alongside but theb you deal with two interfaces. Maybe this could be a target format for another chat agent that you talk to.
Yeah totally - I want to be clear that what's in the video and repo is just a proof of concept. I'm not adamant about it being the only interface through which to communicate with an LLM. I do the same as well; using a chat for rubber ducking is absolutely incredible.
I think that this would be easy to criticize without interfacing with their underlying idea here.
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.
"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."
I use voice input, when I get tired of typing, it is helping me really well. yes agree that, typing long form of English is very tiresome
Pseudocode -
- My question would be can it scale for all types of logic, and do we endup creating syntax similar to python.
Behaviour -
In the vibe coding , most of the time we also give behavior. I feel Gherkin syntax is best form to describe the behavior.
If the pseudocode is precise, what you want is a compiler. Otherwise the LLM is still making decisions for you.
Very insightful. The idea of using pseudocode is clever, and the persistence+correlation layer idea is great.
I had this idea 25 years ago, except that I wanted to use the AI available at the time, which would have probably been genetic algorithms. The idea was to write the expected outputs for some input examples and have a Lisp-like language use evolution/mutation to generate a paragraph or so of code that meets the spec.
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.
Fascinating! I haven't been in the industry as long as you, but I can empathize with the sense of obsoletion. I was working on a design tool for over 10 years, with a goal of building a coding language that was understandable by designers. Once I tried ChatGPT for the first time back in 2021, I knew immediately that it was game over. All my work had gone down the drain.
For a while people were talking about the necessity of UBI in response to the potential elimination of jobs. I tend to take your view (I think it's your view) that it's more worthwhile to automate our basic necessities. Food, water, shelter - use technology to drive those costs down to zero or near zero so that an economically risky solution like UBI doesn't even need to be proposed.
attempted this approach before, fails in low level programming situations.
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?
When the project scales, the transformation of intent into such pseudocode becomes a big deal. Having the pseudocode as an intermediate level to check agents' artifacts is interesting media, but I couldn't see how this would actually work with Huzzah tbh.
I've settled into a habit of asking codex to write down summary of key decisions in a ledger as I end a unit of work. It keeps iterating natural but maintains a system of record on decisions in the same repo. The "ledger" is the new code.
I believe these are called Architectural Decision Records. Matt Pocock's skills [0] make use of them. They're one of the more useful things I've gotten out them.
[0] https://github.com/mattpocock/skills
for me i just make all my prompt through self hosted Gitlab.
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.
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
yeah in the blog post I should have outlined the things I first tried to solve the problem. I tried a variant of gherkin rules, using them for the behavioral spec for a project. It works reasonably well, but without a direct source map from the rules to the code, you still end up with a very difficult-to-understand codebase.
I like the distinction between imperative and declarative styles, but I still use imperative chat sessions to work through what the declarative plan should look like. I feel like this approach loses that.
You are like that bad manager who will hire 10x super engineer and then stifle their work with useless policies and meetings and team building activities “to make sure the productivity are better and work is consistent and team harmony is there!!”. The whole idea of using multi billion weight model is you don’t restrict it with your limited knowledge, you only guide it and review after to make sure it aligns with your goals, definitely the model will bring new tools or tricks you never knew it existed let alone they are useful, just like that super engineer doing things on their own approach, you only guide and align to the goal, here in building your software and in the company to your business goals.
This is basically a compiler, but we’re moving up a layer of abstraction.
Why would I code in pseudocode then ask a LLM to convert it in real code instead of just coding it directly myself ?
I wrote something similar, but as others have pointed out not having a formal language can be a hindrance.
the endgame is a team whose git history is all generated commits, while the one file that actually captures intent is a terse text nobody thought to commit.
This is a step in an interesting direction for many reasons. First of all it reduces the "conversation in english" aspect and goes back to kinda "writing code" which I think would reduce a lot of fatigue and bring back some joy in making software. But then it also gives more control over the output in a way that makes sense: I know how i want to code this, but I can save time not having to deal with the syntax/boilerplate/actual writing. Also since I structured everything precisely, reviewing is going to be way easier. It requires though yet another mental shift in how to code: you stop chatting and you go back to writing in a text editor similarly to what you did before, the difference is that now you write some kind of scaffold instead than the actual code.
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.
> 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.
I think you could go meta here and ask the agent in English to modify your pseudocode for larger changes.
In practice I think a lot of engineers would do this. My recommendation would be to avoid this at all costs. In my opinion, the way to scale a codebase with AI is to have some part of the codebase that is reserved only for human hands. You need to be able to look at something written, and to know that it expresses human intent. Once you deviate from that constraint, then you might be even worse off than before, because now you have 2 sets of generated source code to sift through, not 1.
You could write that pseudocode as a prompt for the agent and get the same result. Use plan mode to understand what agent wants to do.
Am i missing anything?
the difference is that you lose the prompt, and even if you kept the prompt around, there's no built-in mechanism that ties your prompt to the exact code that it produced. with this editor, that's all automated for you.
Does keeping the pseudocode alongside the generated code make it easier to understand why a change was made later?
Prompts plus code called literate programming, have been around over 30 years.
Interesting idea! I wonder if, after some iteration, a variation on this could help curb some of the LLM spaghetti mess
That's definitely the goal. If the pseudocode is only ever touched by humans, then it will act as a frame of reference that could keep the LLM generated code in check.
I was already doing this with "writing" tests. Just being absolutely terribly lazy.
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.
Yes, I also wrote this kind of pseudocode. But to make full use of it, you'd want to persist it, and to maintain a map between the lines of your pseudocode and the lines of your real code. It's not practical to do this manually, you'd want these mechanics built into your editing system.
It takes a great deal of bravery to publish work like this. I see the comments are filled with people who have never used an agent to develop code and are quite sure this is the dumbest thing they've ever seen.
Nice work.
> 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.
A good commit message is not a record of human intent, it's a record of changes in human intent. You can read a change log to see the evolution of a codebase, sure.
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.
A good commit message will survive longer than this proposal is the point.
What the author is proposing has a long history of similar ideas: Literate Programming, UML modeling, DSL crazes, and now to LLM-generated abstractions. AI isn't special. They always fail in the same ways as basic "commenting your code". One can even argue that unit tests are a close cousin to this same problem. Taken one step further how is Huzzah better than just using property tests?
Two clicks from the article:
> 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
Can't already just write pseudocode in your prompts without any extra tooling?
Terse pseudo code > verbose prose
Coding Encoding Think about the terms
Are you using Huzzah to development Huzzah? :)
I'd call this one Micropilot.
As in micromanagement.
i actually really like this. nice job
Congrats, it's 1991 and you've invented Python. Except Python is deterministic, ran on computers in 1991, doesn't require a subscription and doesn't burn the world in the process.
I agree with the intent (and I am also exhausted), but not sure Huzzah is needed. you can already do this using any language or no language. I can write some quick python pseudocode that demonstrates what I want but probably is broken, and then ask Claude/etc to write real code in X language that actually works and is more elegantly or efficiently written than my example.
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.
There's a problem being missed here. You're trying to make a big complex thing from a little simple thing. It's like trying to take a hash and turn it back into the original data, without knowing what the original data looked like.
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.
Yes, human imperfection is and will always be an issue. I think humans should get out of the loop for finite tasks, but the problem specifically with software creation is that it's inherently unbounded. You need a human somewhere to reign it in and ensure it's aligned with intent.
A good example of a finite task is like something we're working on at my company. We're building a multi-agent orchestration engine for large scale offensive network ops. Think like an Active Directory attack. This kind of thing is extremely complex, and involves lots of ambiguity and cross-referencing. You couldn't deterministically program a machine to do this attack, but you could definitely coordinate a bunch of agents to work together to do it. And you don't need a human in the loop outside of some lightweight scoping and gating procedures.
Invented New coding language that transpile to other coding languages and saying it novel approach.
I really feel the pain here, I have myself tried things ol these lines... I will give Huzzah it a try.
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 ??
It's tiring to see how people in the seemingly know dance around the issues an noone gets to the point, noone solves anything.
What is your solution to this problem? Surely ranting about it online isn't going to help?
This isn't a rant, this is an observation or conclusion. I'm amused how clueless people really are. I mean, it's mind boggling how vast the desert of the emptymindedness is in this forum.
My solution? I'm waiting for someone to make it, since I'm lazy... until then that's my secret.
Another LLM could use the pseudocode to generate black box test cases without access to the generated code. How to define the API between tests and the implementation would require some more work.
Sounds a bit like this: https://ulanguage.org/u-keyword
How is it different from https://github.com/github/spec-kit?
I’ve not tried it but I’m willing to bet if you gave Claude or ChatGPT similar pseudo code you’d get the same result.
Cheers!
I mean if you can write pseudocode then just code it yourself, very often that would be almost the same number of tokens/lines
just put that into and ai coding harness end get the solution implemented
It took you 8 months to burn out from churning SaaS slop? My mind was cooked in 3 weeks trying to six neglected ideas at once
I was pretty tired a month in, but this new way of coding felt so much fun that I was along for the ride. But now it's really starting to weigh me down and I feel like I need something new.
I developed a really healthy balance, work and one side project at a time instead of being worried about permanent underclass ideas
what is this!
> utterly exhausted
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].