The economics of the force multiplier is too high to ignore, and I’m guessing an SWEs who don’t learn how to use it consistently and effectively will be out of the job market in 5 or so years.
Something similar will happen with agentic workflows - those who aren't already productive with the status quo will have to eventually adopt productivity enhancing tooling.
That said, it isn't too surprising if the rate of AI adoption starts slowing down around now - agentic tooling has been around for a couple years now, so it makes sense that some amount of vendor/tool rationalization is kicking in.
Thats why I started with AI coding. I wanted to hedge against the possibility that this takes off and I am useless. But it made me sad as hell and so I just said: Screw it. If this is the future, I will NOT participate.
If they do indeed provide a boost, it is clearly not very massive so far. Otherwise we'd see a huge increase in the software output of the industry: big tech would be churning out new products at a record rate, tons of startups would be reaching maturity at an insane clip in every imaginable industry, new FOSS projects would be appearing faster than ever, ditto with forks of existing projects.
Instead we're getting an overall erosion of software quality, and the vast majority of new startups appear to just be uninspired wrappers around LLMs.
In those workflows and cases where margins and dollar value provided is low, I've seen significant uptake of AI tooling where possible.
Even reaching this point was unimaginable 5 years ago, and is enough to show workflow and dollar value for teams.
To use another analogy, using StackOverflow or Googling was viewed derisively by neckbeards who constantly spammed RTFD back in the day, but now no developer can succeed without being able to be a proficient searcher. And a major value that IDEs provided in comparison to traditional editors was that kind of recommendation capability along with code quality/linting tooling.
Concentrating on abstract tasks where the ability to benchmark between human and artificial intelligence is difficult means concentrating on the trees while missing the forest.
I don't foresee codegen tools replacing experienced developers but I do absolutely see them reducing a lot of ancillary work that is associated with the developer lifecycle.
Uptake is orthogonal to productivity gain. Especially when LLM uptake is literally being forced upon employees in many companies.
> I do absolutely see them reducing a lot of ancillary work that is associated with the developer lifecycle.
That may be true! But my point is they also create new overhead in the process, and the net outcome to overall productivity isn't clear.
Unpacking some of your examples a bit --
Better code and documentation search: this is indeed beneficial to productivity, but how is it an agentic workflow that requires individual developers to adopt and become productive with, relative to the previous status quo?
Documentation generation: between the awful writing style and the lack of trustworthiness, personally I think these easily reduce overall productivity, when accounting for humans consuming the docs. Or in the case of AI consuming docs written by other AI, you end up with an ever-worsening cycle of slop.
Automating low sev ticket triage: Potentially beneficial, but we're not talking about a revolutionary leap in overall team/org/company productivity here.
Low sev customer support: Sounds like a good way to infuriate customers and harm the business.
I'm sure other industries would have their similar examples. And then the best folks in my direct team (infra), much smaller - are the command-line, Linux/docker/etc. guys that use mostly VSCode.
Pretty sure you can count the number of professional programmers using vanilla vim/neovim on one hand.
The best programmers I know are game programmers using Visual Studio. Real Visual Studio, not Visual Studio Code.
(vim is definitely a big thing but I'm not sure how many people I know who even use emacs anymore...)
The models seem to still (claude opus 4.5) not get things right, and miss edge cases, and work code in a way that’s not very structured.
I use them daily, but I often have to rewrite a lot to reshape the codebase to a point where it makes sense to use the model again.
I’m sure they’ll continue to get better, but out of a job better in 5 years? I’m not betting on it.
It’s fine to be skeptical, and I definitely hope I’m wrong, but it really is looking bad for SWEs who don’t start adopting at this point. It’s a bad bet in my opinion, at least have your F-u money built up in 5 if you aren’t going full in on it.
There is, effectively, a "learning curve" required to make them useful right now, and a lot of churn on technique, because the tools remain profoundly immature and their results are delicate and inconsistent. To get anything out of them and trust what you get, you need to figure out how to hold them right for your task.
But presuming that there's something real here, and there does seem to be something, eventually all that will smooth out and late adopters who decide want to use the tools will be able onboard themselves plenty fast. The whole vision of them is to make the work easier, more accessible, and more productive, after all. Having a big learning curve doesn't align with that vision.
Unless they happen to make you more significantly productive today on the tasks you want to pursue, which only seems to be true for select people, there's no particular reason to be an early adopter.
- we are far removed from “early adopter” stages at this point
- “eventually all that will smooth out…” is assuming that this is eventually going to be some magic that just works - if this actually happens both early and late adopters will be unemployed.
it is not magic, it is unlikely to ever be magic. but from my personal perspective and many others I read - if you spend time (I am now just over 1,200 hours spent, I bill it so I track it :) ) it will pay dividends (and also will feel like magic ocassionally)
It doesn’t appear like anything of this sort is happening and the idea that good employer with a solid technical team would start firing people for not “knowing AI” instead of giving them a 2 week intro course seems unrealistic to me.
The real nuts and bolts are still software engineering. Or is that going to change too?
the best SWEs will automate anything they have to manually do more than once. I have seen this over and over and over again. LLMs have take automation to another level and learning everything they can be helpful with to automate as much of my work will be worth 12,000+ hours in the long run.
We are also in the early days still, I guess everyone has their own way of doing this ATM.
Speaking as someone with a ton of experience here.
None of the things they do can go without immense efforts in validation and verification by a human who knows what they're doing.
All of the extra engineering effort could have been spent just making your own infrastructure and procedures far more resilient and valuable to far more people in your team and yourself going forward.
You will burn more and more and more hours overtime because of relying on LLMs for ANYTHING non-trivial. It becomes a technical debt factory.
That's the reality.
Please stop listening to these grifters. Listen to someone who actually knows what they're talking about, like Carl Brown.
Not this one, presumably: https://en.wikipedia.org/wiki/Carl_Robert_Brown
For it to work best you should be an expert in the subject matter, or something equivalent.
You need to know enough about what your making not just to specify it, but to see where the LLM is deviating (perhaps because you needed to ask more specifically).
Garbage in garbage out is as important as ever.
This is equivalent of that.
> This is equivalent of that.
In the hands of a crappy engineer from above, you are correct.
an SWE does not necessarily need to "learn" Claude Code any more than someone who does not know programming at all to be able to use the tool effectively. What actually matters is that they know how things should be done without coding assistants, they understand what the tools may be doing, and then give directions/correct mistakes/review code.
In fact, I'd argue tools should be simple and intuitive for any engineer to quickly pick up. If an engineer who has solid background in programming but with no prior experience with the tools cannot be productive with such a tool after an hour, it is the tool that failed us.
You don't see people talk about "prompt engineering" as much these days, because that simply isn't so important any more. Any good tool should understand your request like another human does.