[remich]

I think this is an interesting point, my one area of disagreement is that there is no "anti-LLM sentiment" in the programming community. Sure, plenty of folks expressing skepticism or disagreement are doing so from a genuine place, but just in reading this site and a few email newsletters I get I can say that there is a non-trivial percent in the programming world who are adamantly opposed to LLMs/AI. When I see comments from people in that subset, it's quite clear that they aren't approaching it from a place of skepticism, where they could be convinced given appropriate evidence or experiences.

[bitwize]

But there's a difference. Being opposed to AI-generated art/music/writing is valid because humans still contribute something extraordinarily meaningful when they do it themselves. There's no market for AI-generated music, and AI-generated art and writing tends to get called out right away when it's detected. People want the human expression in human-generated art, and the AI stuff is a weak placeholder at best.

For software the situation is different. Being opposed to LLM-generated software is just batshit crazy at this point. The value that LLMs provide to the process makes learning to use them, objectively, an absolute must; otherwise you are simply wasting time and money. Eric S. Raymond put it something like "If you call yourself a software engineer, you have no excuse not to be using these tools. Get your thumb out of your ass and learn."

[skydhash]

Ok, I’ll bite. What’s there to learn that you can tie directly to an increase of productivity?

I can say “learn how to use vim makeprg feature so that you can jump directly to errors reported by the build and tool” and it’s very clear where the ROI. But all the AI hypers are selling are hope, prayers, and rituals.

[bitwize]

The skill is learning to supply the LLM with enough context to do anything a developer does: turn specs into code, check its work including generating and running tests, debug and analyze the code for faults or errors, and run these in a loop to converge on a solution. If you're about to do something by hand in an IDE, STOP. Think about what the LLM will need to know to perform that task for you.

It may take some human intervention, but the productivity results are pretty consistent: tasks that used to take weeks now take hours or days. This puts in reach the ability to try things you wouldn't countenance otherwise due to the effort and tedium involved. You'd have to be a damn fool not to take advantage of the added velocity. This is why what we do is called "engineering", not a handicraft.

[skydhash]

An engineering take on this would have provided numbers like success and failure rate, guaranteed results, operation manuals,…

> This puts in reach the ability to try things you wouldn't countenance otherwise due to the effort and tedium involved.

If you’re talking about prototypes, a whiteboard is way cheaper and less time consuming than an agent.

[baq]

I’m not an AI hyper, I just don’t code manually anymore. Tickets take about as much time to close as before, but the code shipped now has higher test coverage, higher performance, better concurrency error handling, less follow-up refactor PRs, less escapes to staging/prod and better documentation; some of it is now also modeled in a model checker.

[skydhash]

So the code was an unknown (to the world) X quality, but now it’s X+k quality? How does that help me exactly?

[baq]

I don't care to be honest, it's up to you to learn to use the tool.

[imron]

> I just don’t code manually anymore

I'm curious about what industry you are in and the tech stack you are using?

[baq]

without revealing too much generic saas at non-toy scale, 95% TS + postgres + 5% a very long tail of other stuff.