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)

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

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

@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.

@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.