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

341–350 of 400 posts

Re: Writing Code Was Never the Bottleneck

#341

Post by lukeschlather »

ffsm8 wrote: post #87
fhd2 wrote: post #71

Earlier quoted context omitted.

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

There is also the situation in which the developer knows the tools by heart and has ownership of the codebase, hence intuitively knows exactly what has to be changed and only needs to take action. These devs don't get any value whatsoever from LLM, because explaining it to the LLM takes longer then doing it themselves. Personally, I feel like everything besides actually vibe coding + maybe sanity checking via a quick…

> These devs don't get any value whatsoever from LLM, because explaining it to the LLM takes longer then doing it themselves.

I feel like people are maybe underestimating the value of LLMs for some tasks. There's a lot of stuff where, I know how to do it but I can't remember the parameter order or the exact method name and the LLM absolutely knows. And I really get nothing out of trying to remember/look up the exact way to do something. Even when I do know, it often doesn't hurt to be like "can you give me a loop to replace all the occurrences of foo with bar in this array of strings" and I don't need to remember if it's string.replace(foo,bar), whether I need to use double or single quotes, if it's actually sub or gsub or whatever.

There's lots of tiny sub-problems that are totally inconsequential and an LLM can do for me, and I don't think I lose anything here. In fact maybe I take a little longer, I chat with the LLM about idioms a bit and my code ends up more idiomatic/more maintainable.

It kind of calls to mind something Steve Jobs said about how hotkeys are actually worse than using a mouse, and that keyboard users aren't faster, they just think they are. But using LLMs for these sorts of things feels similar in that, like using keyboard shortcuts, maybe it takes longer, but I can use muscle memory so I don't have to break flow, and I can focus on something else.

Asking the LLM for these sorts of trivial problems means I don't have to break flow, I can stay focused on the high-level problem.

Re: Writing Code Was Never the Bottleneck

#342

Post by hnaccount_rng »

wafflemaker wrote: post #318
hnaccount_rng wrote: post #299

Earlier quoted context omitted.

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

Interesting thought. Yeah.. the whole LLM-generated thing might end up being a boon. It is (reasonably) distinctive. At least for now. And rightly or wrongly it triggers defensive reflexes

Re: Writing Code Was Never the Bottleneck

#343

Post by steveBK123 »

samat wrote: post #319
ortusdux wrote: post #305

Earlier quoted context omitted.

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

I’d argue with software that the level of detail you need to specify to do a successful SOW is so much work you’d might as well then just do the dev work too.

It also cuts against all trends of iterative development in that it is like waterfall with a gun to your head to get the spec 1000% right.

Re: Writing Code Was Never the Bottleneck

#344

Post by aleph_minus_one »

imiric wrote: post #291
aleph_minus_one wrote: post #126

Earlier quoted context omitted.

Simply require from the junior developers that each pull request has to satisfy a very high standard. If they are not sure about something, they may ask, but if they send you some pull request of bad quality to review, and you find something, they deserve a (small) tantrum. It is likely not possible to completely forbid junior developers from using AI tools, but any pull request that they create that contains (AI-gen…

The thing is that a "very high standard" is not a measurable criterion. The project can have test coverage requirements and strict linting to catch basic syntax and logic problems, but how do you enforce simplicity, correctness, robustness, or ergonomics? These are abstract concepts that are difficult to determine, even for experienced developers, so I wouldn't expect less experienced developers to consider them. A c…

The answer is simple: "a very high standard" is what the very experienced developers of the team consider to be "a very high standard". :-)

Re: Writing Code Was Never the Bottleneck

#345

Post by wombatpm »

dgellow wrote: post #103
threemux wrote: post #55

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.

Agreed fully, if I have 1-2 hours a day with Claude code I end up the week with a personal project I can actually use. Or spend like half a weekend day to see if an idea makes sense. But I think that makes them invaluable in professional contexts. There is so much tooling we never have the time to write to improve stuff. Spend 1-2h with Claude code and you can have an admin dashboard, or some automation for something…

Obligatory xkcd

https://xkcd.com/1205

Re: Writing Code Was Never the Bottleneck

