Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing Code Was Never the Bottleneck

ordep.dev

Post reply on HN
Print view View original

51–60 of 400 posts

Re: Writing Code Was Never the Bottleneck

#51

Post by brazzy »

noelwelsh wrote: post #40

> The actual bottlenecks were, and still are, code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication. All of this wrapped inside the labyrinth of tickets, planning meetings, and agile rituals. Most of these only exist because one person cannot code fast enough to produce all the code. If one programmer was fast enough, you would not…

That hypothetical one person would not just need to produce the code, but also understand how it fulfills the requirements. Otherwise they are unable to fix problems or make changes.

If the amount of code grows without bounds and is an incoherent mess, team sizes may not, in fact, actually get smaller.

Re: Writing Code Was Never the Bottleneck

#52

Post by agumonkey »

andrelaszlo wrote: post #22

My most recent example of this is mentoring young, ambitious, but inexperienced interns. Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before: - During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "go…

Somehow interesting how this is similar to other uses of ML driven tools, like electronics engineering where solutions would be near impossible to understand for experienced engineers.

Re: Writing Code Was Never the Bottleneck

#53

Post by dizhn »

andrelaszlo wrote: post #22

My most recent example of this is mentoring young, ambitious, but inexperienced interns. Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before: - During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "go…

> - Many bugs were of a new kind (to me), the code would look like it does the right thing but actually not work at all, or just be much more broken than code with that level of "polish" would normally be.

This reminded me of a quarter million dollar software project one of my employers had contracted to a team in a different country. On the face of it - especially if you go and check by the spec sheet - everything was there but the thing was not a cohesive whole. They did not spend one second beyond the spec sheet and none of the common sense things that "follow" from the spec were there. The whole thing was scrapped immediately.

With LLMs this kind of work now basically becomes free to do and automatic.

Re: Writing Code Was Never the Bottleneck

#54

Post by zeroCalories »

thisoneisreal wrote: post #39
andrelaszlo wrote: post #22

My most recent example of this is mentoring young, ambitious, but inexperienced interns. Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before: - During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "go…

I think this is going to look a lot like the same problem in education, where the answer is that we will have to spend less time consuming written artifacts as a form of evaluation. I think effective code reviews will become more continuous and require much more checking in, asking for explanations as the starting point instead of "I read all of your code and give feedback." That just won't be sustainable given the r…

I think asking people to explain is good, but it's not scalable. I do this in interviews when I suspect someone is cheating, and it's very easy to see when they've produced something that they don't understand. But it takes a long time to run through the code, and if we had to do that for everything because we can't trust our engineers anymore that would actually decrease productivity, not increase it.

Re: Writing Code Was Never the Bottleneck

#55

Post by threemux »

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.

Re: Writing Code Was Never the Bottleneck

#56

Post by williamdclt »

kabdib wrote: post #33

my LLM win this year was to give the corporate AI my last year's worth of notes, emails and documents and ask it to write my self review. it did a great job. i'm never writing another one of those stupid bits of psychological torture again otherwise i'm writing embedded systems. fine, LLM, you hold the scope probe and figure out why that PWM is glitching

That's a really good idea, and would have the double-benefit that it would incentivise me to keep better track of information and communication, as well as take more notes, all of which certainly has various other benefits.

Re: Writing Code Was Never the Bottleneck

#57

Post by chii »

noodletheworld wrote: post #50
epolanski wrote: post #37

Earlier quoted context omitted.

> the code would look like it does the right thing but actually not work at all, or just be much more broken than code with that level of "polish" would normally be I don't understand, if they don't test the code they write (even if manually) it's not an LLM issue, it's a process one. They have not been taught what does it mean to have a PR ready for being reviewed, LLMs are irrelevant here.

How do you test edge cases? You think about the implementation and how it can fail. If you don’t think about the implementation, or don’t understand the implementation, I would argue that you can earnestly try to test, but you won’t do a good job of it. The issue of LLMs here is the proliferation of people not understanding the code they produce. Having agents or LLMs review and understand and test code may be the fu…

> pushing the burden of verification and understanding to other people.

Where was the burden prior to LLM's?

if a junior cannot prove his/her code as working and have an understanding, how was this "solved" before llm? Why can't the same methods work post-llm? Is it due to volume? If a junior produces _more_ code they don't understand, it doesn't give them the right to just skip PR/review and testing etc.

If they do, where's upper management's role here then? The senior should be bringing up this problem and work out a better process and get management buy-in.

Re: Writing Code Was Never the Bottleneck

#58

Post by khazhoux »

Yet another article trying to take away from the impact of LLMs. This one is more subtle than most, but still the message is "this problem that was solved, was never actually the problem."

Except... writing code is often a bottleneck. Yeah, code reviews, understanding the domain, etc, is also a bottleneck. But Cursor lets me write apps and tools in 1/20th the time it would take me in an area where I am an expert. It very much has removed my biggest bottleneck.

Re: Writing Code Was Never the Bottleneck

#59

Post by dakiol »

epolanski wrote: post #37
andrelaszlo wrote: post #22

My most recent example of this is mentoring young, ambitious, but inexperienced interns. Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before: - During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "go…

> the code would look like it does the right thing but actually not work at all, or just be much more broken than code with that level of "polish" would normally be I don't understand, if they don't test the code they write (even if manually) it's not an LLM issue, it's a process one. They have not been taught what does it mean to have a PR ready for being reviewed, LLMs are irrelevant here.

LLMs amplify the problem, so they are not that irrelevant.
Post reply on HN