sbloz

I agree with the conclusion of this, I think, but the consequences are more interresting. One of the biggest problems with this flood of apps and products is curation. For the things that "deserve to exist" how does anyone find them among the sea of slop? I don't think there's a good solution, at least one that exists today. Look at Steam, Netflix, Youtube, Amazon or really anything else. How do you find what's good? For me, most of the time, I just return to what I know. But that doesn't seem ... healthy?

I disagree that consuming content in a field is not enough to build taste. I'd argue it's actually better than creating, simply due to scale. 1:1 sure, creating something will give you more "taste" than consuming something. But it's not 1:1. Creating takes so long. And creating mixes design and implementation. When you're implementing, most of the time, you aren't building taste.

As far as creating quality things goes, and "the wall", doing it well becomes a practical problem. Writing code for example forces you to think deeply about what your building, what it does, and how it works. You can do that without writing code, you're just no longer forced to. It's not an intrinsic problem. It's just a nice side effect of coding that you lose, and need to figure out how to compensate for.

Thanks for trying it and thanks for the feedback! It's very helpful. I think I should restructure the tutorial into a bit more of a "worksheet". That way you have some more guidance and space to experiment with just the operations. The tutorial is too long right now.

Do you think the overall scoring, the per operation score, or both are too opaque? I tried to give clear visibility into the per opperation scoring. But the per puzzle scoring does need more attention. I want to reward both being smart short solutions and clever long solutions, so right now it's just an unhappy compromise.

I was hoping solutions would be sort of "personal". Share the interesting connections you came up with and different ways you think about words.

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.