Live data from Hacker News

Writing Code Was Never the Bottleneck

ordep.dev

71–80 of 400 posts

Re: Writing Code Was Never the Bottleneck

#71
post #47

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…

Well said. That has been my experience as well, but from the perspective of using these tools on my own. Sure, I can now generate thousands of lines of code relatively quickly, but the hard part is actually reviewing the code to ensure that it does what I asked, fix bugs, hunt for security issues, refactor, simplify and remove code, and so on. I've found that it's often much more productive to write the code myself,…

> I suspect that the majority of the people who claim that these tools are making them more productive are simply skipping these tasks altogether

I think that's probably true, but I think there are multiple layers here.

There's what's commonly called vibe coding, where you don't even look at the code.

Then there's what I'd call augmented coding, where you generate a good chunk of the code, but still refactor and generally try to understand it.

And then there's understanding every line of it. For this, in particular, I don't believe LLMs speed things up. You can get the LLM to _explain_ every line to you, but what I mean is to look at documentation and specs to build your understanding and test out fine grained changes to confirm it. This is something you naturally do while writing code, and unless you type comically slow, I'm not convinced it's not faster this way around. There's a very tight feedback loop when you are writing and testing code atomically. In my experience, this prevents an unreasonable amount of emergencies and makes debugging orders of magnitude faster.

I'd say the bulk of my work is either in the second or the third bucket, depending on whether it's production code, the risks involved etc.

These categories have existed before LLMs. Maybe the first two are cheaper now, but I've seen a lot of code bases that fall into them - copy pasting from examples and SO. That is, ultimately, what LLMs speed up. And I think it's OK for some software to fall into these categories. Maybe we'll see too much fall into them for a while. I think eventually, the incredibly long feedback cycles of business decisions will bite and correct this. If our industry really flies off the handle, we tend to have a nice software crisis and sort it out.

I'm optimistic that, whatever we land on eventually, generative AI will have reasonable applications in software development. I personally already see some.

Re: Writing Code Was Never the Bottleneck

#72
post #53

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 w…

Cheap labor with low EI is/has been what will suffer most from generative AI.

Re: Writing Code Was Never the Bottleneck

#73
I will disagree with the author.

If you look from the lenses of BigTech and corporations, yes code was not a bottleneck.

But, if you look from the perspective of startups, rigorous planning was because resources to produce features were limited, which means producing a working code was a bottleneck, because in small teams you don't have coordination overhead, idea and vision is clear for them -> to produce something they have discussed and agreed on already.

My takeaway is, when discussing broad topics like usefulness of AI/LLM, don't generalize your assumptions. Code was bottleneck for some, not for others

Re: Writing Code Was Never the Bottleneck

#74

The difference between a hobbyist who codes and a professional is all of the things listed in this article. As someone who shamefully falls more in the hobbyist camp, even when they code in the workplace, and has always wanted to cross what I perceived as a chasm, I’m curious, where did most people who code for a living learn these skills?

years of experience and iterations

Re: Writing Code Was Never the Bottleneck

#75
post #64

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 guess answering "you obviously didn't write it, please redo" is not an option, because then you are the dinosaur hindering company's march towards the AI future?

You also are never 100% sure if they wrote it

Re: Writing Code Was Never the Bottleneck

#76

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 have a team that’s somewhat junior at a big company. We pretty much have everyone “vibe plan” significantly more than vibe code. - you need to think through the product more, really be sure it’s as clarified as it can be. Everyone has their own process, but it looks like rubber ducking, critiquing, breaking work into phases, those into tasks, etc. (jobs to be done, business requirement docs, domain driven design pl…

I pray for whoever has to review code you didn't bother writing

Re: Writing Code Was Never the Bottleneck

#77

Even without LLMs, we were approaching a point of saturation where software development was bottlenecked by market demand and funding, not by a shortage of code. Our tooling has become so powerful that the pure act of programming is secondary. It's a world away from when the industry began. There's a great story from Bill Gates about a time when his ability to simply write code was an incredibly scarce resource. A co…

On a tangential note... This type of problem is very relevant for "impact of ai" estimates.

I think we have a tendency to overestimate efficiency... because of the central roles it plays at the margins that mattered to us at any given time. .

But the economy is bottlenecked in complex ways. Market demand, money, etc.

It's not obvious that 100X more code is something we can use.

Re: Writing Code Was Never the Bottleneck

#78
post #71
post #47

Earlier quoted context omitted.

Well said. That has been my experience as well, but from the perspective of using these tools on my own. Sure, I can now generate thousands of lines of code relatively quickly, but the hard part is actually reviewing the code to ensure that it does what I asked, fix bugs, hunt for security issues, refactor, simplify and remove code, and so on. I've found that it's often much more productive to write the code myself,…

> I suspect that the majority of the people who claim that these tools are making them more productive are simply skipping these tasks altogether I think that's probably true, but I think there are multiple layers here. There's what's commonly called vibe coding, where you don't even look at the code. Then there's what I'd call augmented coding, where you generate a good chunk of the code, but still refactor and gene…

If you are writing code to solve a one off task the first category is ok.

What boggles my mind is people are writing code that’s the foundation of products like that.

Maybe it’s imposter syndrome though to think it wasn’t already being done before the rise of LLMs

Re: Writing Code Was Never the Bottleneck

#79
post #53

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 w…

I'm expecting to see so much more poor quality software being made. We're going to be swimming in an ocean of bad software.

Good experienced devs will be able to make better software, but so many inexperienced devs will be regurgitating so much more lousy software at a pace never seen before, it's going to be overwhelming. Or as the original commenter described, they're already being overwhelmed.

Re: Writing Code Was Never the Bottleneck

#80
This resonates a little, it's problems that you need to consider... When I quit smoking I noticed my code quality dropped. It wasn't because I missed the cigarettes, it was the mental break with a solid social excuse I was missing. I started taking smoke breaks, without the smoke and things returned to normal.
Post reply on HN