sbloz

Since the author starts with a short story about AI I want to recommend one about technology and progress in general: "The Truth of Fact, the Truth of Feeling" from Exhalation by Ted Chiang.

I think about it a lot in conversations like this. The story does a much better job of telling it, so I won't summarize more than: It's a discussion about how technology changes culture and how its very hard to judge if that's a good or bad thing.

It's online https://web.archive.org/web/20140222103103/http://subterrane...

The first orchestrator I built was a kanban board that spawned a vscode session per task with a plan file in it. Nice contained way to do a chat session, you can review the files and make edits, and close it once it's done. Very slow and heavy though. So that way of working resonates with me.

For some more unsolicited feedback: if that's how you use it why not pitch it that way/ make that way of working more obvious? Bug tracking and todo's jump to mind for me. For example: I want to write a prompt to fix this bug at some point but I need to think more about it. Right now I just need a place to jot it down for now so I don't forget.

Re: collab - managing edits and other state (builds/lints/test processes) is definitely a tricky problem. "Frictionless" worktrees is an interesting idea. That often seems like the "right" solution for how I'm working but it's too annoying to do for smaller changes. Doing that well would be a reason for me to give this a try.

I see. That seems pretty similar to plan mode + "implement with subagents". The display for that in terminal apps is pretty bad, but it's low friction.

One more question around yDoc and remote access if you don't mind. Do you have thoughts on a tool like this for "LLM pair programming" or just general collaboration?

Working with teams on smaller projects with these tools is really hard because anyone can build anything. If I'm going to type up a bug or request to send to a team member to build I might as well send it to the LLM instead. A multi-user environment in a tool like this could be interesting. Seeing team members sessions in real time could be neat.

I think the mistake there was the 5 hour session specing the app. It's so hard to know what you want before you see it, so optimize towards seeing it as soon as possible. That's what I thought the article was going to be about based off the title.

Once you have something concrete you can iterate on the prototype until it's a mess. But, hopefully, in that time you got closer to figuring out what you want. And even if the code for the prototype is a mess the "idea" of it should be cleaner. I like to have an LLM make a new spec at that point, and start fresh with it. You can clean up the abstractions and the UX there.

When writing code is cheap figuring out what you want to write is the hard part. It always was, but the barrier of getting the code written and working made that less obvious.

This looks nice, and I like the more opinionated take on how "communicating" with an agent should work.

The post talks a lot about what this is and how it works. I'm curious, from your usage of it, how does it change your way of working with the LLMs? How does working with it go differently from Claude Code?

Specifically: Everything is a tree. That's interesting, but how do you end up using it? Attack the same problem different ways?

I'm also on the hands on side. The mistake that I see a lot of people making is "I can build so much now". But that doesn't mean you're building the right things. And if you're hands off you aren't really thinking about what you're trying to build, at least not deeply. I'd love to see tools that embrace optimizing for that.

I think I have the same perspective. I see it as a flavor of progressive disclosure. Sane defaults and a way to customize if needed. Start with the 80% case and let people customize if they want to. It needs to be optional.

Especially with developer tools I think there's a hesitancy to be opinionated. If you don't know for sure an option is "always correct" it seems safer to ask the user. Developers can be very pedantic. "95% of people probably want it this way, but I should make people pick because that 5% has a valid point". But now you've made it worse for most users.

It's also so much more complicated to support customization, more than I think people realize. It's not just about bugs, every option makes polishing your UX much more difficult. Both because of the testing surface and also because more flexible abstractions are harder to design.