It's a common complaint that people lose control of their codebase using LLMs. It always strikes me as odd, because this is a choice you make when you use the tool.
You don't have to just give it a task, let it do whatever it wants, then accept the result. You can tell it how to do things. You can read the changes. You can ask it to do things differently.
You choose to relinquish all control and then complain that you don't like not being in control. It's all about the level of involvement you choose for yourself. It's not all or nothing, you don't have to go full vibe coder it's a spectrum and you choose where you want to be on that spectrum.
Even with manual reviewing, most of its changes will look relatively reasonable when approving every chunk... until you come across one that doesn't, and then it'll be a neverending chain of 'wait why tf does it do this? Why does it work this way?'
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.
I don't think anyone chooses to relinquish all control from a project they've worked hard on. It's a slippery slope. You start with allowing it to help out a tiny bit, being in control and understanding the code the LLM writes, and then you become more confident in the results, and you trust it, and you don't read every line, and before long its refactoring an entire file by itself and you're not reading it.
And then you look up one day and you don't recognise the codebase
I'm able to avoid slipping down that slope, just don't be lazy. If you look up one day and don't recognize the codebase that's because you haven't actually looked at it in a long time. Obviously when you don't pay attention you miss things. Just pay attention, it's not hard. There's plenty of time for it while Claude or whatever is working through stuff for you.
I agree and I keep control, but I'm pretty sure AI is not faster than no-AI when I keep control. By the time I know what changes I want and how and instruct it how to do that and it thinks and I review the output, I could have written it.
For me it's insanely much faster. Maybe 5-10x depending on the task.
One thing I do is try to keep prompting. I do take time to look at the code and think if I need it, but when I'm unsure of what to do I use the LLM to help me work through it. Here is a problem, I'm not sure whether to do x or y or something else, what do you think?
It will reason around the issue and generally come up with some good suggestions. If I'm not happy I'll just talk to it further, explain what I don't like etc until we get to something I'm happy with.
I try to avoid being super specific and spending tons of time on prompts, rather I give it a vague description of what I want and ask it to plan the change, then I review the plan which will usually be pretty close, explain what I want different and when I'm happy I tell it to do it.
I do think it helps a lot that I've already put in a lot of work to build a clean and consistent application, for many problems there is already a ready-made solution. The core architecture is already there so mostly it just expands on it.
Comments
It's a common complaint that people lose control of their codebase using LLMs. It always strikes me as odd, because this is a choice you make when you use the tool.
You don't have to just give it a task, let it do whatever it wants, then accept the result. You can tell it how to do things. You can read the changes. You can ask it to do things differently.
You choose to relinquish all control and then complain that you don't like not being in control. It's all about the level of involvement you choose for yourself. It's not all or nothing, you don't have to go full vibe coder it's a spectrum and you choose where you want to be on that spectrum.
Even with manual reviewing, most of its changes will look relatively reasonable when approving every chunk... until you come across one that doesn't, and then it'll be a neverending chain of 'wait why tf does it do this? Why does it work this way?'
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.
Honestly, this is less of a problem with LLMs than with some colleagues I've had.
I don't think anyone chooses to relinquish all control from a project they've worked hard on. It's a slippery slope. You start with allowing it to help out a tiny bit, being in control and understanding the code the LLM writes, and then you become more confident in the results, and you trust it, and you don't read every line, and before long its refactoring an entire file by itself and you're not reading it.
And then you look up one day and you don't recognise the codebase
I'm able to avoid slipping down that slope, just don't be lazy. If you look up one day and don't recognize the codebase that's because you haven't actually looked at it in a long time. Obviously when you don't pay attention you miss things. Just pay attention, it's not hard. There's plenty of time for it while Claude or whatever is working through stuff for you.
I agree and I keep control, but I'm pretty sure AI is not faster than no-AI when I keep control. By the time I know what changes I want and how and instruct it how to do that and it thinks and I review the output, I could have written it.
For me it's insanely much faster. Maybe 5-10x depending on the task.
One thing I do is try to keep prompting. I do take time to look at the code and think if I need it, but when I'm unsure of what to do I use the LLM to help me work through it. Here is a problem, I'm not sure whether to do x or y or something else, what do you think?
It will reason around the issue and generally come up with some good suggestions. If I'm not happy I'll just talk to it further, explain what I don't like etc until we get to something I'm happy with.
I try to avoid being super specific and spending tons of time on prompts, rather I give it a vague description of what I want and ask it to plan the change, then I review the plan which will usually be pretty close, explain what I want different and when I'm happy I tell it to do it.
I do think it helps a lot that I've already put in a lot of work to build a clean and consistent application, for many problems there is already a ready-made solution. The core architecture is already there so mostly it just expands on it.