"LLM evangelists - are you willing to admit that you just might not be that good at programming computers?" No.
You can stop questioning yourself early whether you are a good programmer just by realizing you code in python.
[deleted]
The insecure evangelism of LLM maximalists
211–220 of 295 posts
Re: The insecure evangelism of LLM maximalists
#212Earlier quoted context omitted.
The second.
Agreed, but do you honestly think LLMs have reached the level of average programmer? Or is it more a matter of "they can churn out code until I see something that is close enough and I'll make the last few edits"? Also curious if you publish your working setup or if it changes as fast as the LLMs? Seems like you may have a more stable setup than most given how you are developing tools in the space.
I still do not see LLMs as replacements for programmers - they're tools for programmers to direct. If you don't know anything about programming you might be able to get a vibe coded prototype or simple tool out of them but that's a very different thing from a what happens when a skilled software developer uses these things to help accelerate their work.
My current setup is mainly Claude Code CLI on macOS and Claude Code for web driven by the iPhone all and macOS desktop app. I occasionally use Codex CLI too.
I expect I'll be on a different default combo of tools within a month or two.
Re: The insecure evangelism of LLM maximalists
#213I feel any LLM discussion without mentioning concrete tooling choices are unproductive. Toolings are evolving so fast, many statements that were accurate two months ago are simply wrong today.
Re: The insecure evangelism of LLM maximalists
#214I think the author slips into the same pattern he’s criticizing. He says LLM fans shouldn’t label skeptics as “afraid” then he turns around and labels the fans as “insecure” or “not very good at programming.”
It’s the same move; guessing what’s going on in someone’s head instead of sticking to what actually happened and what the tools can or can’t do.
The simpler truth is LLMs are great in some cases and painful in others. They shine on boilerplate and tests. They struggle when the domain is unusual, requirements are fuzzy; mistakes are made, you pay a big babysitting tax.
Instead of psychoanalyzing each other, people should share concrete examples
Re: The insecure evangelism of LLM maximalists
#215> You tried agentic coding. You realised it was better at programming than you are.
We need to drop this competition paradigm ASAP.
Re: The insecure evangelism of LLM maximalists
#216I feel any LLM discussion without mentioning concrete tooling choices are unproductive. Toolings are evolving so fast, many statements that were accurate two months ago are simply wrong today.
It's a lot different to "vibe code" by copypasting crap from a browser window to an editor vs using an agentic LLM with full access to the source and tools to search for documentation, run scripts etc.
And one major thing is language.
Some languages (Rust, React) are so complex and nuanced that LLMs struggle with them - as do humans. Agentic LLMs will eventually solve the problem you've given them but the solution might be a bit wonky.
Compare that to LLMs writing Python or Go. With Go there's just one way to write a loop, it can't get confused with that. The way to write and format the language has been exactly the same since the beginning.
Same with Python, it's pretty lenient on how you write it (objects vs functional) but there are well-estabilished standards on how to do things and it's an old language (34 years btw). Most of Python 2.x is still valid Python 3.
Re: The insecure evangelism of LLM maximalists
#217I feel no strong need to convince others. I've been seeing major productivity boosts for myself and others since Sonnet 3.5. Maybe for certain kinds of projects and use cases it's less good, maybe they're not using it well; I dunno. I do think a lot of these people probably will be left behind if they don't adopt it within the next 3 years, but that's not really my problem.
What's there to be left behind on? That's like arguing people who stick to driving cars with manual transmissions are going to get left behind when buses "inevitably get good." The whole point of the AI coding thing is that it lets inexperienced people create software. What skill moat are you building that a skilled software developer won't be able to pick up in 20 minutes?
Your analogy is the wrong way around :)
Everyone now is driving automatic, LLMs are the manual transmission in a classic car with "character".
Yes, anyone can step into one, start it and maybe get there, but the transmission and engine will make strange noises all the way and most people just stick to the first gear because the second gear needs this weird wiggle and a trick with the gas pedal to engage properly.
Using (agentic) LLMs as coding assistants is a skill that (at the moment) can't really be taught as it's not deterministic and based a lot on feels and getting the hang of different base models (gemini, sonnet/opus, gpt, GLM etc). The only way to really learn is by doing.
Yes, anyone can start up Google Antigravity or whatever and say "build me a todo app" and you'll get one. That's just the first gear.
Re: The insecure evangelism of LLM maximalists
#218> And then, inevitably, comes the character evaluation, which goes something like this: I saw a version of this yesterday where a commenter framed LLM-skepticism as a disappointing lack of "hacker" drive and ethos that should be applied to making "AI" toolchains work. As you might guess, I disagreed: The "hacker" is not driven just by novelty in problems to solve, but in wanting to understand them on more than a surf…
> What I "fear" from LLMs-in-coding is that they will provide an unlimited flow of "mess around until it works" drudgery tasks with none of the upside. I feel like its very true to the hacker spirit to spend more time customizing your text editor than actually programming, so i guess this is just the natural extension.
Even when 100% issue-oriented (that is, spending no time on editor-customizatons or developing other skill and toolkits) consider the difference between:
1. This thing at work broke. Understand why it broke, and fix it in a way which stays and has preventative power. In the rare case where the cause is extremely shallow, like a typo, at least the fix is still reliable.
2. This thing at work broke. The LLM zigged when it should have zagged for no obvious reason. There is plausible-looking code that is wrong in a way that doesn't map to any human (mis-)understanding. Tweak it and hope for the best.
Re: The insecure evangelism of LLM maximalists
#219> LLM evangelists - are you willing to admit that you just might not be that good at programming computers? Maybe you once were. Maybe you never were.
Or maybe the author is bad at programming AND bad at agentic coding.
That’s more likely than the possibility that all llm evangelists are terrible coders.
Re: The insecure evangelism of LLM maximalists
#220I tend to share the sentiment of the author. I think that coding assistants tend to quite good as long as what you ask is close to the training data. Anything novel and the quality if falling off rapidly. So, if you are like Antirez and ask for a Linenoize improvement that has already be seen many times by the LLM at training time, the result will seem magical, but that is largely an illusion, IMO.
But how many times a week are you truely doing something novel? A thing that nobody in the world (or the LLM training data) has done before?