Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The copilot delusion

deplet.ing

Post reply on HN
Print view View original

161–170 of 214 posts

Re: The copilot delusion

#161

Post by joshstrange »

airstrike wrote: post #83

I think all arguments pro and against AI assistants for coding should include a preface that describes the programing language, the domain of the app, the model being used and the chosen interface for interacting with the assistant. Otherwise everyone's just talking past each other.

That’s probably asking for too much but I agree.

Here are some terms/aspects of LLMs that people _regularly_ use, yet 10 people have 10 definitions of what it means (to them)

- Vibe Coding

- Boilerplate

- Copilot

- Cursor/Aider/Claude Code/Codex/OpenHands/etc

- LLM Autocomplete and/or inline code suggestion

- LLM Agent

I’m happy to explain or expand on any of those if it’s not clear what I mean.

Re: The copilot delusion

#162

Post by BlueTemplar »

pona-a wrote: post #157
seanmcdirmid wrote: post #153

Earlier quoted context omitted.

I think we should just agree to disagree. All of those opened up new paradigms for programming, and so will AI even if we aren’t quite sure what that new paradigm is yet. There will always be people claiming the old-fashioned way is better, like Dijkstra’s famous complaint about kids not using punch cards anymore and how that meant they weren’t learning how to be good programmers.

We're actually quite certain what this new paradigm is, because some poor souls are already practicing it: slop coding. You prompt-whisper poorly-defined changes to make, and if the machine chokes on its own vomit along the way, you delete everything and try again. It feels reasonable, consistent to see it as another "old man yells at the skies" scenario, but I do think it's unprecedented for a machine to automate th…

Yes, and as a reminder, this is now an issue much wider than programming :

https://news.ycombinator.com/item?id=44025127

Re: The copilot delusion

#163

Post by BlueTemplar »

rester324 wrote: post #46
Jcampuzano2 wrote: post #19

As a preface, I think lots of people will not like this take. A lot of people are going to have to come to the realization that has already been mentioned before but many find it hard to grasp. Your boss, stakeholders, and especially non-technical people literally give 0 fucks about "quality code" as long as it does what they want it to do. They do not care about tests insofar as if it works it works. Many have no cl…

Well that might be true, but I think the reason why they are blatantly acting like that because stakeholders and decision makers are detached from their decisions timewise. That's why I bring such topics as maintenance and stability very early on into the discussions and ask those stakeholders how much system downtime they can tolerate, so that they can feel the weight of their decision making, and that gives me an o…

Anthropogenic climate change and resource depletion comes to mind...

Re: The copilot delusion

#164

Post by xigoi »

nozzlegear wrote: post #135
boxed wrote: post #58

Earlier quoted context omitted.

Maybe he meant it was long. Some people seem to think that long walls of text is how you spot AI slop.

And god forbid you use an emdash these days.

I’ve recently been accused of using ChatGPT because I wrote a message with formal language and bullet points.

Re: The copilot delusion

#165

Post by sgarland »

queenkjuul wrote: post #143
padolsey wrote: post #36

> if you want to sculpt the kind of software that gets embedded in pacemakers and missile guidance systems and M1 tanks—you better throw that bot out the airlock and learn. But the bulk of us aren't doing that... We're making CRUD apps for endless incoming streams of near identical user needs, just with slightly different integrations, schemas, and lipstick. Let's be honest. For most software there is nothing new und…

Fundamentally, mission critical low level code isn't the kind of software i want to write anyway. I don't find AI tools super useful for most of the same reasons as the author, but i do kind of get tired of the idea that if you're not writing systems in C you're not really programming. I like writing front end code. I'm probably never going to have a job where i need or would even want to write a low level graphics l…

> I like writing front end code. I'm probably never going to have a job where i need or would even want to write a low level graphics library from scratch. Fine, I'm not red-eyed 3am hacker brained, but I'm passionate and good at what i do.

Keep that spirit! All I want from coworkers is genuine interest and curiosity. Not everyone is going to find investigating Linux’s networking stack interesting, just as not everyone is going to find making beautiful pure CSS animations interesting. I think one of the greatest mistakes the tech industry did was to create “full stack,” as though someone would have interest and skill in frontend, backend, and infra. Bring back specialists; we’re all better for it.

Re: The copilot delusion

#166

Post by sgarland »

sanderjd wrote: post #122
sgarland wrote: post #87

