The Copilot Delusion
The Copilot Delusion
I'll just drop this here for future easy linking convenience...
"If you’re writing the same boilerplate every day like some industrial-age cog monkey, automate it yourself. Write a library. Invent a macro. Reclaim some dignity."
Well, I’ve done that… partially. However, since I’m not a top-1‰ superstar rock-dev, my solutions took several attempts, still make a lot of assumptions, and are generally kinda bad.
Until I’ve reached an actually good boilerplate automator, Copilot has its place.
I hear that. I don't judge anyone using copilot to cover the gap between perfect and good enough. I use it that way, as well.
A coder passionately loving Copilot strikes me as a bit like a sailor passionately loving life boats.
It's perfectly rational, and... it implies that they routinely deal with some shit that probably, ideally, ought to get fixed.
I'm projecting my own experience a lot here. When I'm working with code I'm really happy with, I find copilot getting in my way more than helping. When I'm working with code that's newer and messier, I find copilot pretty handy.
The thing is, your attempts at eliminating boilerplate can be pretty bad and take pretty long before they're worse than writing out the boilerplate in full.
Boilerplate code is by itself a problem. If it's just scaffolding, i.e. you're not duplicating logic, then it still makes code harder to read and annoying to maintain.
If you are duplicating logic, then it's a maintenance nightmare. You fix a bug in one version of it, now you gotta update 14 other versions which the LLM dutifully generated with the same bug.
Or worse, it wasn't dutiful (much like a human typically isn't), so now you've got different bugs in different versions of it, as well as different fixes over time, and you quickly lose track which version is the good one.
Shit. So many great lines.
"It's autocomplete with a superiority complex."
"It’s trained on code that’s already an insult to silicon."
It’s trained on code that’s already an insult to silicon
I mean... So am I
Having Co-pilot help is like having a junior dev at your side, who is also drunk and high.
"The problem isn’t just laziness. It’s degradation. Engineers stop exploring. Stop improving. Stop caring. One more layer of abstraction. One more lazy fetch call inside a render loop. Eventually, you’re living in a cathedral of technical debt, and every user pays."
This quote has the no one wants to work anymore vibe.
We all predicted this when web frameworks and object relation mappers were introduced... And we were right... Kind of. The average programmer is certainly worse - but there's also many more of us, getting a lot more done. And there's still plenty of us who master the craft.
The differences here are that ORM and web frameworks weren't actively making the job harder and the sheer surface area of the problem.
If you fuck up with a framework or an ORM, it generally just fails to work, the magic internals might not be super helpful with their error messages, but such is the nature of the tradeoffs.
If you fuck up with an LLM you get something that generally compiles and looks like it should work, that's much more of a problem for both you and anyone who then needs to go trawling through, looking for the issues.
You want real connection to code? You earn that. You dig in. You wrestle with segfaults at 3 in the morning. You pace your apartment muttering about pointer arithmetic. You burn through Handmade Hero until you get it.
Absolutely the best learning happens at 3AM. This guy is selling being overworked to the breaking point as some kind of rite of passage. That’s not working. Or learning. It’s the road to sucking off a 9mm 4 weeks later.
I once woke up at 3. Got a brilliant idea on how to solve one specific problem plaguing me for weeks. Went back to sleep. It was exhilarating.
I just couldn't remember the solution when I woke up again. Bit for this short period of time it was beautiful.
I think, they meant the opposite. Extending your workday until 3 AM means you'll be your least productive at that point. Whereas if you're coding on a passion project at 3 AM (and you're reasonably rested), then it's often the most productive time of day, because there's no distractions, nothing else to be doing...
these "ai bad" posts are getting so tiring. they just feel like upvote farms these days.
Only sunshine and roses allowed? For all the Ai hype in the media and lot of people blindly following, its good to see and remind us the shortcomings. As long as it is done properly and honest, I have nothing against a "Pro" and a "Contra" article.
As long as it is done properly and honest, I have nothing against a “Pro” and a “Contra” article.
Neither do I, personally. Though I am certainly less than inclined enjoy an article where the author is oddly preachy/"holier-than-thou", sayings things such as you're not a "real" programmer unless you sacrifice your health debugging segfaults at 3AM or have done the handmade hero challenge (certainly an interesting series to watch, but one that I have zero interest in replicating). Yet the author accuses copilot of having a superiority complex. I cannot say for sure, however I would assume if the article was in favor of AI rather than against, then there would definitely be comments about exactly this.
The overarching tone of the article seems like if it were written as a direct comment toward a user instead, it would run afoul of beehaw's (and surely other instances') rules, or at the least come really close to skirting the line - and I don't mean the parts where the author is speaking of/to copilot.
I agree. I think it's driven by fear. I get it. I'm slightly afraid I won't have a job in 10 years (or at least a much worse paying one)...
I'm still a much better programmer than AI today. But I don't cope with the fear by deluding myself into thinking that AI is useless and will stay useless.
The feels a lot like portrait painters saying that photography will never amount to anything because it's blurry and black and white.
50 million users have an extra 3 seconds of unnecessary lag in a day because you wanted to hit tab rather than write code? That's nearly 5 years of cumulative wasted time.
As if anyone cared if they had to wait a total of 3 seconds in a workday. If it’s a second per user action, we’re talking, but this is some bare-metal CPU wrangler’s take on how ‘efficient’ code should behave; completely disregarding that most users who touch a computer need 5 seconds to type ‘hi’ into MS Teams.
Most engineers already write bloated, abstracted, glacial code that burns CPU cycles like a California wildfire. Clean code? Ha! You’re writing for other programmers’ academic circlejerk, not the hardware.
It’s interesting that everybody else preaches ‘Write for the human first, for the machine second’.
As if anyone cared if they had to wait a total of 3 seconds in a workday.
That depends on when it appears. Some tasks kind of have to feel instantaneous, and there might be a pretty slim margin between okay and frustrating.
But yeah, that's the kind of savings that mostly matter on the scale of regional or national grid planning.
Most engineers already write bloated, abstracted, glacial code that burns CPU cycles like a California wildfire. Clean code? Ha! You’re writing for other programmers’ academic circlejerk, not the hardware.
It’s interesting that everybody else preaches ‘Write for the human first, for the machine second’.
Yeah, the author seems to lean too hard into the "programming is electronics" model, where the opposing end is "programming is math and formal logic"; most of us take some mixed view. And most of us have higher correctness requirements than what a reasonable effort in memory unsafe languages like C and C++ gives us, so we trade away some machine efficiency. In the authors parlance, most of us aren't interested in the demoscene circlejerk; we need to make tradeoffs between maintainability and everything else. Write-once code isn't good enough.
There have been attempts at establishing a third pole of "promptgramming is natural language" or whatever ever since COBOL promised programming in plain English, but the ambiguity of natural language when used to encode a business logic machine means that a "sufficiently advanced compiler" will have to be extremely advanced, on the order of including the manager and the entire engineering methodology.
Very good read, thank you for sharing!