#346

Post by LtWorf »

danaris wrote: post #152
Sammi wrote: post #88

Earlier quoted context omitted.

Software is going to be of two types: 1. Mostly written by LLMs, and only superficially reviewed by humans. 2. Written 50-50% by devs and LLMs. Reviewed to the same degree as now. Software of type 2 will be more expensive and probably of higher quality. Type 1 software will be much much more common, as it will be cheaper. Quality will be lower, but the open question is whether it will be good enough for the use cases…

I 100% guarantee you there will be plenty of software still written fully by humans—and even more that's written 95% by humans, with minor LLM-based code autocomplete or boilerplate generation.

Especially for companies that actually have to deliver a product that works or provide support when it doesn't.

Re: Writing Code Was Never the Bottleneck

#347

Post by wombatpm »

hbn wrote: post #295
bob1029 wrote: post #176

I used to think authoring code was the bottleneck. It took a solid decade to learn that alignment of the technology to the business is the actual hard part. Even in the extreme case like a B2B/SaaS product wherein every customer has a big custom code pile. If you have the technology well aligned with the business needs, things can go very well. We have the technology to make the technology not suck. The real challeng…

> alignment of the technology to the business is the actual hard part Yup. The tough part of my job has always been taking the business requirements and then figuring out what the business ACTUALLY wants. Users will tell you what they want, but users are not designers and usually don't think past what they currently want right now. Give them exactly what they say they want and it will almost never give a good result.…

Should BOFH be a required source when training agents for interactions?

Re: Writing Code Was Never the Bottleneck

#348

Post by Tainnor »

lukeschlather wrote: post #341
ffsm8 wrote: post #87

Earlier quoted context omitted.

There is also the situation in which the developer knows the tools by heart and has ownership of the codebase, hence intuitively knows exactly what has to be changed and only needs to take action. These devs don't get any value whatsoever from LLM, because explaining it to the LLM takes longer then doing it themselves. Personally, I feel like everything besides actually vibe coding + maybe sanity checking via a quick…

> These devs don't get any value whatsoever from LLM, because explaining it to the LLM takes longer then doing it themselves. I feel like people are maybe underestimating the value of LLMs for some tasks. There's a lot of stuff where, I know how to do it but I can't remember the parameter order or the exact method name and the LLM absolutely knows. And I really get nothing out of trying to remember/look up the exact…

> There's a lot of stuff where, I know how to do it but I can't remember the parameter order or the exact method name and the LLM absolutely knows. And I really get nothing out of trying to remember/look up the exact way to do something. Even when I do know, it often doesn't hurt to be like "can you give me a loop to replace all the occurrences of foo with bar in this array of strings" and I don't need to remember if it's string.replace(foo,bar), whether I need to use double or single quotes, if it's actually sub or gsub or whatever.

I mean, I kinda get it in more complicated contexts, but the particular examples you describe (not remembering method names and/or parameter orderings) have been solved for ages by any decent IDE.

Re: Writing Code Was Never the Bottleneck

#349

Post by aforwardslash »

Henchman21 wrote: post #248
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…

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.

We didn't turn our back on VB. Microsoft killed it when it became a citizen of the .NET ecosystem; pairing C# concepts, requiring extensive code changes and an IDE that was read-only during debug (yah, you couldn't edit the code while debugging) killed the product.

Greed (wanting an enterprise alternative to Java and C++ builder) killed VB, not the community.

Re: Writing Code Was Never the Bottleneck

#350

Post by shepherdjerred »

linsomniac wrote: post #264

That is true in some cases. However, there are many cases where writing the code IS the bottleneck. Experiments, trying different approaches, well defined code. Examples: This morning Claude Code built a browser-based app that visualizes 3.8M lines of JSON dumps of AWS infrastructure. Attention required by me: 15 minutes. Results: Reasonable for a 1-shot. A few weeks ago I had it build me a client/server app in multi…

I agree. Cursor has been amazing for me to write small test/validation scripts, write tedious code that wasn't very interesting to me, or perform some experiment.

I can forget about the details and care more about architecture, how things connect, etc.

Post reply on HN