Earlier quoted context omitted.

Cursor has been confidently incorrect repeatedly when discussing databases at my job. It doesn’t understand how MySQL works, and wants to make terrible indexing decisions because of it. You wouldn’t know that it’s wrong unless you already know the correct answer, because what it recommended will work, it’ll just be bloated and sub-optimal. And therein lies the problem: computers are so fast, people will happily assum…

Yeah. But you aren't disagreeing with what I wrote. I think it's breaking a lot of brains that we have these tools now that are useful but not deterministically useful.

Fair point. I don’t hate AI, and use it sometimes, but I’m always painfully aware that it can and will make mistakes, some subtle, that must be caught by someone who already knows most of the answer.

Re: The copilot delusion

#167

Post by sgarland »

Jcampuzano2 wrote: post #45
nalekberov wrote: post #30

Earlier quoted context omitted.

> I really think a lot of the reason some people say it doesn't give them as much productivity as they would like is due largely to a desire to write "clean" code based on years and years of our own training, and due to having to be able to pass code review done by your peers. Machine doesn't get mad when an app takes forever to start or keeps constantly crashing, but we humans do. Writing "clean" code has the least…

People keep reading off this nonsense that AI generated code is always bad or slow. This is so far from the truth that I really think anybody who still says this has not actually used it for anything real in at least a couple years. Yes, I'm not saying it will always generate you the best code, sometimes it may even be bad. What I am saying is it CAN generate code that is reasonably performant, sometimes even more pe…

It generates reasonably performant code because most of the industry isn’t writing code that’s computationally bound. If you have to wait for network I/O anyway, it doesn’t really matter if your code is optimal, because that wait will dominate everything else.

Re: The copilot delusion

#168

Post by Jcampuzano2 »

drekipus wrote: post #96
Jcampuzano2 wrote: post #45

Earlier quoted context omitted.

People keep reading off this nonsense that AI generated code is always bad or slow. This is so far from the truth that I really think anybody who still says this has not actually used it for anything real in at least a couple years. Yes, I'm not saying it will always generate you the best code, sometimes it may even be bad. What I am saying is it CAN generate code that is reasonably performant, sometimes even more pe…

I can only assume that you have significant experience being a junior engineer

First off, I would hope that everyone had experience being a junior engineer for some time.

But if your assertion is that using AI for code generation and being successful with it makes you a junior engineer, then good luck keeping your job in the future. Just take a look at social media and there are a plethora of examples of prominent engineers using it with success.

Re: The copilot delusion

#169

Post by sgarland »

OnionBlender wrote: post #154

The author is clearly a C++ programmer. I've been noticing that these AI tools are worse at C++ than other languages, especially scripting languages. Whenever I try to learn from people that are using these tools successfully, they always seem to be using a scripting language and working on some CRUD app.

They seem to be a game dev judging by their other posts. I imagine there’s a lot less content online about that for LLMs to scrape than yet another CRUD app.

Re: The copilot delusion

#170

Post by sgarland »

alexjplant wrote: post #127
sgarland wrote: post #79

> The real horror isn’t that AI will take our jobs—it’s that it will let people in who never wanted the job to begin with. I fully agree. This already happened with the explosion of DevOps bullshit, where people with no understanding of Linux got jobs by memorizing abstractions. “Stop gatekeeping,” they say. “Stop blowing up prod, and read docs” I fire back.

> explosion of DevOps bullshit The fact that somebody can "be DevOps" or work as a "DevOps Engineer" is exemplary of the fact that DevOps as conceived and DevOps as practiced are two very different things. The former would be engineers taking ownership of deployment, collaborating horizontally, and practicing tight feedback loops. DevOps as practiced is the time-honored tradition of a dev team and a cloud team playin…

The platonic ideal of DevOps is fine, yes. The problem I’ve consistently run into is there is a vanishingly small percentage of devs who want to do Ops, or even consider that a server with real constraints is running their code. Performance takes a backseat to DX, which AFAICT is code for “I don’t want to do anything but write code and push.”

I should note that I think this is fine, if and only if you have specialist teams who respect each others’ abilities and recommendations. A dev team shouldn’t have to worry about standing up infrastructure, but similarly, when the infra team tells them that their app is consuming far more compute than it should be, the dev team should profile and improve their code instead of asking for more compute.

Post reply on HN