[zahlman]

I open this discussion thread and literally the first two top-level comments I see contradict each other:

> I find that productivity follows a Pareto distribution (80:20 rule) and that AI is a sharper tool in that it enables the already productive to be proportionally more productive and this effect increases as the intelligence of AI increases. So 80:20 becomes a 90:10, 95:5, 99:1 etc.

> Big caveat to the productivity claim is that it’s concentrated in lesser experienced engineers and vanishes or goes negative with highly experienced engineers.... LLMs move your baseline towards the mean. If you are below average it improves and if you are above it hinders.

[cjbgkagh]

While I disagree with the counter position I do believe it to be an honest account of their experience. I think the counter intuitive aspect is that marginal cost of software is practically zero so in an efficient market the consumption of it will be dominated by the best software written by senior devs with AI, even if the production of software is dominated by junior devs with AI. I think we are in a transitory phase where still employed juniors can be very productive shortly before becoming unemployed at which point that productivity drops to zero. If junior devs are productively producing software that then goes unused then how productive were they really. But I understand that the latter effect may not have been picked up in the general stats. Anecdotally again, I fired 3 juniors and went solo and I know of many others who have done something similar.

Another aspect is that once the easier work is complete then the remaining residual is the difficult work, and this changes the relative productivity to the point where a junior developer may not be able to make any further progress at all.

Overly bureaucratic companies tend to generate easier work for themselves to the point that this work dominates their total workload. If we are to measure productivity by opening and closing Jira tickets then I would expect the junior developers to get a much bigger ‘productivity’ benefit from AI than senior developers.

[DanielHB]

> If junior devs are productively producing software that then goes unused then how productive were they really

Most ways of measuring productivity across an economy (in macro sense) takes into account only the transfer of capital. Meaning someone paying for something. So in this case it will be measurably zeo in most macro-economics studies.

[torginus]

Wonder if that means if I knock out an app using a Claude Code sub in an afternoon, that would've taken me a week previously, and the result is better than what I could've done, does that mean that gross productivity went down?

- I didn't make money, since I got paid for my time

- Anthropic didn't make money, since the amount I paid them for AI is tiny

This sounds wrong to me.

[DanielHB]

If the same amount of people bought your app at the same rate as if you hand-written it, then no. In fact your productivity would have grown 10x (half a day vs 1 work-week). The actual costs paid to Anthropic to make said app would have net-zero effect I believe (not an expert in macro economics).

[rileymat2]

Presumably, someone bought the app.

[icantevenhold]

Consequently 99% of software written is to make it easier to buy stuff (at least in web dev).

They say the internet is for porn but it’s really to sell/buy stuff

Edit: even with LLMs the “killer” application is to make it easier to buy things xD

[jvanderbot]

It's not so contradictory if you peel back a couple layers

1. For junior engineers a 50% increase might be less than a 10% increase for senior engineers. So the % comments are consistent with the pareto argument. Diminishing returns _can produce_ a pareto tradeoff.

2. Saying gains are "concentrated" to junior engineers can also be a function of the work assigned to junior engineers. A senior engineer might get 1000% boost over jr doing the same jr work. The problem is the reverse - the hard things are concentrated around the oldest engineers, and now "hard" can also mean "not easily claude'd"

[bicx]

Yes, I’m a senior engineer at a 3-engineer startup, and there isn’t “junior-level” or “senior-level” work here. It’s all just work. Claude allows me to tear through the kind of gruntwork I’ve been doing ad nauseam for the last 15 years.

If my tasks were things like squeezing 3% more efficiency out of an algorithm, that might be different. Although, even then, my PM (!) used Claude to boost the efficiency of one of our more complex Postgres queries by up to 5x, in ways I honestly would not thought of doing. It was quite humbling. A former engineer here used pgMustard on the same query a couple years ago and claimed it was as fast as it could get.

I can’t speak for the kind of work done in the higher echelons of big tech, but for us, there isn’t much that Claude can’t help with.

[jvanderbot]

Yeah those single points of failure/bottlenecks are prefect focal points for people with floating responsibilities and a good understanding of how to use claude.

The system-sweeping features I still would ask to review, but you can't argue with a DB query just getting faster.

[bojan]

> Although, even then, my PM (!) used Claude to boost the efficiency of one of our more complex Postgres queries by up to 5x

Would you be kind to describe what test set-up do you have that a PM felt safe enough to deploy the changed query without the fear they'll break something?

[saghm]

Who said they deployed it themselves? I would expect that they made a PR (probably with some benchmarks), and that there are tests ensuring that the results are the same independent of timing, so then the author of the comment could verify whether it still worked and reproduce the benchmark results and then chose where to approve and merge based on that.

The same techniques that were used to try to prevent regressions before we had LLMs still work for LLM-generated code, provided that you actually use them. If you have an insufficient test suite and a lax policy around who reviews code before merging, you're going to have a bad time even if you only have your seniors writing the code by hand.

