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

21–30 of 214 posts

Re: The copilot delusion

#21

Post by nyarlathotep_ »

malfist wrote: post #4

I feel this in my bones. Every day I'm getting challenged by leadership that we're not using AI enough, told that I should halve my estimates because "we'll use AI", and being told that there's a new AI tool that I have to adopt because someone is tracking KPIs related to adoption and if our team doesn't adopt enough AI tools we're going to be fired to give more headcount to those that do. It's like the world has los…

> I feel this in my bones. Every day I'm getting challenged by leadership that we're not using AI enough, told that I should halve my estimates because "we'll use AI", and being told that there's a new AI tool that I have to adopt because someone is tracking KPIs related to adoption and if our team doesn't adopt enough AI tools we're going to be fired to give more headcount to those that do.

This--all of this--seems exactly antithetical to computing/development/design/"engineering"/architecture/whatever-the-hell people call this profession as I understood it.

Typically, I labored under the delusion that competent technical decision makers would integrate tooling or choose to use a language, "service", platform, whatever, if they saw benefits and if they could make a "case" for why something was the correct approach, i.e how it met some product's needs, addressed some shortcomings, made things more efficient.

Like "here's my design doc, I chose $THING for caching for $REASON and $DATASTORE as it offers blah blah"

"Please provide feedback and questions"

This is totally alien to that approach.

Ideally, "hey we're going to use CoPilot/other LLM thingy, let us know if it aids your workflow, give us some report in a month and we'll go from there to determine if we want to keep paying for it"

Re: The copilot delusion

#23

Post by ghaff »

bluefirebrand wrote: post #7
malfist wrote: post #4

I feel this in my bones. Every day I'm getting challenged by leadership that we're not using AI enough, told that I should halve my estimates because "we'll use AI", and being told that there's a new AI tool that I have to adopt because someone is tracking KPIs related to adoption and if our team doesn't adopt enough AI tools we're going to be fired to give more headcount to those that do. It's like the world has los…

> Management has an AI shaped hammer and they're hitting everything to see if it's a nail. I really think we need to figure out how to cut back on management so we can get back to the business of actually doing work

Coordinating teams, talking to stakeholders/customers (including spending a lot of time with them), having someone manage individual contributors at some level, etc. is work that can't just be ignored at a company of any size. The only way to avoid (a lot of) it is to be very small and that has its own set of issues.

Re: The copilot delusion

#25

Post by edoceo »

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…

This is true. But the cost after is high. Creating code, by hand or AI is easier than maintaining or modifying the system.

And this is where a problem (still) appears - except now the AI-assiated authors have even less comprehension of the system.

Re: The copilot delusion

#27

Post by boxed »

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…

Clean code is nice.

Working code is a requirement.

You missed the point. AI slop doesn't just fail on point 1. It fails on point 2.

Re: The copilot delusion

#29

Post by bravetraveler »

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…

I suspect experienced folks are well aware of the subjectivity of quality. How? Change control.

Quality control exists until The Business deems otherwise. The reasons vary: vulnerability, promotion, whatever. Usually not my place to say.

Personally, my 'product' isn't code. Even the 'code' isn't code. For every 8 hours of meetings I do, I crank out maybe 20 lines of YAML (Ansible). Then, another 4 hours of meetings handing that out/explaining the same basics for Political Points.

The problem(s) relating to speed or job security have remarkably little to do with code; generated or not. The people I work with are functionally co-dependent because they don't use LLMs or... manuals.

All this talk about "left behind"... to survive a bear, one doesn't have to be the fastest. Just not the slowest.

Re: The copilot delusion

#30

Post by nalekberov »

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…

> 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 importance when it comes to machine generated code.

Post reply on HN