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 yo…
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…
I'm going back to coding by hand
31–40 of 54 posts
Re: I'm going back to coding by hand
#32Earlier quoted context omitted.
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 doin…
So do you make the LLM restrict its output to small, individually-reviewable chunks per PR?
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.
Re: I'm going back to coding by hand
#33Forget all the technology involved. One of them is yours, you made it and know it. The other one is something you bought.
Quite literally, something phoned in.
Re: I'm going back to coding by hand
#34Re: I'm going back to coding by hand
#35But I think it's really about finding the right abstraction. As a staff or principle engineer in the beforetimes, I also didn't understand most of the code being written by the org. I dove in where needed, but more importantly I found the right layer to understand what was going on - dependencies between teams and services, data flows and data models, etc. And where I found myself most effective was when I was shaping and understanding those effectively.
Re: I'm going back to coding by hand
#36Re: I'm going back to coding by hand
#37Re: I'm going back to coding by hand
#38> I changed some variable names and I had to chase down all the places they were referenced, $ find . -name '*.c' -exec perl -i -pe 's/\btheOldName\b/theNewName/g' \{} \;
Any half decent IDE will change them automatically for you, no need to chase them down. Just look at the git diff if you want to see where things changed.
It's long been my experience that that only works with high-level languages (specifically, those with bytecode), not C (especially once symbols are generated from macros). (OTOH, i've not touched an IDE in well more than 10 years.)
Also, it's long been my experience that any half-decent IDE is still a pale shadow of Emacs.
Re: I'm going back to coding by hand
#39Earlier quoted context omitted.
Any half decent IDE will change them automatically for you, no need to chase them down. Just look at the git diff if you want to see where things changed.
Yeah this is a very very common and fundamental operation in programming. Always use the “refactor” tool in your IDE instead of trying to change every instance of a variable name by hand. It’s like using a linter: you do it because it’s the right thing to do and doing it without the tool confers no benefit and is prone to error.
That _is_ the refactoring tool in my IDE (emacs). i demonstrated replacing _all_of them at once, not replacing them each by hand.
> ... because it’s the right thing to do and doing it without the tool confers no benefit and is prone to error.
There was nothing in my post done "without the tool." Shell/find/perl _is_ the tool for C refactoring, and has been for decades.