The post is a skeptical take on coding with large language models. It argues that despite enormous investment and nonstop evangelism, there is little visible evidence that software is materially better, cheaper, faster to build, or easier to maintain. It also frames the LLM push as partly about making software labor more interchangeable and weakening developer bargaining power. In other words, the complaint is not that LLMs are unimpressive demos. It is that the promised industry-scale payoff has not shown up in shipped software or in measured productivity.
Most of the useful discussion landed in a middle ground sharper than either hype or rejection. People who actively use these tools said the real gains are not “10x engineer” magic. They are narrower and more believable. LLMs are good at small, verifiable fixes, debugging unfamiliar systems, generating drafts, converting documentation formats, and helping one person attempt projects they would otherwise avoid. That is a real workflow change. It just does not automatically turn into visible business output, because software delivery is gated by review, integration, coordination, and downstream mistakes. Several comments made the same point from different angles: users often feel faster locally, but the economy-wide proof is still weak, and raw code volume is a bad proxy for value.
The strongest pro-LLM comments were concrete rather than ideological. People described shipping hobby apps they had postponed for years, using models as a kind of adaptive tutor, and relying on them during illness or injury to stay productive by reviewing small diffs instead of writing every line manually. Even skeptics conceded that debugging and bug finding are a sweet spot because the output can be checked quickly. The strongest skeptical comments focused less on whether models can emit code and more on what happens around that code: giant unread PRs, skill atrophy, more verbosity and noise, and organizations using the existence of the tool to squeeze labor while tolerating lower quality. The net picture was not “LLMs do nothing” and not “LLMs already transformed software.” It was that LLMs clearly help at the task level, especially for bounded work, but their broader payoff is being oversold and may be getting canceled out by sloppier usage, organizational bottlenecks, and the cost of cleaning up after them.
Treat LLMs as a narrow force multiplier, not a replacement for engineering judgment. If you run a team, optimize for small reviewed changes, debugging, and prototyping, then measure whether those gains survive integration, maintenance, and org friction.
Split but leaning pro-use in practice and anti-hype in framing. Many commenters were irritated by blanket skepticism because they see obvious day to day gains, especially in debugging and prototyping, but they also rejected the 10x rhetoric and agreed that autonomous agent workflows, giant PRs, and management fantasies about replacing engineers are producing a lot of noise and distrust.
Key insights
01
LLMs as accessibility and stamina support
For some developers the win is not marginal speed. It is staying functional when health, fatigue, or injury would otherwise stop work entirely. Used this way, the model is less a coder replacement and more an adaptive interface that lets someone supervise small changes, review diffs, and keep shipping when typing and deep concentration are impaired. That reframes part of the value proposition from productivity theater to assistive technology.
If you evaluate LLMs only on average team throughput, you will miss a real accessibility use case. Consider them in the same bucket as other accommodations and design workflows around small auditable diffs so the benefit is usable without lowering quality.
The practical sweet spot is bug hunting in code you do not fully know yet, where the model can quickly narrow search space and suggest hypotheses you can verify. That works because the task ends in a small concrete fix or a reproducible explanation, not a sprawling architecture decision. This is why many experienced users sound modest about code generation but enthusiastic about debugging help.
Point your experiments at diagnosis first. If you are rolling out coding assistants, start with incident triage, test generation, and root cause exploration instead of broad autonomous feature work.
Faster code output does not become business value on its own when the rest of the organization still moves at the old pace. Review queues, interface negotiations, documentation rituals, and cross-team coordination can easily absorb the gained velocity. In some cases the extra speed just raises organizational stress because upstream engineers change faster than downstream partners can handle.
Do not read faster code production as proof that a team is delivering more value. Measure cycle time across handoffs and approvals, and expect process redesign if you want tooling gains to show up outside the developer’s laptop.
Feeling faster today may simply mean you moved effort from writing to later debugging, integration, or comprehension debt. Several commenters zeroed in on the gap between strong personal anecdotes and weak external evidence. The useful interpretation is not that users are delusional. It is that benefits vary hugely with skill and workflow, while the costs often show up later and in different parts of the system.
Track downstream metrics before declaring a win. Rework rate, escaped defects, review time, and time to understand old changes will tell you more than self-reported speed.
The post’s labor argument resonated, but several comments sharpened it by saying software is not moving from craft to industry now. That happened years ago through standard tooling, process, and team structures. What is still unusual about software is how open the field remains to self-taught entrants, even as the practical stack for a new hire keeps expanding far beyond what a degree covers. LLMs may change entry paths, but they are entering an already industrial workflow.
If you are thinking about hiring and training, focus less on nostalgic craft narratives and more on what skills remain scarce. Tool fluency can be taught fast. Systems thinking and deep conceptual grounding still compound.
The strongest visible impact is prototyping by nonexperts
One place where commenters did see unmistakable change was quick MVPs, hobby apps, and one-off tools built by people who would not have built them before. The code may be ugly and maintenance-hostile, but the barrier to trying an idea has dropped hard. That is a consumer and founder unlock more than proof of higher output from senior engineers.
Expect more cheap prototypes and more half-baked competitors in adjacent niches. Build your advantage around distribution, iteration speed after prototype stage, and the ability to turn rough demos into maintainable products.
Not all skeptics are making an empirical claim about coding productivity. One comment rejected LLMs on training data theft, energy use, and broader social harm, and said whether the tools work is beside the point. That does not tell you whether the post’s business claims are right, but it explains why some critics will never be persuaded by better benchmarks or stronger coding demos.
If you are leading adoption, separate capability arguments from legitimacy arguments. A pilot that proves engineering value will not address concerns about sourcing, environmental cost, or labor effects.
An LLM optimist argued that the technology can be genuinely impressive and still degrade day to day work through slop, stalled learning, and management pressure to promise impossible output. That cuts against the idea that visible dissatisfaction means someone has not tried the tools. The burden is not just proving the model can help. It is proving the surrounding workflow improves human work rather than cheapening it.
Watch for second-order effects after rollout. Rising document volume, lower review quality, and inflated delivery expectations can erase gains even when the underlying model is competent.
Boilerplate acceleration may just industrialize slop
One blunt objection said that if a workflow mostly rewards generating boilerplate faster, the process itself is already optimizing for the wrong thing. More fast code is not neutral if the output is harder to trust and maintain. This pushes back on the common defense that LLMs are fine for routine code, because routine code still lives inside systems that have to stay reliable.
Do not treat “just boilerplate” as a safe default use case. Apply the same reliability bar to repetitive code paths, because maintenance burden accumulates there too.
blog.jsbarretto.com