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

61–70 of 400 posts

Re: Writing Code Was Never the Bottleneck

#61

Post by epolanski »

noodletheworld wrote: post #50
epolanski wrote: post #37

Earlier quoted context omitted.

> 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 I don't understand, if they don't test the code they write (even if manually) it's not an LLM issue, it's a process one. They have not been taught what does it mean to have a PR ready for being reviewed, LLMs are irrelevant here.

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…

> The issue of LLMs here is the proliferation of people not understanding the code they produce.

Let's ignore the code quality or code understanding: these juniors are opening PRs, according to the previous user, that simply do not meet the acceptance criteria for some desired behavior of the system.

This is a process, not tools issue.

I too have AI-native juniors (they learned to code along copilot or cursor or chatgpt) and they would never ever dare opening a PR that doesn't work or does not meet the requirements. They may miss some edge case? Sure, so do I. That's acceptable.

If OP's are, they have not been taught that they have to ask for feedback when their version of the system does what it needs to.

Re: Writing Code Was Never the Bottleneck

#62

Post by imiric »

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 the junior/senior distinction is useful in this case. All software engineers should care about the quality of the end product, regardless of experience. I've seen "senior" engineers doing the bare minimum, and "junior" engineers putting vastly more care into their work. Experience is something that is accrued over time, which gives you more insight into problems you might have seen before, but if there's no care about the product, then it's hardly relevant.

The issue with LLM tools is that they don't teach this. The focus is always on getting to the end result as quickly as possible, skipping any of the actually important parts of software development. The way problem solving is approached with LLMs is by feeding them back to the LLM, not by solving them yourself. This is another related issue: relying on an LLM doesn't give you software development experience. That is gained by actually solving problems yourself; understanding how the system works, finding the underlying root cause, fixing it in an elegant way that doesn't create regressions, writing robust tests to ensure it doesn't happen again, etc. This is the learning experience. LLMs can help with this, but they're often not used in this way.

Re: Writing Code Was Never the Bottleneck

#63

Post by alkonaut »

I agree with most of this. Writing code is one of the easy bits of Software Development. Writing the specifications about what to write is hard.

Once you can specify what to create, and do it well, then actually creating it is quite cheap.

However, as a software developer that often feel I'm pulled into 10 hours of meetings to argue the benefits of one 2-hour thing over the other 2-hour thing, my view is often "Lets do both and see which one comes out best". The view of less technical participants in meetings is always that development is expensive, so we must at all cost avoid developing the wrong thing.

AI can really take hat equation to the extreme. You can make ten different crappy and non-working proof-of-concept things very cheaply. Then throw them out and manually write (or adapt) the final solution just like you always did. But the hard part wasn't writing the code, it was that meeting where it was decided how it should work. But just like discussing a visual design is helped by having sketches, I think "more code" isn't necessarily bad. AI's produce sub par code very quickly. And there are good uses for that: it's a sketch tool for code.

Re: Writing Code Was Never the Bottleneck

#64

Post by oytis »

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…

I guess answering "you obviously didn't write it, please redo" is not an option, because then you are the dinosaur hindering company's march towards the AI future?

Re: Writing Code Was Never the Bottleneck

#65

Post by zeroCalories »

octo888 wrote: post #28
virgilp wrote: 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?

Yeah I've run several SOTA tools on our gnarly legacy codebase(because I desperately need help), and the results are very disappointing. I think you can only evaluate how well a tool understands a codebase if you already know it well enough to not need it. This makes me hesitant to use it in any situation where I do need it.

Re: Writing Code Was Never the Bottleneck

#68

Post by AbstractH24 »

The difference between a hobbyist who codes and a professional is all of the things listed in this article.

As someone who shamefully falls more in the hobbyist camp, even when they code in the workplace, and has always wanted to cross what I perceived as a chasm, I’m curious, where did most people who code for a living learn these skills?

Re: Writing Code Was Never the Bottleneck

#69

Post by jaapz »

chii wrote: post #57
noodletheworld wrote: post #50

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

Testing is often very subtle. If you don't understand changes you made (or really didn't make because the LLM did them for you), you don't know how they can subtly break other functionality that also depends on it. Even before LLM's, this was a problem for juniors, as they would change some code, it would build, it would work on their feature, but it would break something else which was seemingly unrelated. Only if you understand what your code changes actually "touch", you know what to (manually or automatically) test.

This is of course especially significant in codebases that do not have strict typing (or any typing at all).

Re: Writing Code Was Never the Bottleneck

#70

Post by ysofunny »

kabdib wrote: post #33

my LLM win this year was to give the corporate AI my last year's worth of notes, emails and documents and ask it to write my self review. it did a great job. i'm never writing another one of those stupid bits of psychological torture again otherwise i'm writing embedded systems. fine, LLM, you hold the scope probe and figure out why that PWM is glitching

but as soon as you are doing that,

the people who have to read your self-review will simply throw what you gave them into their own instance of the same corporate AI

at which point why not simply let the corporate AI tell you what to do as your complete job description; the AI will tell you to "please hold the scope probe as chatbotAI branding-opportunity fixes the glitches in the PWM"

I guess we pass the butter now...

Post reply on HN