Eniko FoxI do not need to hear from people who can't code or at the very minimum seem to actually hate it how I can supposedly code more efficiently
This is a post about large language models
I also do not need to hear from people who can't understand the cognitive load difference between writing code yourself and trying to understand code someone, or *something*, else wrote. Especially when the something else will be able to slip in little bugs that are easy to overlook and which no human coder, not even the most junior, would ever put in there
This is a post about that Ptacek article some people think has some good points for some baffling reason (it doesn't)
If you wanna automatically produce shit code and spend your time babysitting the lying machine then that's a you problem. I'm sure you'll make a consultant who bills out at $150/hour very happy some day. But your character flaws have nothing to do with me so keep that shit to yourself
Also, and I can't believe I'm going to actually deconstruct his arguments further, fucking linters and unit tests? Really?? Putting aside your AI is writing said unit tests so you have no idea what it's testing for, these are tools designed for catching the occasional human flub. They were *not* designed to hold back a tidal wave of sewage such as the one produced by LLMs
Like idk how to tell you this but you can easily introduce bugs that the linter and unit tests won't catch
Shocking, I know
Me sending a thousand AI-driven Mac trucks onto the road: it's fine actually if they do something stupid the guardrails will stop them
*watches a truck slam clean through a guardrail and plummet into a ravine leaving a large mushroom cloud*
Ah. Well. Nevertheless
Anyway, time to go do something more productive than angrily posting about some dipshit being incredibly wrong on the internet
Honestly I think there's a disconnect between LLM proponents when it comes to code and the rest of us. They see code as a purely mechanical thing, and so ripe for automation. To them claims of artistry and craft are something to roll your eyes at, arrogance from senior engineers who think too highly of themselves
Meanwhile said senior engineers have the decades of experience to know how much of programming relies on artistry and craft, how much of it is fundamentally a creative endeavor
Gonna mute this to reclaim my notifications ✌️
Christophe@eniko well said! Code is not just derivative stuff based on whatever has been coded before...
Jean-Baptiste "JBQ" Quéru@eniko It was COBOL in the 50s, SQL in the 70s, visual programming in the 90s, MDA in the 00s, no-code in the 10s. We have plenty of experience with technologies that claimed they'd replace coders but didn't.
arclight@jbqueru @eniko I doubt COBOL was intended to displace programmers; there weren't enough programmers in 1958 to worry about displacing and machine time was far more expensive than human time. Like FORTRAN, COBOL was aimed at subject matter experts already doing the work. Programming as a standalone generic profession didn't come about until the 60s or 70s.
The difference between those systems and AI is in how vendors treated errors. If COBOL or SQL gave wrong results for a properly constructed expression, that was an error to be fixed. If an AI tells you to put glue on a pizza or to drink gasoline, the vendor shrugs and is mildly embarrassed and goes on doing what they were doing. All failures and errors are on the user's part - for not phrasing their prompt 'correctly', for not verifying the machine's stochastic response. We've gone from GIGO to IGO with vendors basically saying that requirements and acceptance tests don't matter. All that matters is line go up.
We still use FORTRAN, COBOL, and SQL - they have proven value and are fit for purpose. They solve actual problems. They are easier to learn and easier to produce error free code than their predecessors. The only problem AI is intended to solve is that other people have money.
RootWyrm 🇺🇦
@jbqueru @eniko do NOT under ANY circumstances lump COBOL in there. Period. Full stop. This is outright wrong and demonstrates a complete ignorance of COBOL's origins and intent.
COBOL was not in ANY way meant to make programming 'easier.' It was designed specifically as a successor to FLOWMATIC to create a portable language which was self-documenting. NOT to be easy to write.
The whole point of leaning on English was to make it *portable* on machines of the time, a very rare thing.
Gabriele Svelto [moved]@eniko I hadn't read the article until seeing your thread, but now I have. The first few paragraphs left me puzzled until I hit this line and then it all clicked:
> I work mostly in Go
Ah yes, that's why he needs to write repetitive code that requires extensive unit-testing. That's also why the kind of code generated by an LLM works (maybe). Good luck fixing a bug in that code five years from now.
@gabrielesvelto i don't remember enough about Go to know why this makes sense so if you'd like to spell it out i'd love to read it
@eniko Go was designed to let you clobber together network-facing services rather simply. They made a lot of choices that reduce the friction toward this goal while retaining some type structure. However once you start pushing at the edges a lot of this simplicity is a massive footgun that lets you make stupid mistakes and doesn't really provide a structural way to avoid them. Go is a language where it's easy to write code that mostly works under most conditions, but is all but robust.
@eniko there's this article/rant from five years ago that goes hard comparing Go and Rust basic abstractions and shows just how bad Go is when you start crossing platform boundaries or just have to deal with errors. It's a bit long but a very good read on the topic: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride
@gabrielesvelto "My honeymoon with the Go language is *extremely* over."
strong start XD
Chuck@gabrielesvelto @eniko This is really a priceless rant. Not so much because Go sucks but because it so clearly illustrates how "programming" is orthogonal to "operating systems"which are orthogonal to "system architecture".
Henri@eniko @gabrielesvelto I think most people agree that Go has this verbose aspect to it, for example, functions return the error and result value which you immediately need to check with an if statement. This is just tedious to write, and I remember when I was trying out Copilot, was kind of convenient to have generated for you, even if it wasn’t 100% what you wanted.
The kinds of LLM tools he is talking about are a step beyond the Copilot that just autocompletes. I do understand what his point in the blog was even if I don’t like the vibe coding productivity hustle culture these people talk about.
It is for a specific kind of programming: corporate code that you write for a job for getting paid money. There is no passion or artistry here. You need to complete Jira tickets at the end of your sprint. You have to fulfill requirements and pass the acceptance criteria. PRs are mostly rubber stamp, nobody clones your branch and test it, the best you can hope for is someone noticing a superficial mistake.
Yeah, I’m now over 40 and I also sometimes think it’s not worth my time to spend learning the intricacies of some microservices interacting with each other. I also tend to get caught in some procrastination traps that are not related to the assigned task I’m working on.
Our stuff at work is in C# so I don’t know how well it works with this AI shit, but another thing about Go is that it is very easy to work with code in a lot of different repos because you can just import code directly without having to create, build, deploy and import packages that we have to do with Nuget.
I should also mention that at work we have a shit ton of legacy code, split into many different repos, sometimes hard to know what parts are actually in use and what is outdated, or why is some parts of the data handled in the “wrong place”, was it just convenient at the moment or does it make sense for the “business logic” to do it this way?
And then the teams get reorganized and you’re working with stuff you’ve never seen before and it takes quite a while to catch up. Not to mention the fact that each time someone that has 5+ years of experience leaves the company, the institutional knowledge is also lost.
Meanwhile the middle managers hired 3 months ago are asking for changes to the system without fully understanding how it all works together.
Meanwhile, the technical debt piles up and fossilizes and gaps in observability resulting from shifting through multiple platforms for cost optimization have left even simple customer support issues to become a puzzle to be solved.
So yeah, I wouldn’t mind if there was some tool that helped me to automate some part of my work. And it’s probably going to involve the LLMs at some point in the future. I don’t have to like it, but it’s a job, and that comes with the territory.
@slyecho @eniko I get that, I did work on those kind of codebases in the past, truly horrible ones. I can understand the appeal of using those tools on one of those codebases, but to me the larger problem working with them was maintenance. The more mediocre code gets checked in the harder it gets to make things work later. Ultimately I think these tools will increase the amount of work people do because of the increased complexity they breed.
@gabrielesvelto I don’t have a problem with mediocre code, there is a lot of low-quality code too, but the over engineered object oriented stuff relying on meta programming constructs is the thing that makes stuff hard to understand and change, while the idea was to “abstract away” the repetitive stuff, I suppose.
I only have the appeal right now, I don’t actually know if these tools work for our code yet (Copilot was kind of underwhelming).
Claudius Link@gabrielesvelto @eniko
I came here to say something similar.
If you have to write extensive boilerplate code, I blame the programming language.
It's a bit like the AI email use case depicted. AI might work "well enough" here but it's solving the wrong problem!
David Nash@gabrielesvelto @eniko I have a couple of personal projects written in Go (main reason: it was fast enough and simple enough to do the job in a short amount of time), and I can definitely see why "something to help with all the boilerplate" would be tempting. But even given that, I've never personally been even mildly tempted to drag an LLM into those projects.
Svavar the NeurospicyThis disconnect has always existed.
Way before LLMs I could bash out code that mostly worked but needed cleaning up and optimising and I'd get immediate pressure to put it into production and move onto the next thing.
It's the same for people like voice-over artists who have spent decades honing their craft and now accountants with no knowledge or taste for good voice acting are replacing them with AI because it's "good enough" and they can't appreciate the difference quality makes.
tiny_m@eniko we had a company meeting where they were interviewing a panel of our colleagues in front of everybody and one of the questions asked to our junior dev was do you think your job is creative and they said no, you just google how to do it and copy the answer and both me (senior) and my boss (more senior) locked eyes, shook our heads, raised our eyebrows quietly. I think understanding there is choice and knowing how to apply the choices is the creative part but you have to know enough first
Almost A Fern@eniko great thread! I think the management-legible version of "artistry and craft" is that the hard part of my job is not writing the code, but understanding and precisely describing the problem domain and building a team capable of doing the same; the LLM, marketing copy to the contrary, doesn't understand the domain, and can't (accurately) explain it's (non-existent) reasoning or (durably) learn from it's (frequent) mistakes. The artistry and craft that make me a senior engineer are the experience and skill to blaze a trail and make the difficult "understand and describe the problem domain" work easier for my colleagues that follow me by building and updating high-quality abstractions, whereas LLMs obfuscate that domain with high volumes of buggy and repetitive code. In short, they automate the easy part at the expense of the hard part, which will over time drag down the productivity of the entire team. (Now, would this convince most non-technical managers: not likely, but it's at least framed in cost-benefit terms that are somewhat legible to them.)
Farbs@eniko I reckon it's an inferiority complex thing. Easier to think that someone else's skills are worthless than that they have value in ways that you don't.
四@eniko The ones who wants LLMs wants them so they can fire the rest of us. That’s it. That’s why they don’t care about anything else.
Matt Campbell@eniko With respect, and it pains me to say this because I'm inclined to be an LLM skeptic and critic particularly when it comes to code: tptacek _is_ a senior developer, and he has said (on the HN comment thread for this article) that fixation on craft is more of a thing with early-in-career developers. So I guess, in his view, senior developers swallow their desire to do great work and just crank out what the business wants.
@matt that's a bizarre take from someone who's supposed to be a senior engineer
@eniko Here's the HN comment I was referring to, to make sure I'm not misunderstanding or misrepresenting it: https://news.ycombinator.com/item?id=44165292
ManchmalScottgod did you see that recent fly io blog post where the author goes "uhh but actually if you're trying to be an artisan when coding you're literally doing it wrong and literally nobody will care so llms are good actually"
like damn sorry you don't actually enjoy programming i hope you get well soon
edit: actually went and read the rest of the thread and realized that was exactly the article you were talking about lmaooo
@manchmalscott lol yeah
but yeah that guy is insufferable
BrazMogu (i.e. Bruno Guedes)@eniko This disconnect permeates all of the GAN/LLM bullshit hype cycle, from art generators pushed by people who don't want to do art to text generators that can write emails that will be read by automated text interpreters. They want to automate the process out of the things, but not by putting any thought into it; they pray to a random number generator that will do what they want by chance, eventually.
mcc@eniko Capitalists long for nothing but a box they can put money in at one end, and things they can sell for much more money come out at the other end. Nothing else matters but money in -> more money out, no finesse, no strategy, no decisions. AI fits this mythical notion of how "business" works so well they will do anything to make it real, even if they don't actually know how to make it real
IvanDSM
Janie Larson
Jacqueline@burnoutqueen @eniko I thought that was Man Crush Monday
Thepi
RustyRing
JWcph, Radicalized By Decency
01d55@jwcph Paul Krugman is not one of those guys, but I will concede that I know this because he frequently criticizes those guys, which proves that they're enough economists to get on his nerves frequently.
Kevin Karhan 
@eniko I mean, we don't even get fully-automated #IT where any "#AI" could in theory perform as it's ripe for that.
- I mean, #automation in #AI exists, but noone's gonna drop #Ansible, #Puppet or #Saltstack (not even #Landscape & #MAAS) for #ChatGPT or similar bs.
#Protip: Ask "AI" fans if they would cobditionlessly entrust an "AI" with their financial details in full.
- Pretty shure none of them do.
Jason Sadler@eniko I love your whole thread. Great takes.
The other part that baffles me is that when I get a feature from a product manager or an idea of my own, I have a good idea about how I can make that work. The most efficient way for me to put that down is in code, not to try to explain the idea in English. This can’t be just me, right?
The other part that baffles me is that when I get a feature from a product manager or an idea of my own, I have a good idea about how I can make that work. The most efficient way for me to put that down is in code, not to try to explain the idea in English. This can’t be just me, right?
Bird Wainer@eniko I think that the disconnect is even deeper than that. I'd say that they view code as transactional, rather than mechanical, and as disposable. Every time I see someone pushing LLM generated code I know deep down that they have never had to live with a codebase for an extended period of time.