Writing Code Was Never the Bottleneck • Hacker News Board

Re: Writing Code Was Never the Bottleneck

#311

Post by rightbyte » Thu, Jul 03, 2025, 4:44 PM UTC

Cthulhu_ wrote: post #153

gdiamos wrote: post #18

I used to think I needed to type faster. As I get older I spend more of my coding time on walks, at the whiteboard, reading research, and running experiments

Exactly; it's not about the volume of code, it's about the value of it. The best code is the code never written. Reminds me of a former colleague of mine, I'd sit next to him and get frustrated because he was a two-finger typer. But, none of his code was wasted. I frequently write code, then cmd+z back to ten minutes ago or just `git checkout .` because I lost track.

Ye. The occassions were typing speed is even remotely important are so rare. Like, when you make a totally new file or class and need to churn out the skeleton.

Re: Writing Code Was Never the Bottleneck

#312

Post by hn_throwaway_99 » Thu, Jul 03, 2025, 4:44 PM UTC

tstrimple wrote: post #300

hn_throwaway_99 wrote: post #237

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…

It's the exact same thing every time a technical bar is lowered and more people can participate in something. From having to manually produce your own film to having film processing readily available on demand to not needing to process film at all and everyone has a camera in their pocket. The number of people taking photos has absolutely exploded. The average quality of photos has to have fallen through the floor. B…

Software is a very different beast though because this crappy technical debt lives on, it often grows "tentacles" with poorly defined boundaries, people and companies come to depend on it, and then the mess must eventually be cleaned up.

Take your photos example. Sure, the number of photos taken has exploded, but who cares if there are now reams and reams of crappy vacation photos - it's not like anyone is really forced to look at it.

With AI-generated code, I think it's actually awesome for small, individual projects. And in capable hands, they can be a fantastic productivity enhancer in the enterprise. But my heart bleeds for the poor sap who is going to eventually have to debug and clean up the mountains of AI code being checked in by folks with a few months/years of experience.

Re: Writing Code Was Never the Bottleneck

#313

Post by hn_throwaway_99 » Thu, Jul 03, 2025, 4:52 PM UTC

p_v_doom wrote: post #260

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.

> Good experienced devs will be able to make better software I lowkey disagree. I think good experienced devs will be pressured to write worse software or be bottlenecked by having to deal with bad software. Depends on company and culture of course. But consider that you as expereinced dev now have to explain things that go completely over the head of the junior devs, and most likely the manager/PO, so you become the…

I think the recent post about the Cloudflare engineer who built an OAuth implementation, https://news.ycombinator.com/item?id=44159166, shows otherwise (note the Cloudflare engineer, kentonv, comments a bunch in the discussion). The author, who is clearly an expert, said it took him days to complete what would have taken him weeks or months to write manually.

I love that thread because it clearly shows both the benefits and pitfalls of AI codegen. It saved this expert a ton of time, but the AI also created a bunch of "game over" bugs that a more junior engineer probably would have checked in without a second thought.

Re: Writing Code Was Never the Bottleneck

#314

Post by epicureanideal » Thu, Jul 03, 2025, 4:54 PM UTC

bluefirebrand wrote: post #247

stuartjohnson12 wrote: post #38

Earlier quoted context omitted.

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

Sounds like we’re about to become more and more valuable over time? Hmmmm

Re: Writing Code Was Never the Bottleneck

#315

Post by teiferer » Thu, Jul 03, 2025, 4:58 PM UTC

[dead]

Re: Writing Code Was Never the Bottleneck

#316

Post by draw_down » Thu, Jul 03, 2025, 5:01 PM UTC

AshleysBrain wrote: post #123

This reminds me of the quote by Robert C. Martin[1]: "the ratio of time spent reading [code] versus writing is well over 10 to 1". If programmers spend 90%+ of their time reading code rather than writing it, then LLM-generated code is optimizing only a small amount of the total work of programming. That seems to be similar to the point this blog is making. [1] https://www.goodreads.com/quotes/835238-indeed-the-ratio-…

[dead]

Re: Writing Code Was Never the Bottleneck

#317

Post by kpen11 » Thu, Jul 03, 2025, 5:15 PM UTC

kpen11 wrote: post #298

Whether or not there was a claim that code _was_ the bottleneck, this raises some points that I've been talking over with people for a while now. Introducing a lever to suddenly produce more code faster creates an imbalance in the SDLC. If our review process was already a bottleneck, now that problem is even worse! If the review bottleneck was something we could tolerate/ignore before, that's no longer the case, we n…

I'll be digging deeper on these ideas on a webinar on the 15th if this topic is interesting to you! https://dagger.io/webinar/agentic-ci

Re: Writing Code Was Never the Bottleneck

#318

Post by wafflemaker » Thu, Jul 03, 2025, 5:23 PM UTC

hnaccount_rng wrote: post #299

AnotherGoodName wrote: post #285

Earlier quoted context omitted.

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.

Came here looking for this comment! I think we will need to find a way to communicate “this code is the result of serious engineering work and all tradeoffs have been thought about extensively” and “this code has been vibecoded and no one really cares”. Both sides of that spectrum have their place and absolutely will exist. But it’s dangerous to confuse the two

There's a simple way to communicate it. Just leave in the emoticons added in comments by the LLM.

Wrote it initially as a joke, but maybe it's not that dumb? I already do it on LinkedIn. I'm job hunting and post slop from time to time to game LinkedIn algorithms to get better positioning among other potential candidates. And not to waste anybody's time, I leave in the emotes at beginning of sentences just so people in the know know it's just slop (so as not to waste their time).

Re: Writing Code Was Never the Bottleneck

#319

Post by samat » Thu, Jul 03, 2025, 5:26 PM UTC

ortusdux wrote: post #305

steveBK123 wrote: post #127

Earlier quoted context omitted.

I dealt with a 4x as expensive statement-of-work fixed price contract that was nearshored and then subbed out to a revolving cast of characters. The SOW was so poorly specified that it was easy to maliciously comply with it, and it had no real acceptance tests. As a result legal didn't think IT would have a leg to stand on arguing with the vendor on the contract, and we ended up constantly re-negotiating on cost for…

Nailing the SOWs and acceptance test requirements is key. They can mean the difference between toxic dog food or mail trucks that last decades. https://en.wikipedia.org/wiki/2007_pet_food_recalls https://en.wikipedia.org/wiki/Grumman_LLV

We do quality outsource development for usual web/mobile stuff (yeah, it exists).

80% of our job is helping clients to figure out what do they actually need and what's reasonable to implement given current state of tech, finding that balance between ideal and realistic software, or rather negotiating it.

So expecting client to write SOWs/specifications is like expecting client to write code.

Aha, actually, I've recently seen it quite few times: people send me detailed SOW which look good, but once I try to read them to actually create an understanding of the domain logic/program in my head — it does not make any sense.

Very close to the grand-grand-parent comment about mentoring junior programmers. Now imagine they are the one paying you!

Re: Writing Code Was Never the Bottleneck

#320

Post by bloomca » Thu, Jul 03, 2025, 5:29 PM UTC

imiric wrote: post #284

diogolsq wrote: post #233

Earlier quoted context omitted.

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.

Depends on the business logic, sometimes summaries (or a short demo explanation) help a lot to understand the made tradeoffs, so the reviewer can contribute more without spending too much time. It is especially helpful if the part is somewhat isolated.

But most of the time it is not very necessary.