I will just point out the benefit is not as obvious as you think. Developers have consistently overestimated LLM productivity gains, which still seems true for agentic AI: https://metr.org/blog/2026-05-11-ai-usage-survey/ It is particularly striking how similar the results are to LLMs before agents.

Along with the total absence of long-term data, I think the benefit can be (weakly) denied. Maybe not in the employmemt marketplace, but certainly for myself.

▲

qsort 2 hours ago | parent | next [-]

> I will just point out the benefit is not as obvious as you think. Developers have consistently overestimated LLM

I think there are two different claims here:

- developers overestimate productivity gains, which is a solid finding in many of these studies. Skepticism of extremely large productivity gains is warranted and I flatly disbelieve "10x uplift" claims.

- LLMs give no productivity uplift at all, which is much harder to defend. A repeat of the famous METR RCT study did find evidence of improved productivity, and this seems to align with the experience of many experts I trust.

▲

Diogenesian 2 hours ago | parent | next [-]

Specifically my claim is "the relatively minor productivity uplift I would personally get out of agentic development is offset by the high cost, along with unresolved questions about long-term code maintainability, so I am not convinced that it is actually beneficial."

IMO the bigger problem is that ~1.5x individual dev productivity uplift seems to translate into 1.05x uplift across the team. People have been waaaaayyyyy too overconfident about this stuff.

▲

breadzeppelin__ an hour ago | parent [-]

I am both a career developer and experienced team manager. from first hand experience the 1.5x im getting from AI is not flowing down to my team / org because why would i output 50% more when the pay environment and leadership are already underwhelming. That additional 50% productivity goes completely to side projects built on my second computer between 9-5 tasks

▲

Diogenesian an hour ago | parent | next [-]

Actually, the METR report speculates that some of the overreported productivity uplift comes from grabbing unnecessary low-hanging fruit, things like "oh I'll make a web dashboard to keep track of this stuff // wow that would have taken all day without Claude!" But in the olden days they would have just used a notepad. Yet psychologically they built a real thing and saved a lot of time.

	▲	breadzeppelin__ 34 minutes ago \| parent [-]
		True I have made a few low tier apps that just hit apis that were previously obfuscated deep in menus that have had an outsized impact

▲

dawnerd 9 minutes ago | parent | prev | next [-]

That’s what I’ve heard from my dev team too. They’re using it to give themselves free time while still being on the clock, not to produce more output for the company. Roughly thinking about hours spent on projects I think have gone up per task, the opposite that should be happening.

▲

dieselgate 21 minutes ago | parent | prev [-]

Your comment makes total sense to me but generally, in regards to productivity gains from AI, I can never understand where these are realized for people. Maybe I'm just a laggard but never found myself 25%-50% behind on anything or that much more work/items/tickets available.

▲

skydhash an hour ago | parent | prev [-]

> LLMs give no productivity uplift at all, which is much harder to defend

It’s not really hard to defend. Because when people says that productivity is uplifted, they are talking about amount of work, not the ROI. That’s why you keep hearing about LOC, amount of PR and prototypes, and the time taken is actually “time to PR” and not “time to production + time spent on bugs”.

▲

deaton an hour ago | parent | prev | next [-]

I think the real disaster is that once you let the LLM work on a project for a bit, you start to lose understanding of what exactly is even happening under the hood in the project. You can take steps to mitigate this, but agents don't exactly encourage the behavior required to maintain a good understanding of what's going on.

▲

westurner 43 minutes ago | parent [-]

Like becoming a manager?

When a person becomes a manager, they do or do not have enough time and expertise to review all of the code that they trust the team to produce.

Managers usually get into automated testing; unit tests, integration tests, acceptance tests, and maybe also BDD syntax

Managers and developers are responsible for setting a test coverage threshold for merge approval.

If there is 100% branch coverage test coverage for a codebase, what would coverage-guided fuzzing or property testing find? If there is 100% branch coverage test coverage for a codebase, what is the value of spending resources on formal verification?

How does the value of LLM-produced 100% branch coverage compare to no-LLM 100% branch coverage?

	▲	tablarasa 14 minutes ago \| parent [-]
		> How does the value of LLM-produced 100% branch coverage compare to no-LLM 100% branch coverage? This is such a salient question. Sometimes (definitely not always) the test suites produced by LLMs are so trivial it's scary. Coverage can be an illusion for sure.

▲

pydry 2 hours ago | parent | prev [-]

The productivity depends upon the requirements.

If slop is fine (and sometimes it is), the benefits are undeniable. If the dev was the kind that would have produced slop anyway - again, undeniable boost.

If the quality needs to be high I think it actually can slow you down, though.