4 ms·

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 t

by leobg 1mo ago

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

danielvaughn 1mo ago
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.
- markiannucci 1mo ago
  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.
  - danielvaughn 1mo ago
    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.
- zahrevsky 1mo ago
  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.
  - danielvaughn 1mo ago
    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.
wccrawford 1mo ago
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 leobg 1mo ago

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

danielvaughn 1mo ago

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.

markiannucci 1mo ago
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.
- danielvaughn 1mo ago
  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.
zahrevsky 1mo ago
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.
- danielvaughn 1mo ago
  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.

wccrawford 1mo ago

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.