Live data from Hacker News

Writing Code Was Never the Bottleneck

ordep.dev

281–290 of 400 posts

Re: Writing Code Was Never the Bottleneck

#282
> LLMs reduce the time it takes to produce code, but they haven’t changed the amount of effort required to reason about behavior, identify subtle bugs, or ensure long-term maintainability.

I'd argue that they're slowly changing that as well -- you can ask an LLM to "read" code, summarize / review / criticize it. At the least, it can help accelerate onboarding onto new / unfamiliar codebases.

Re: Writing Code Was Never the Bottleneck

#283
post #172
post #144

Earlier quoted context omitted.

As participant in many kinds of similar projects, lets put it this way, the crew already knows that the ship has a few holes while at the harbour, but captain decides for sailing anyway. Eventually you will find yourself on deep waters, with the ship lower than it should be, routinely taking out buckets of water, whishing for the nearest island, only to repair ship with whatever is on that island, and keep sailing to…

This almost seems to be a weird artefact of capitalism. Ive worked on several projects which at some point became obviously doomed to almost everybody in the trenches but management/investors/owners kept believing. Perception of reality did not permeate the class divide. I wish I could make $$$ off this insight somehow but im not sure it's possible.

> This almost seems to be a weird artefact of capitalism.

I don't see how this would be causally linked to capitalism in any meaningful way.

Re: Writing Code Was Never the Bottleneck

#284

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…

Code review has become the new bottleneck, since it’s the layer that prevents sloppy AI-generated code from entering the codebase. One thing I do that helps clean things up before I send a PR is writing a summary. You might consider encouraging your peers to do the same. ## What Changed? Functional Changes: - New service for importing data - New async job for dealing with z. Non-functional Changes: - Refactoring of C…

Ha. Almost always when I see PRs with such summaries I can assume that both the summary and the code has been AI-generated.

PRs in general shouldn't require elaborate summaries. That's what commit messages are for. If the PR includes many commits where a summary might help, then that might be a sign that there should be multiple PRs.

Re: Writing Code Was Never the Bottleneck

#285

Earlier quoted context omitted.

I'm showing my age, but this is almost exactly analogous to the rise of Visual Basic in the late nineties. The promise then was similar: "non-programmers" could use a drag-and-drop, WYSIWYG editor to build applications. And, IMO, VB was actually a good product. The problem is that it attracted "developers" who were poor/inexperienced, and so VB apps developed a reputation for being incredibly janky and bad quality. T…

We turned our back on VB. Do we have the collective will to turn our back on AI? If so I suspect it’ll take a catalyzing event for it to begin. My hunch tells me no, no we don’t have the will.

Fwiw I honestly think it was a mistake to turn our back on vb.

Yes there were a lot of crappy barely functioning programs made in it. But they were programs that wouldn’t have existed otherwise. Eg. For small businesses automating things vb was amazing and even if the program was barely functional it was better than nothing.

Re: Writing Code Was Never the Bottleneck

#286

Earlier quoted context omitted.

> Maybe it’s imposter syndrome though to think it wasn’t already being done before the rise of LLMs It may well have been happening before the rise of LLMs, but the volume was a lot more manageable Now it's an unrestricted firehose of crap that there just not enough good devs to wrangle

Would be interesting to look at the real world impact of the rise of outsourcing coding to the cheapest lowest skilled overseas body shop en mass, around the 2000s. Or the impact of trash version of commodified products flooding Amazon. The volume here is orders of magnitude greater, but that’s the closest example I can think of.

> Would be interesting to look at the real world impact of the rise of outsourcing coding to the cheapest lowest skilled overseas body shop en mass, around the 2000s.

Tech exec here. It is all about gamed metrics. If the board-observed metric is mean salary per tech employee, you'll get masses of people hired in india. In our case, we hire thousands in India. Only about 20% are productive, but % productive isnt the metric, so no one cares. You throw bodies at the problem and hope someone solves it. Its great for generations of overseas workers, many of whom may not have had a job otherwise. You probably have dozens of Soham Parekhs .

Western execs also like this because it inflates headcount, which is usually what exec comp is based on "i run a team of 150.." Their lieutenants also like it because they can say "i run a team of 30", as do their sub-lieutenants "i run a team of 6"

Re: Writing Code Was Never the Bottleneck

#287

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…

> Writing code was the bottleneck years ago.

No it wasn't. It never was.

Re: Writing Code Was Never the Bottleneck

#288

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…

Struggling with the same issues with junior developers. I've been asking for an implementation plan and iterating on it. Typical workflow is to commit the implementation plan and review it as part of a pr. It takes 2-3 iterations to get right. Then the developer asks claude code to implement the based on the markdown. I've seen good results with this.

Another thing I do is ask for the claude session log file. The inputs and thought they provided to claude give me a lot more insight than the output of claude. Quite often I am able to correct the thought process when I know how they are thinking. I've found junior developers treat claude like a sms - small ambiguous messages with very little context, hoping it would perform magic. By reviewing the claude session file, I try to fix this superficial prompting behaviour.

And third, I've realized claude works best of the code itself is structured well and has tests, tools to debug and documentation. So I spend more time on tooling so that claude can use these tools to investigate issues, write tests and iterate faster.

Still a far way to go, but this seems promising right now.

Re: Writing Code Was Never the Bottleneck

#289

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…

These tools seem to work for accelerating seniors, not well for juniors. How are juniors supposed to learn if the aren’t doing?

Re: Writing Code Was Never the Bottleneck

#290

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.

LLMs help me at work writing one-off scripts where I can verify they're behaving correctly. Or I'll give it a few lines of code where I don't like how they read and ask it if there's a cleaner way to write it, i.e. if there's maybe an API or method on a class that I'm forgetting/didn't know about, and I can understand its suggestion for a rewrite.

But getting it to spit out hundreds or even thousands of lines of code and then just happy path testing and shipping is insane.

I'm really concerned about software quality heading into the future.

Post reply on HN