Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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"
by benmusch - 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.by danielvaughn
- 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.
by Jataman606 - 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.
by cyteeditor - 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
by maxwg - 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!by danielvaughn
- " 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
by vivzkestrel - I don't think we need to wait 5 years, we can already see it knowby ygouzerh
- 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.
by wyum - 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.by sroerick
- 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.by zuzululu
- 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:by broken-kebab
- 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.”
by leobg - 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.by wccrawford
- 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.
by danielvaughn - 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!
by smicallef - 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...)
by floatrock - I'm confused, it looks like you've just written a new terse language that now costs money to compile?by quasarj
- Technically speaking everything costs money to compile in the form of electricity. This is just...inefficient compilation.by dcchambers
- I have to admit, I am unsure if this article was some sort of parody.by ern
- 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.
by danielvaughn - 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 :)by kennywinker
- 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.
by avaer - 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.
by a2ff6eeb0 - Clever! :)
Difficult! :(
by igravious - 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.by danielvaughn
- 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...)
by andai - I'm working on a bidirectional version of this! The big challenge is keeping the various versions of the thing in sync through edits.by ianhorn
- I think you might be interested in what I’m working on:by rpunkfu
- 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.
by reticulates