11–20 of 146 posts
Writing fizzbuzz requires that you understand algo + you credit card, while agent requires only your credit card. I believe most of people will pick the 2nd one.
You seem to be conflating two things: how to prompt, and how to share sessions. You can already use pseudo-code today if you want to. As for sharing, you can commit (a link to) it, use `git notes` (as I do), or a service like entire.io. I think you should work on your differentiation. The session management stuff is the greater concern, in my opinion; pseudo code is not a novelty.
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 co…
You can already retrieve the session associated with a given line of code.
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.”
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.
Earlier quoted context omitted.
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 co…
Sharing sessions means providing full visibility into what you did with the agent to the team. See https://entire.io/ or https://usegitai.com/ You can already retrieve the session associated with a given line of 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.
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”. Perso…
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 f…
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.
What about multi-file / larger changes? How would you express files being connected, imports, and exports? Or are you thinking the hz files are disposable per change?
Writing fizzbuzz requires that you understand algo + you credit card, while agent requires only your credit card. I believe most of people will pick the 2nd one.
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.
With scale problems arise.
Hmm. Interesting idea. What about multi-file / larger changes? How would you express files being connected, imports, and exports? Or are you thinking the hz files are disposable per change?
I'll be looking into multi-file stuff soon - it's an interesting can of worms to think through.