121–130 of 170 posts
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…
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.
Earlier quoted context omitted.
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…
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…
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'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
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.
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…
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 repre…
I'm working on a bidirectional version of this! The big challenge is keeping the various versions of the thing in sync through edits.
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.