Comment by bigstrat2003
2 days ago
Yep, the goalposts just keep shifting. In reality: they still don't work well, unless you're content with producing low quality work.
2 days ago
Yep, the goalposts just keep shifting. In reality: they still don't work well, unless you're content with producing low quality work.
Your perspective is one that assumes a single entity is using AI, rather than disparate groups of people working on disparate problem spaces/topics, each with different "intelligence" thresholds for them to say "good enough". The goal post isn't changing, it's that there are multiple problem spaces with completely different, fixed, goalposts.
And even then, within a single group, you'll have multiple thresholds, of "this really helps make my coding more productive" to "I no longer type code, just review" to eventually "I'm no longer employed".
This is the opposite of my experience since about February of this year.
The quality of the output is so variable. It depends on the model, “effort level”, prompting, probably even the programming language/app functionality, and libraries involved. For example, I find LLMs are best at making simple web apps. These web apps, while simple, would still take a senior engineer perhaps a week or two to create, but LLMs can spit them out inside of an hour. Conversely, LLMs struggle with things like Docker or local model stuff. Parallelization of code is a mixed bag. In these areas I think it often would have been faster for me to write the thing by hand.
What model struggles with Docker or local model deployment?
I have had good results in that area with GPT 5.5 in the past.
On the subscription plan I don't use anything but xhigh effort and Fable, 5.6 Sol, or now also Opus 5.
Is that the class of model that struggles with Docker for you?
1 reply →
"unless you're content with producing low quality work." - With the right guiding hand, it is a productivity multiplier without compromising quality. As a fully autonomous developer, it is a disaster.
> With the right guiding hand, it is a productivity multiplier without compromising quality
This just reads like another variation of “it’s the user not the tool,” which is just endless runway for always blaming people and never acknowledging the limitations of LLM’s.
I’d be curious to hear how the recipients of your work enabled by the “productivity multiplier” feel about the quality.
Yes. It is always people. Every tool will have limitations, including LLMs.
We actually have trendlines on user reported bugs, and I am happy to report they show a significant downtrend.
You can't play an entire orchestra's sheet music on a single guitar either, but your playing ability still matters a lot.
I would say that as of July 2026, with the right scaffolding, you can get reasonably good output out of a LLM, or better a combination of LLMs. For example, it pays off to prepare an implementation plan with one LLM and then let another LLM check it for flaws, then again. After several iterations like this, you will have a plan better than whatever you could come up with yourself.
It often is the user and not the tool. LLMs are complicated, have nontrivial failure modes, and the user needs to steer them carefully. They might be the most complicated tools on the planet right now.
Anecdotally, the recipients of my work have become visibly more happy in the last months. LLMs are great at diagnosing subtle problems which tend to appear at Friday night only, and this is the sort of problem that bugs actual people the most.
2 replies →
How are junior devs becoming qualified “guiding hands” these days? If the expert with LLM assistance is multiplied, what’s a company’s incentive to pay for a junior, and how would they train to get good in these conditions?
I agree on this one. Junior developers are not yet good guiding hands yet. But for the motivated junior developers LLMs are a great onboarding and learning tool. A good senior engineer must still guide, and there are very large gaps on how it's being done
Juniors are still useful, but not as pure "coders". The juniors you want to hire now can wear product, engineering and QA hats, and are self starters with good attention to detail and AI skills. These types of people are actually a bargain.
2 replies →
[flagged]
I produce code that is significantly higher quality with the assistance of coding agents, because I no longer succumb to the temptation to cut corners due to lack of time.
One example: everything I do is properly tested and documented now, even the most trivial of changes. Previously I would have weighed those tradeoffs and sometimes decided not to bother with the tests because they weren't worth the time.
4 replies →
Which means good enough for all those companies that outsource their IT, especially for offshoring.
What they care about isn't software delivery, is physical goods or services that aren't related to software, for them software is a cost center.
Here's the rub. They produce low quality work according to your rubric. If that was the universal rubric, they would already have RL'd against it, and you'd like the work they produce.
So the average bar for software is very low, and most people writing it don't care about software quality and just want a paycheck to cash?
I've been saying this for years.
I wouldn't say it like that exactly, though you're not wrong either. People just heavily discount the value of future efficiency gains due to nuanced architectural/stylistic choices. I think this is in part because people have a limited expectation that the code will survive long enough for it to matter, or that they'll be at the company long enough to reap the rewards of the up front work.
From time to time check a couple of ads in YT. They are full of low quality unrealistic AI generated ads.
What kind of work are you doing and what do you consider to be quality or not?
Of course don’t let me assume, maybe you have a higher quality disproof for the Jacobian conjecture you could share with the class.