Writing Code Was Never the Bottleneck • Hacker News Board

Re: Writing Code Was Never the Bottleneck

#241

Post by bluefirebrand » Thu, Jul 03, 2025, 1:54 PM UTC

exe34 wrote: post #208

gyesxnuibh wrote: post #198

Earlier quoted context omitted.

Does that work as well with non-strangers who are your coworker? I'm not sure. Also if you're organizationally changing the culture to force people to put more effort in writing the code, why are you even organizationally using LLMs...?

> Does that work as well with non-strangers who are your coworker? I'm not sure. I imagine if you have a say in their performance review, you might be able to set "writes code more thoughtfully" as a PIP?

No, because that's not measurable

Re: Writing Code Was Never the Bottleneck

#242

Post by thfuran » Thu, Jul 03, 2025, 1:55 PM UTC

Sammi wrote: post #79

dizhn wrote: post #53

Earlier quoted context omitted.

> - 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.

>We're going to be swimming in an ocean of bad software

I think we already are. We're about to be drowning in a cesspit. The support for the broken software is going to be replaced by broken LLM agents.

Re: Writing Code Was Never the Bottleneck

#243

Post by peterldowns » Thu, Jul 03, 2025, 1:56 PM UTC

tomasreimers wrote: post #231

I've felt like a broken record the past few weeks, but this. Authoring has never been the bottle neck, the same way my typing speed has never been the bottle neck. The bottle neck has been, and continues to be, code review. It was in our pitch deck 4 years ago; it's still there. For most companies, by default, it's a process that's synchronously blocked on another human. We need to either make it async (stacking) or…

Hey Tomas, been a while! I like the approach that graphite is taking to AI code review — focus on automating the “lint” or “hey this is clearly wrong” or “you probably wanted to not introduce a security flaw here” type stuff, so that humans can focus on the more important details in a changeset. As your AI reviewers take on more tasks, have your answers to your question (“why do we do code review”) changed at all?

Re: Writing Code Was Never the Bottleneck

#244

Post by gortok » Thu, Jul 03, 2025, 1:59 PM UTC

aleph_minus_one wrote: post #137

gortok wrote: post #94

Earlier quoted context omitted.

Developers have always loved the new and shiny. Heck, getting developers not to rewrite an application in their new favorite framework is a tough sell. LLM “vibe coding” is another continuation of this “new hotness”, and while the more seasoned developers may have learned to avoid it, that’s not the majority view. CEOs and C-suites have always been disconnected from the first order effects of their cost-cutting edict…

> Heck, getting developers not to rewrite an application in their new favorite framework is a tough sell. This depends a lot on the "programming culture" from which the respective developers come. For example, in the department where I work (in some conservative industry) it would rather be a tough sell to use a new, shiny framework because the existing ("boring") technologies that we use are a good fit for the work…

I agree.

In the Venn diagram of the programming culture of the companies that embrace vibe coding and the companies whose developers like to rewrite applications when a new framework comes out is almost a perfect circle, however.

Re: Writing Code Was Never the Bottleneck

#245

Post by kazinator » Thu, Jul 03, 2025, 2:00 PM UTC

There are times when writing the code is a bottleneck. It's not everyday code. You don't quite know how to write the code. Whatever you try breaks somehow, and you don't readily understand how, even though it is deterministic and you have a 100% repro test case.

An example of this is making changes to a self-hosting compiler. Due to something you don't understand, something is mistranslated. That mistranslation is silent though. It causes the compiler to mistranslate itself. That mistranslated compiler mistranslates something else in a different way, unrelated to the initial mistranslation. Not just any something else is mistranslated, but some rarely occurring something else. Your change is almost right: it does the right thing with numerous examples, some of them complicated. Making your change in the 100% correct way which doesn't cause this problem is like a puzzle to work out.

LLM AI is absolutely worthless in this type of situation because it's not something you can wing from the training data. It's not a verbal problem of token manipulation. Sure, if you already know how to code this correctly, then you can talk the LLM through it, but it could well be less effort just to do the typing.

