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.

> 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.

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"

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.

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.

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.