3 ms·

I think you're overly painting that process as a waterfall method. In reality, i think its more of a loop. You do the loop a bunch of times and the solution get

I think you're overly painting that process as a waterfall method. In reality, i think its more of a loop. You do the loop a bunch of times and the solution gets better and better. The act of coding sometimes exposes a lot more of the requirement questions you didn't even know to ask in the first few steps. So anything that can let you iterate the loop faster is good. The analogy is kind of like if you can make your compile and tests faster, its way easier to code. Because you don't just code and test at the very end, you do it as part of a thinking loop.

skydhash 1y ago
You can get a lot of stuff designed before having to start the loop, just like you can get the boilerplate code written (or use a framework), before writing any business logic. Writing code to find specs is brute-forcing the solution. Which is only useful when there's no answer or data (kinda rare in most domains). Taking some time to plan and do research can resolve a lot of inconsistency in your starting design. If you have written the code before, then you'll have to refactor even if the program is correct, because it will be a pain to maintain. In painting, even sketching is a lot of work. Which is why artists will collect references instead, mentally select the part they will extract. Once you start sketching, the end goal is always a final painting, even if you stop and redo midway. Actual prototyping is called a study and it's a separate activity.
walleeee 1y ago
> So anything that can let you iterate the loop faster is good. I think the major objection is that you only want to automate real tedium, not valuable deliberation. Letting an llm drive too much of your development loop guarantees you don't discover the things you need to unless the model does by accident, and in that case it has still trained you to be a tiny bit lazier and stolen an insight you would have otherwise had yourself, so are you really better off?
- alooPotato 1y ago
  This is a confusion that comes up often - 100% agree with chat-in-the-loop style interfaces. That slows me down way too much and its too hard to fix when it inevitably gets something wrong. I'm mostly talking about Cursor Tab - the souped up autocomplete. I think its the perfect interface, it monitors what I type and guesses my intention (multiline autocomplete, and guessing which line I'm going to next). It lets me easily parse if the LLM is heading in the right direction, in which case pressing tab speeds up the tedium. If its wrong, I just keep typing till it understands what I'm trying to do. It works really really well for me. I went back to using a non-LLM editor for a bit and I was shocked at how much I had become dependent on it. It was like having an editor that didn't understand types and didn't autocomplete function names. I guess if you're a purist and never used any IDE functionality, then this also wouldn't be for you. But for me, its so much better of an experience.
dragonwriter 1y ago
> So anything that can let you iterate the loop faster is good. That's only true if it doesn't negatively impact the value produced each iteration by enough to offset the speed improvement.All other things being equal, going yhrough the loop faster is better, but automation doesn and always keep all other things equal.

skydhash 1y ago

You can get a lot of stuff designed before having to start the loop, just like you can get the boilerplate code written (or use a framework), before writing any business logic. Writing code to find specs is brute-forcing the solution. Which is only useful when there's no answer or data (kinda rare in most domains). Taking some time to plan and do research can resolve a lot of inconsistency in your starting design. If you have written the code before, then you'll have to refactor even if the program is correct, because it will be a pain to maintain. In painting, even sketching is a lot of work. Which is why artists will collect references instead, mentally select the part they will extract. Once you start sketching, the end goal is always a final painting, even if you stop and redo midway. Actual prototyping is called a study and it's a separate activity.

walleeee 1y ago

> So anything that can let you iterate the loop faster is good. I think the major objection is that you only want to automate real tedium, not valuable deliberation. Letting an llm drive too much of your development loop guarantees you don't discover the things you need to unless the model does by accident, and in that case it has still trained you to be a tiny bit lazier and stolen an insight you would have otherwise had yourself, so are you really better off?

alooPotato 1y ago
This is a confusion that comes up often - 100% agree with chat-in-the-loop style interfaces. That slows me down way too much and its too hard to fix when it inevitably gets something wrong. I'm mostly talking about Cursor Tab - the souped up autocomplete. I think its the perfect interface, it monitors what I type and guesses my intention (multiline autocomplete, and guessing which line I'm going to next). It lets me easily parse if the LLM is heading in the right direction, in which case pressing tab speeds up the tedium. If its wrong, I just keep typing till it understands what I'm trying to do. It works really really well for me. I went back to using a non-LLM editor for a bit and I was shocked at how much I had become dependent on it. It was like having an editor that didn't understand types and didn't autocomplete function names. I guess if you're a purist and never used any IDE functionality, then this also wouldn't be for you. But for me, its so much better of an experience.

dragonwriter 1y ago

> So anything that can let you iterate the loop faster is good. That's only true if it doesn't negatively impact the value produced each iteration by enough to offset the speed improvement.All other things being equal, going yhrough the loop faster is better, but automation doesn and always keep all other things equal.