> The role change has been described by some as becoming a sort of software engineering manager, where one writes little or no code oneself but instead supervises a team of AI coding agents as if they are a team of human junior software engineers....

> In reality, though, the code review load for software engineers will gradually increase as fewer and fewer of them are expected to supervise an ever-growing number of coding agents, and they will inevitably learn to become complacent over time, out of pure necessity for their sanity. I’m a proponent of code review...but even I often consider it a slog to do my due diligence for a large code review (just because I think it’s important doesn’t mean I think it’s fun). If it’s your full-time job to review a swarm of agents’ work, and experience tells you they are good enough 95%+ of the time, you’re not going to pay as much attention as you should and bad changes will get through.

Another way to look at this is that AI coding agents take the fun out of a software engineer's job. The machine takes many of the fun parts and leaves the human with more of the unenjoyable parts.

Under our new ways of working, you are required to be excited an curious about this evolution three times per day.

The prompt injection section is the strongest point here and honestly underappreciated in most AI discourse. I work on a product that processes untrusted user-supplied content through an LLM pipeline, and the defensive engineering required is nontrivial. You essentially need a sanitization layer that strips anything resembling instructions from data before it enters the context window — conceptually similar to parameterized queries for SQL injection, except we don't have a clean equivalent yet. Every mitigation is heuristic-based and feels brittle.

The copyright angle is also genuinely interesting. Most real codebases will end up as a mix of human and AI-generated code, and the legal boundaries for that scenario are completely uncharted. The Berne Convention point is a good one — amending international IP frameworks moves at glacial speed, so companies are going to be operating in legal uncertainty for a long time regardless of what individual jurisdictions decide.

These opinions about what is going on w/ LLM development always stop short at first order effects and fail to account for second/third order effects.

> Skill atrophy

If LLMs are so good that you no longer have use for the skill, why do we care about skill atrophy? That skill isn't that useful to most people. There are so many examples of this in human history where it was completely fine and we went on to do higher order things that were more useful.

> Even if they set out fully intending to provide the highest level of scrutiny to all generated code, they will gradually lose the ability to tell a good change from a bad one

If this (first order effect) is actually a problem then it follows that we will naturally exercise our skill of detecting good change from bad ones (second order effect) and the skill will not atrophy? (third order effect). Seems like your "problem" is self correcting?

> At its core, the only defense I’ve got for that response is… this time feels different? Not a particularly rigorous defense, I admit, but I did warn you that this was the squishiest of the issues at hand.

Well, if you knew this perhaps it was better just not to lead with it and spend so many paragraphs on it.

> Some might argue that, even if that time comes eventually, that’s no reason not to make use of the tools that are available right now. But it should come as no surprise that I disagree. Better not to become overly dependent on AI coding agents in the first place so you’ll be better situated to weather the storm (and maybe even thrive) when it comes.

Well this argument didn't turn out to be any less squishy than the first one. It's a self correcting "problem" but you disagree and we should do X because you said so. What was the point of all of this then?

> Prompt Injection

I also think this will likely always be a problem but you can pretty much point at ANY tool we use in software development. Your viewpoint would be similar to saying we should stop using libraries because there's always going to be a vulnerability when you distribute code that somewhere in the chain a bad actor can inject malicious code even if the library was created by a trusted source in the industry. We have plenty of examples of this happening in real life. So far, still squishy.

> Copyright/licensing > I’m not a lawyer! I’m a legal layperson offering my unqualified assessment of some tricky legal questions. Let’s get to it.

Sigh, this entire post is slop isn't it? Bad look for whatever "standup for me is".

edit: Standup for me is something that is made entirely irrelevant by agentic LLMs, no surprise. The irony is rich.

The author wants to be the gatekeeper of skill, quality, and how we develop while they hand feed us slop in the form of their blog posts.

i was kinda hoping for TFA to finally produce some research outputs or even statistics, but sadly the `uncomfortable truths` are your usual vague talking points.

As someone who worked on “prompt injection” before it was called “prompt injection” for an (unfinished) phd…

yeah there is only one surefire 100% fix for “prompt injection”: use deterministic solutions ie not machine learning.

There were no uncomfortable truths there about code agents, save one of the 4 points which was that maybe they sometimes get prompt injected if you let them search for things online and don't pay attention to where they search and the code they write. That's not an uncomfortable truth in the normal sense of "I know you don't want to admit this but..." and more just the thing that, if you didn't know it already 8 months ago, you certainly should by now.

The other truths that were not about coding agents:

--Skill Atrophy. (Use it or lose it-- another thing we already know)

--The economics of serving code agents at scale (Ungrounded in actual numbers, only OpenAI's miscellaneous statements and annecdotes. Actual cost of running code agents: last gen's mid-tier gaming gpu's will get you reasonably close to Claude Sonnet if you put just a little time in to an agent harness, and its getting cheaper and cheaper for better and better. So, at scale, with real sysadmins doing the hard engineering to eek out every last bit of performance-- well, infra needed for serving these isn't the cost center)

