Live data from Hacker News

Writing Code Was Never the Bottleneck

ordep.dev

381–390 of 400 posts

Re: Writing Code Was Never the Bottleneck

#381

Right, we all know this. LLMs write a lot of bad code that cannot be realistically reviewed. I've even had code submitted to me by juniors which didn't make any sense. When I ask them why they did that, they say they don't know, the LLM did it. What this new trend is doing is generating a lot of noise and overhead on maintenance. The only way forward, if embracing LLMs, is to use LLMs also for the reviewing and maint…

>When I ask them why they did that, they say they don't know, the LLM did it. I can't imagine a professional software developer in a position of authority leaving that statement unchallenged and uncorrected. If a person doesn't stand behind the code they write, they shouldn't be employed. Full stop.

The person in question was a junior.

Of course I didn't approve the PR.

Re: Writing Code Was Never the Bottleneck

#382

Earlier quoted context omitted.

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

> , people and companies come to depend on it, and then the mess must eventually be cleaned up.

I have found time and again that enough technological advancement will make previously difficult things easy that when it's time to clean up the old stuff, it's not such a huge issue. Especially so if you do not need to keep a history of everything and can start fresh. This probably would not fly in a huge corp but it's fine for small/medium businesses. After all, whole companies disappear and somehow we live on.

Re: Writing Code Was Never the Bottleneck

#383

Nobody mentioned Joel Spolsky's October 2nd, 2000 article, so I'll start: https://www.joelonsoftware.com/2000/10/02/painless-functiona... Code is not a bottleneck. Specs are. How the software is supposed to work, down to minuscule detail. Not code, not unit tests, not integration tests. Just plain English, diagrams, user stories. Bottleneck is designing those specs and then iterating them with end users, listening to…

> How the software is supposed to work, down to minuscule detail. So... coding. :P

Code is a technical specification and could be any programming language, markup, terraform files, configuration, whatever.

Product Spec is written in English and in a such way that everybody can understand it without technical knowledge. Because it doesn't operate in C arrays and nuances of how queues work -- just common sense and real-life objects/entities! Then the actual code is an abstraction that takes the spec and implements it for certain architecture / scalability requirements and so on.

For example you can ask to make to-do list app. You can build it on:

- As a CLI tool

- As a UI web interface

- As an AI agent that operates entirely on voice recognition and text-to-speech as interface

A product spec can omit this "tiny" detail, code -- cannot.

Even if you specify this is Web UI to-do app in product spec, there are still tons of things to choose for developer:

- Programming language

- Cloud/Self-hosted

- Architecture (monolith/microservices/modular monolith/SOA/event-driven)

You wouldn't specify in a Product spec that to-do items has to go to an SQS queue that lambda picks up and adds them to a DB, would you? That has to be a separate technical spec document, which is simply called documentation (+actual code in the repositories).

Re: Writing Code Was Never the Bottleneck

#384
post #28
post #4

TBH, I feel like the biggest help Cursor gives me is with understanding large-ish legacy codebases. It's an excellent (& active) "rubber duck". So I'm not sure the argument holds - LLMs don't just write code.

Or is it just giving you a limited understanding but pretending it's grokked the entire codebase AND data?

But that's already way better than a physical rubber duck. That was my point.

Re: Writing Code Was Never the Bottleneck

#385
It's always nice to look at history to parallels to modern conversations, and I think it's instructive to look back at the era when software jobs were getting outsourced to overseas. Even though the cost of generating code was cheaper, and the people on the other end can participate in meetings and all that, software is still primarily done in person. Even today, several years after the pandemic and the height of remote work, many tech companies are mandating in-office policies even for software workers.

The point is that there's a human element to code that we can't even capture when working remotely with intelligent humans. LLMs will always be like a remote worker.

Re: Writing Code Was Never the Bottleneck

#386

Earlier quoted context omitted.

Could you tell which language they were coding in?

A mix, but a majority Ruby, with some shell scripts and Terraform. My gut feeling is that it would generalize to typed languages, Go, Erlang, even Haskell etc, but maybe some of them make life easier for the reviewer in some ways? What are your thoughts on that?

