danielvaughn

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.

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.

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.

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.

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.

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.

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

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.

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.

For sure - reading LLM-generated code is extremely painful for me, and it's one of the big motivations behind this project.

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.

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

Yes, there's no language. And exactly - we're effectively already doing this, but with waaay more words.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Pushing a fix now - thanks for letting me know.

edit: fixed

I don't want to name this person because he's very nice and I don't want to make fun of him. But he's as close to AI psychosis as I've seen. He's totally non-technical, and someone set him up with Discord and OpenClaw. He has an entire "team" of agents - a CEO, a CTO, etc. What they're building, god knows what. But he just released a "podcast" interview with his CEO, setting up a secondary screen with an AI-generated face speaking into a microphone. It's absolutely insane.

The point of my comment is that it's absolutely skilled work. If someone with 15 years of experience in programming can't simply make a lateral move into a different type of programming without falling on their face, then it means there's more than just jargon. Each problem domain has its own unique nuances that humans need to tease out, and that requires domain skills.

I've been programming for 15 years, but I've never really taken the plunge into 3D work. Always wanted to. So I figure, now that coding agents are so powerful, let's see if I can make something!

I've tried 3 experiments so far, and have given it serious effort. They're all terrible.

The reason they're terrible is that it's a skill issue. I don't have 3D skills. I don't know the lingo, I don't know how to describe my problems, and I don't know when the agent is shooting itself in the foot.

Totally agree about remote work for juniors. Even as a senior I feel like it's diminished some of my skills, in spite of all the benefits it brings.

Am I the only person that loathes sidebars in browsers? Maybe it's because I've been using a browser since 1996, but my brain is deeply set in the idea that the space below the chrome 110% belongs to user space.

I've tried a few browsers with vertical tabs, and my brain keeps seeing them as part of the page itself. It's a very distracting and uncomfortable experience.