However, writing everyday, straightforward code is in fact the bottleneck for every single one of the LLM cheerleaders you encounter on social networks.

Re: Writing Code Was Never the Bottleneck

#246

Post by bluefirebrand » Thu, Jul 03, 2025, 2:00 PM UTC

jameshart wrote: post #138

thisoneisreal wrote: post #39

Earlier quoted context omitted.

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…

Evaluating written artifacts is broken in education because the end goal of education is not the production of written artifacts - it is the production of knowledge in someone’s mind and the artifacts were only intended to see if that knowledge transfer had occurred. Now they no longer provide evidence of that. A ChatGPT written essay about the causes of the civil war is not of any value to a history professor, since…

> We care a lot less about whether or not the developer has a particular understanding of the world

We actually should because the developer has to maintain and extend the damned thing in the future

Re: Writing Code Was Never the Bottleneck

#247

Post by bluefirebrand » Thu, Jul 03, 2025, 2:02 PM UTC

stuartjohnson12 wrote: post #38

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…

In the medium term I think you have to shift the work upstream to show that they've put in the labour to actually design the feature or the bug fix. I think we've always had this mental model which needs to change that senior engineers and product managers scope and design features, IC developers (including juniors for simpler work) implement them, and then senior engineers participate in code review. Right now I can…

> I don't think they are employable right now

Well that sucks because that just means the pipeline for engineers to become seniors is completely broken

Re: Writing Code Was Never the Bottleneck

#248

Post by Henchman21 » Thu, Jul 03, 2025, 2:03 PM UTC

hn_throwaway_99 wrote: post #237

Sammi wrote: post #79

Earlier quoted context omitted.

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.

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.

Re: Writing Code Was Never the Bottleneck

#249

Post by viraptor » Thu, Jul 03, 2025, 2:05 PM UTC

dizhn wrote: post #53

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

> They did not spend one second beyond the spec sheet and none of the common sense things that "follow" from the spec were there.

That's how lots of the early outsourced projects ended up. Perfectly matching the spec and not working.

> The whole thing was scrapped immediately.

And that's how it ended up too. everything old is new again.

Re: Writing Code Was Never the Bottleneck

#250

Post by fhd2 » Thu, Jul 03, 2025, 2:11 PM UTC

imiric wrote: post #116

fhd2 wrote: post #93

Earlier quoted context omitted.

In my experience, it was. And if we're getting real for a moment, the vast majority of programmers gets paid by a company that is, first and foremost, interested in making more money. IMHO all technical decisions are business decisions in disguise. Can the business afford to ship something that fails for 5% of their users? Can they afford to find out before they ship it or only after? What risks do they want to take?…

I agree with your sentiment, but not with the conclusion. Sure, technical decisions ultimately depend on a cost-benefit analysis, but the companies who follow this mentality will cut corners at every opportunity, build poor quality products, and defraud their customers. The unfortunate reality is that in the startup culture "move fast and break things" is the accepted motto. Companies can be quickly started on empty…

Tech and product are just small components in what makes the business profitable. And often not as central as we in our industry might _like_ to believe. From my perspective, building software is the easy, the fun part. Many bets made have nothing to do with the software.

And yes, there is enshittification, there is immoral actors. The market doesn't solve these problems, if anything, it causes them.

What can solve them? I have only two ideas:

1. Regulation. To a large degree this stops some of the worst behaviour of companies, but the reality in most countries I can think of is that it's too slow, and too corrupt (not necessarily by accepting bribes, also by wanting to be "an AI hub" or stuff like that) to be truly effective.

2. Professional ethics. This appears to work reasonably well in medicine and some other fields, but I have little hope our field is going to make strides here any time soon. People who have professional ethics either learn to turn it off selectively, or burn out. If you're a shady company, as long as you have money, you will find competent developers. If you're not a shady company, you're playing with a handicap.

It's not all so black and white for sure, so I agree with you that there's _some_ power in choosing who to work for. They'll always find talent if they pay enough, but no need to make it all too easy for them.