I've worked with some junior developers and my experience has been the same as yours. We work primarily with typed languages. With junior developers I see two ways it goes: either they write code that does not take advantage of the type system, typing everything as basic string or numeric types. On the other end of the spectrum, those who go to the extremes where they build a complicated type hierarchy with abstractions more complicated than the problem space requirements

Re: Writing Code Was Never the Bottleneck

#387
post #57

Earlier quoted context omitted.

How do you test edge cases? You think about the implementation and how it can fail. If you don’t think about the implementation, or don’t understand the implementation, I would argue that you can earnestly try to test, but you won’t do a good job of it. The issue of LLMs here is the proliferation of people not understanding the code they produce. Having agents or LLMs review and understand and test code may be the fu…

> pushing the burden of verification and understanding to other people. Where was the burden prior to LLM's? if a junior cannot prove his/her code as working and have an understanding, how was this "solved" before llm? Why can't the same methods work post-llm? Is it due to volume? If a junior produces _more_ code they don't understand, it doesn't give them the right to just skip PR/review and testing etc. If they do,…

> Why can't the same methods work post-llm?

>> If you don’t think about the implementation, or don’t understand the implementation, I would argue that you can earnestly try to test, but you won’t do a good job of it.

Previously the producers of the code were competent to test it independently.

This increasingly, to my personal observation, appears to no longer be the case.

They do test it, they just dont think about it deeply and so they do a shit job of testing it, and an incompetent job of writing tests for it.

Not by being lazy; smart diligent folk doing a bad job because they didn't actually understand what needed to be tested, and tested some irrelevant trivial happy path based on the requirements not the implementation.

Thats what LLMs give you.

Its not a process issue; its people earnestly thinking they've done a good job when they havent.

Re: Writing Code Was Never the Bottleneck

#388

Earlier quoted context omitted.

I work alone, not in teams, but use LLM (codex-1) a lot, and it's extremely helpful. I accepted that in return the code base is much lower quality than if I would have written it. What works for me is that after having lots of passing tests, I start refactoring the tests to get closer to property testing: basically prove that the code works by allowing it to go through complex scenarios and check that the state is go…

I wonder how this trade-off will age. I'm not a Mag7/Saas/SV startup tech guy, so I've tended to work on systems that are in service & maintained for upwards of 10 years. It's not unusual to see 20 year old codebases in my field. We scoff at clever code thats hard to understand leading to poor ability for teams to maintain, but what about knowingly much lower quality code?

In startups there's no real plan to even live that long. Many of them just exist to con investors.

So it's not so important.

Re: Writing Code Was Never the Bottleneck

#389

Earlier quoted context omitted.

I wonder how this trade-off will age. I'm not a Mag7/Saas/SV startup tech guy, so I've tended to work on systems that are in service & maintained for upwards of 10 years. It's not unusual to see 20 year old codebases in my field. We scoff at clever code thats hard to understand leading to poor ability for teams to maintain, but what about knowingly much lower quality code?

When the price of building becomes low, you just toss it and build more. Much like Ikea's low cost replaceable furniture has replaced artisan, hand made furniture and cheap plastic toys have replaced finely made artifacts. LLM produced code is cheap and low effort; meant to be discarded. In recognizing this, then it should be used where you have this in mind. You might still buy a finely made sofa because it's high t…

Ikea has a lot of hardwood stuff that will last longer than you and your progeny…

Re: Writing Code Was Never the Bottleneck

#390

Earlier quoted context omitted.

> - 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 "good catch, I'll fix that" (also reminiscent of an LLM). Would you mind drilling down into this a bit more? I might be dealing with a similar problem and would appreciate if you have any insight

Basically the juniors just ask the LLM for an explanation of what the problem is and then fix what the LLM interprets your review to be talking about. The way that you solve this is that you pull your junior into a call and work them through your comments one by one verbally, expecting them to comprehend the issues every time.

If my boss is ok with AI, why bother and make the junior hate you?

The codebase will go to shit regardless.

Post reply on HN