Maybe we can keep on coding? pseudo code project

Posted by EmptyDrum 9 hours ago

6 months ago a few people [https://news.ycombinator.com/item?id=44940089] agreed that LLMs are very good at translating Pseudo-code to real code. I agree. Also, writing pseudo code somewhat makes me feel a similar state of flow. Maybe even more, because no compiler/interpreter annoys me about syntax issues. Now, I built this:

https://github.com/HalfEmptyDrum/Pseudo-Code-Flow

It is basically a Claude Code skill. You can call it on a .pseudo text file with /translate. It will obviously translate the pseudo code into your specified language. This would be nice and all, but I included another subtle but useful feature:

*This is probably the most useful feature and fundamentally changed my coding*:

The LLM will suggest changes (design, architecture, functionality, ...) to your code, but will roughly use your pseudo code style.

I think of pseudo code as the semantic body that is closest to how the code/algorithm is represented in my head. When Claude then answers in my language instead of Python/C++/... (which has lots of boilerplate to make it work), it resonates much easier with me.

Let me know what you think!

Comments

Comment by codingdave 2 hours ago

> The LLM will suggest changes (design, architecture, functionality, ...) to your code, but will roughly use your pseudo code style.

So it will change your architecture, but keep your line-by-line logic? Is this like a self-driving car that takes you to the wrong destination, but accurately follows traffic laws on the way?

Give me the opposite - something that builds exactly what I designed, but has the freedom to get there in better ways than I suggest.

Comment by jseabra 4 hours ago

Translating pseudo-code to real code is almost table stakes for any decent LLM at this point. But getting architectural feedback in the same abstraction layer you think in, that's a different thing entirely. I've noticed something similar when working with Claude Code. The quality of the back-and-forth improves significantly when you stay at the intention level rather than jumping straight to implementation. Once you're in the weeds of actual syntax, the conversation tends to collapse into micro-corrections. Staying pseudo keeps the design space open longer. One thing I'd be curious about: how does it handle the translation when your pseudo-code has ambiguous control flow? That's usually where I hit the wall. The semantic intent is clear to me but there are three or four valid ways to implement it and the model just picks one without flagging the decision.

Comment by lazypl82 8 hours ago

Great point on the flow state with pseudo code. The gap I keep running into is what comes after – once the translated code ships to production, knowing quickly whether it actually behaves as intended is still mostly manual. Curious if others have thoughts on that part of the loop.

Comment by raw_anon_1111 7 hours ago

Why would that be any more manual than it has been before? You still write or have Claude to write unit and integration tests thst you review

Comment by EmptyDrum 8 hours ago

I feel like that this is fundamentally impossible to solve for. Approximately the effort = planning + checking correctness seems to be constant.

Comment by EmptyDrum 9 hours ago

Btw, I got inspired by this: https://www.williamjbowman.com/blog/2026/03/05/against-vibes...

Really useful read!

Comment by 9 hours ago

Comment by stbtrax 9 hours ago

feedback: your psuedo code example is just product requirements and not actual psuedo code. and I think if you wrote psuedo code it would just work as is without a skill

Comment by EmptyDrum 9 hours ago

True (will fix) - but then still, Claude will still not change my pseudo code, but directly translate. I liked that part particularly.

Comment by EmptyDrum 9 hours ago

[dead]