This is not a problem I've had. I know roughly what I want before I ask for it, I make sure the result is roughly what I expected. Some times if I'm not entirely sure what I want I'll ask it to plan the change or suggest some approaches etc then choose the one I prefer.
For me it works great. My judgement is that I get things done significantly faster, and generally with comparable or better quality than I would doing it manually. It's important to lay a good foundation, if you are careful with the broad strokes it helps the LLM lay the rest down more consistently. It's also a lot easier to refactor things when the need becomes apparent.
I generally prefer small increments yes but I don't shy away from larger changes where necessary. Just like everyone hated reviewing a 4000 line PR before LLMs, we all still hate it now, provided you actually do review things properly and not just tell Claude to do it or skim it lazily.
I wouldn't say I make the LLM restrict it's output, rather I'd say I just don't ask for a lot at once. If I want to create a new page in our web app I'll split it up into multiple tasks - create the new page with the required layout and add it to the navigation. Create a new component we need for this page, put it on the page so it can be tested. Create another component. Add an endpoint to the API for getting the necessary data. Use these existing components and the new ones to build the final page. At each step I test and verify that it works properly, and review the code to make sure it's reasonable. I might make several pull requests or just one depending on the size of the task and what makes sense to me. In general I want a PR to be testable, just a component isn't testable if it isn't used so it has to be used. I also don't do a PR that isn't production ready, so I won't submit a PR with just a test page.
If it's a very simple page where we have most or all necessary components I might just send a screenshot from Figma along with instructions to use existing components and what data to use, CSS variables and whatever else and have it try to one-shot it. I generally don't want a PR to have more than a few hundred lines total. I review and test the code at each step and finally I review the whole PR myself before submitting it to colleagues.
Comments
This is not a problem I've had. I know roughly what I want before I ask for it, I make sure the result is roughly what I expected. Some times if I'm not entirely sure what I want I'll ask it to plan the change or suggest some approaches etc then choose the one I prefer.
For me it works great. My judgement is that I get things done significantly faster, and generally with comparable or better quality than I would doing it manually. It's important to lay a good foundation, if you are careful with the broad strokes it helps the LLM lay the rest down more consistently. It's also a lot easier to refactor things when the need becomes apparent.
So do you make the LLM restrict its output to small, individually-reviewable chunks per PR?
I generally prefer small increments yes but I don't shy away from larger changes where necessary. Just like everyone hated reviewing a 4000 line PR before LLMs, we all still hate it now, provided you actually do review things properly and not just tell Claude to do it or skim it lazily.
I wouldn't say I make the LLM restrict it's output, rather I'd say I just don't ask for a lot at once. If I want to create a new page in our web app I'll split it up into multiple tasks - create the new page with the required layout and add it to the navigation. Create a new component we need for this page, put it on the page so it can be tested. Create another component. Add an endpoint to the API for getting the necessary data. Use these existing components and the new ones to build the final page. At each step I test and verify that it works properly, and review the code to make sure it's reasonable. I might make several pull requests or just one depending on the size of the task and what makes sense to me. In general I want a PR to be testable, just a component isn't testable if it isn't used so it has to be used. I also don't do a PR that isn't production ready, so I won't submit a PR with just a test page.
If it's a very simple page where we have most or all necessary components I might just send a screenshot from Figma along with instructions to use existing components and what data to use, CSS variables and whatever else and have it try to one-shot it. I generally don't want a PR to have more than a few hundred lines total. I review and test the code at each step and finally I review the whole PR myself before submitting it to colleagues.