--Copyright. (This passed on the same bad read of a court ruling half the press has been doing for a few years now. TLDR: The Thaler vs. Perlmutter case, which said nothing about output not being protected by copyright. It denied Thaler's attempt to register *the AI* as the owner of the copyright)

The more immediate uncomfortable truth for me is that my company is requiring all developers to use LLMs, and laying off developers who won't make the switch. I'm not sure that "LLM-based AI coding agents have no place now, or ever, in generating production code for any software I build professionally" is a decision that most of us will have a choice in.

The section on "artificially low costs" does not make a lot of sense to me. If anything I feel like the costs are inflated for the frontier models, not "artificially low". Easy proof: GLM-5 costs about 1/10 as much as Opus. I'm not going to tell you it's as good as Opus 4.6 -- it's not -- but it performs comparably to where frontier models were 6 months ago. (It's on par with Sonnet 4.5 on leaderboards, though in practice it's probably closer to Sonnet 4.0.)

If I can switch to an open source model today, run it myself, and spend 1/10 as much as Opus, and get to about where frontier models were 6 months ago, fear-mongering about how we'll have to weather "orders-of-magnitude price hikes" and arguing that that one shouldn't even bother to learn how to use AI at all seems disconnected from reality. Who cares about the "shady accounting" OpenAI is doing, or that AI labs are "wildly unprofitable"? I can run GLM 5 right now, forever, for cheap.

i just read this before - why is it 3hrs ago?

I find the other article that the author refers to in his text, to be more thorough and revealing: https://www.wheresyoured.at/the-ai-industry-is-lying-to-you/

The skill atrophy point strikes me as tenuous at best. Obviously, the plural of anecdote is not data, but I find myself able to work on projects of greater complexity than I would have been able to otherwise. 90% of my time is spent going back and forth on Markdown files, discussing the architecture, trade-offs, etc. I don't think it's necessarily impossible to use all this newfound power to ship more sloppier code. It's clearly possible to use all this newfound power to ship better code too.

I didn't find this very convincing. Especially the argument around artificially low cost -- we know that training the next model is the biggest cost for these companies, and we've already seen inference costs fall drastically (https://epoch.ai/data-insights/llm-inference-price-trends).

These "truths" are more like concerns.

Skills do atrophy if you don't practice them, but also, refreshing your memory about some technology you haven't used in a while, or even learning something new, is easier than ever. You can ask the AI questions and try things out yourself very easily. Maybe "just in time" learning isn't good enough, but that's more of a concern based on speculation than a truth.

AI is being subsidized, but also, inference costs are dropping due to algorithmic improvements. For example, TurboQuant [1] looks pretty promising and even if it doesn't pan out, there are plenty of other potential advances like that. Competition might result in AI inference being available at good prices even without subsidies. So, again, more of a concern than a "truth."

Prompt injection: an unsolved mess, but perhaps curated, trusted datasets will be good enough for many projects, so you don't have to expose your agent to the open Internet? It's a similar problem to the supply-chain vulnerabilities that downloadable open source libraries have. A valid concern, but it seems like we'll improve security and muddle through?

Copyright: also an unsolved mess, but kind of similar. Search engines copy the web as part of how they work, but that didn't stop Google from becoming big tech. And sure, Napster was built on copying music and was shut down, but YouTube was also built on widespread copyright violation and it muddled through. It's unclear whether copyright law is load-bearing infrastructure for the software industry or for open source software.

[1] https://github.com/tonbistudio/turboquant-pytorch

I disagree with the author's interpretation of many of their points.

> Skill Atrophy

Very true, but in the same way moving from assembly -> scripting languages degraded the skill of programmers to manage memory. AI is another tool (albeit one that's on a different level than any other transformation we've had); what matters is whether the programmer understands the intent of the code, not the 0's and 1's that it turns into. That intent is still there, we're just writing it at a much higher level than before.

> Artificially low cost

This heavily depends model to model. IMO OpenAI/Anthropic are likely the outliers here, and I do agree that it's unlikely they'll recoup the training costs for their specific models, but they also legitimized an industry - something that's hard to tangibly price. Many of the models out of China however will almost certainly recoup cost. Qwen 3 had a training price of around $1.6m USD. In the first quarter of this year OpenRouter processed around 5 trillion tokens from it, landing at around 2.5m in revenue (very rough numbers). Assuming a 30% margin, that's already 40% of their training cost in revenue for a quarter from a single platform - their usage in china is almost certainly higher.

The reality is training costs are getting cheaper. I agree that currently the top providers are heavily subsidizing costs, but that doesn't mean you can't drive revenue, they just choose not to as having the "best" model right now gives them clout.

Lots of claims on cost, very little data.