[bicx]

They built a comparison harness between the old and the new query, and ran it across thousands to benchmark and ensure valid results. And then I reviewed the PR.

[jvanderbot]

read the diff and time the query?

[tcp_handshaker]

That is not the most absurd, the most absurd is people here thinking faster ( and yes I avoid the word better ) code generator engines will solve humanity problems.

[indoorfish]

But software makes the most money? Look at the stock market. It must be the most important thing? right guys? right?

[expedition32]

If AI starts putting tech folks out of a job we can end the teacher, nurse and daycare shortage.

[inigyou]

There will still be no money available for those things. Money is only available for Larry Ellison's yacht.

[suzzer99]

> it enables the already productive to be proportionally more productive

I finally got a real feature to develop and started using Codex a couple weeks ago. Before that, I was just using ChatGPT for small things. For the most part, I was doing a lot of monkey-patching and deep troubleshooting that I didn't think Codex would be good at.

I was wrong. I had no idea how smart these tools are.

I now realize, as the tech lead on a large project with me, 2 front-end developers, a full-stack-ish developer, a tester, two product people, and a PM - that I could do this entire project more efficiently with just me and the tester.

I'm doing SQL for the first time in 20 years, which would have slowed me down in the past, but not now. It used to take me an hour to program a new feature and two hours to get it to look right, if I had to do the CSS myself. Now I can do that w/o anyone's help. Writing tests used to take as long as writing the code. Maybe it still does, but that's an hour instead of a day. And it's so much less painful. There's no satisfaction of the aha moment when writing tests. It's just a slog.

We're a very small shop that usually only has 1-2 devs on a project. So we're not set up to do big projects, we aren't doing agile, and it's just a mess. We waste probably 80% of our effort just communicating.

The product team was needed/useful in the beginning to define the broad scope of the project and lay down the UI/UX patterns. But now it's like pulling teeth to get them interested in our internal client's ever-evolving wishlist. I can handle that, and always come to the product team with very specific asks when I need UI design help. Just give me the tester, who's so thorough it's annoying, to catch the weird edge cases I hadn't thought of.

I'm not saying I'm God's gift at any of these things, just that I'm reasonably competent at them. It's kind of terrifying what a seasoned full-stack dev with a decent feel for UX and the ability to manage stakeholders can do with this.

[lobster45]

Your comment resonates with me due to the cognitive dissonance of seeing the benefits and issues with AI as far as development work. I have been struggling to identify a process improvement that AI can improve not only the development aspect by the overall productivity of our company. We are a dev shop mostly C++ and python. At our company I see the development workflow and it is very inefficient. The biggest issue is communication. AI can certainty increase the coding output and velocity, but the rest of the process relies on humans.

[torginus]

Well for one, since one person can do more, less communication is needed, so you can cut out the inefficient part.

[ulnarkressty]

It heavily depends on the task, language and experience. What I saw in my team was that low performers started being as productive as mediocre programmers, however they mostly produce slop which needs to be sent back for rework, so in the short term it's not that great. However since they can iterate faster, I have the feeling that they are learning faster so hopefully in the long run they can be somewhat productive.

The high-performers on the other hand are ripping through tasks at such a speed that they now have time to focus on quality and processes, so in the end you get a really well polished piece of software. However this is starting to change for the worse as the PMs are realizing what's happening and cramming more and more stuff in the sprints.

The amazing part is not the above though - it's that one needs not be an SME anymore. One of our customers asked us to make an Android application with some features of our product, which were not trivial to port. Even though we never did anything like that before, a small team was able to release it in a couple of months mostly bug-free. Without AI this would have taken at least half a year, or more. It is quite shocking to hear the status updates going from "we need this thing implemented and I have no idea what it even means" to "it's done and works" the next day.

[Turfie]

If you're finding it hinders, you're using it wrong.

Terrence Tao is living proof, that it cannot hinder even the most elite.

There's always something you can do with it.

[nkrisc]

Terrence Tao is an exception in many regards. I’m less concerned if it helps him, and more interested in how it affects the average person, since the vast majority of users will be average.

[Shacklz]

Tao can use LLMs on his own terms, on his conditions. Under those circumstances, it's an absolutely fantastic tool.

In an enterprise, everyone gets to use LLMs. Everyone can create slop. In an enterprise environment, this can lead to weird situations where the senior has to put in extra efforts to contain the slop of others... so I can kind of see where the "hinders seniors" is coming from.

[californical]

I don’t think it’s even “seniors” containing slop of others.

I think it’s those who still care about quality (which seems to be decreasing in the industry overall) trying to keep the whole thing running, in a sea of people who think going really really fast and not understanding their code is fine because LLMs can make sense of it and clean it up later.

Just look at the condition of open source contributions recently