In a professional setting, I agree 100%, no notes. Where LLMs have helped me the most are actually side projects. There, writing the code is absolutely the bottleneck - I literally can't (or perhaps won't is more truthful) allocate enough time to write code for the little apps I've thought of to solve some small problem.
Writing Code Was Never the Bottleneck
351–360 of 400 posts
Re: Writing Code Was Never the Bottleneck
#352Guess what X + Y + Z + T ... in aggregate are the bottleneck, and LLMs pretty much speed up the whole operation :)
So pretty pointless and click-baity article & title, if you ask me.
Re: Writing Code Was Never the Bottleneck
#353Earlier quoted context omitted.
There was also a review of that code about a week later [0] which highlights the problems with LLM-generated code. Even looking strictly at coding, the hard thing about programming is not writing the code. It is understanding the problem and figuring out an elegant and correct solution, and LLM can't replace that process. They can help with ideas though. [0] https://news.ycombinator.com/item?id=44215667
> There was also a review of that code about a week later [0] which highlights the problems with LLM-generated code. Not really. This "review" was stretching to find things to criticize in the code, and exaggerated the issues he found. I responded to some of it: https://news.ycombinator.com/item?id=44217254 Unfortunately I think a lot of people commenting on this topic come in with a conclusion they want to reach. It…
I won't say that you have converted me, but maybe I'll give LLMs a shot and judge for myself if they can be useful to me. Thanks, and good luck!
Re: Writing Code Was Never the Bottleneck
#354Earlier quoted context omitted.
No, because that's not measurable
It's measurable in the number of times you have to spend >x minutes to help them go through something they should have written up by themselves. You can count the number of times you have to look at something and tell them "do it again, but without LLM this time". At some point you fire them.
Re: Writing Code Was Never the Bottleneck
#355Earlier quoted context omitted.
> Does that work as well with non-strangers who are your coworker? Yeah, OK, I guess you have to be a bit less unapologetic than Linux kernel maintainers in this case, but you can still shift the culture towards more careful PRs I think. > why are you even organizationally using LLMs Many people believe LLMs make coders more productive, and given the rapid progress of gen AI it's probably not wise to just dismiss thi…
My point in that second question was: Is the human challenge of getting a lot of inexperienced engineers to fully understand the LLM output actually worth the time, effort and money to solve vs sticking to solving the technical problems that you're trying to make the LLM solve? Usually organizational changes are massive efforts. But I guess hype is a hell of an inertia buster.
Re: Writing Code Was Never the Bottleneck
#356Re: Writing Code Was Never the Bottleneck
#357Earlier quoted context omitted.
There was also a review of that code about a week later [0] which highlights the problems with LLM-generated code. Even looking strictly at coding, the hard thing about programming is not writing the code. It is understanding the problem and figuring out an elegant and correct solution, and LLM can't replace that process. They can help with ideas though. [0] https://news.ycombinator.com/item?id=44215667
> There was also a review of that code about a week later [0] which highlights the problems with LLM-generated code. Not really. This "review" was stretching to find things to criticize in the code, and exaggerated the issues he found. I responded to some of it: https://news.ycombinator.com/item?id=44217254 Unfortunately I think a lot of people commenting on this topic come in with a conclusion they want to reach. It…
Like his first argument was that you didn't have a test case covering every single MUST and MUST NOT in the spec?? I would like to introduce him to the real world - but more to the point, there was nothing in his comments that specifically dinged the AI, and it was just a couple pages of unwarranted shade that was mostly opinion with 0 actual examples of "this part is broken".
> Unfortunately I think a lot of people commenting on this topic come in with a conclusion they want to reach. It's hard to find people who are objectively looking at the evidence and drawing conclusions with an open mind.
Couldn't agree more, which is why I really appreciated the fact that you went to the trouble to document all of the prompts and make them publicly available.
Re: Writing Code Was Never the Bottleneck
#358Earlier quoted context omitted.
I pray for whoever has to review code you didn't bother writing
Everyone is responsible for what they deliver. No one is shipping gluttonous CLs, because no one would review them. You still have to know and defend your work. Not sure what to tell you otherwise. The code is much more thought through, with more tests, and better docs. There’s even entire workflows for the CI portion and review. I would look at workflows like this as augmentation than automation.
What this actually means is that your manager gets a raise when the AI written code works, and you get fired when it inevitably breaks horribly. You also get fired if you do not use AI written code
Re: Writing Code Was Never the Bottleneck
#359Earlier quoted context omitted.
The thing is that a "very high standard" is not a measurable criterion. The project can have test coverage requirements and strict linting to catch basic syntax and logic problems, but how do you enforce simplicity, correctness, robustness, or ergonomics? These are abstract concepts that are difficult to determine, even for experienced developers, so I wouldn't expect less experienced developers to consider them. A c…
The answer is simple: "a very high standard" is what the very experienced developers of the team consider to be "a very high standard". :-)
Re: Writing Code Was Never the Bottleneck
#360Earlier quoted context omitted.
Sometimes, orgs don!t mandate testing or descriptive PRs, and then you requiring it makes you look like a PITA.
PITA or senior developer that's too senior for that company? Honestly I think an organization has no say in discussions about testing or descriptive PRs, and on the other side, a decent developer does not defer to someone higher-up to decide on the quality of their work.
If you wanted software engineers to be able to hold any sort of quality line against a few trillion dollars worth of AI investment, we needed to unionize or even form a guild twenty years ago.