I wouldn't refuse to use an LLM for coding if it were specifically requested by management. I mean, I might advise as to risks, but ultimately, if a business is willing to put their resources on the line as a business decision, then okay, their capital, their call. But I wouldn't personally be spending time on it in 2026 on my own initiative either. Maybe for some special cases that are particularly well-suited to it, like "I need a limited amount of throwaway code in a language that I don't know".

Why not?

Software development has a lot of stuff that's asserted to "change the world" come along all the time. Could be new tools, new programming languages, new paradigms, new validation software, whatever.

First, assuming that one really does take over

be it a new programming language or a new editor or a particular LLM generating code

it's typically easier to let other people do the work of breaking the path, since whatever the thing is typically not in a fantastic state. There are problems that are going to need to be solved. Some of those may never be solved, whatever the promises or expectations. And some of the early workarounds may be unnecessary in the long term. The first-mover benefits, on the other hand, aren't likely that big a deal (and I think that we have enough data out now to show that while there might be benefits, as things stand, they aren't that large).

Second, a lot of the time, things that are put forward as being the future are not, in fact, the future. If you sit back and watch, then you don't burn time heading down every new blind alley. If LLM-assisted coding becomes the norm, then five years from now, a lot of data will have been gathered showing that using them in coding produces benefits and what those benefits are, as well as drawbacks.

Specifically in the case of AI writing software, I am pretty sure that in the long run, AI will be writing software at a human level. Same as AI will be doing a lot of things. But I am not at all sure that that it's going to be an LLM of the present form taking the present approach. Also, a lot of the workarounds to learn today to deal with present limitations of the tools may not be the ones needed down the road. Further, those limitations probably vary by tool even today; I'm not very interested in learning how to try to get Llama 3 to do something only to switch to ChatGPT only to switch to Claude.

Another issue is that most current code-generation models run on cloud services, which raises security and dependency issues.

Plus reproducibility issues. Even if I decide that, say, a cloud-based LLM of a particular version works well and the tradeoffs are acceptable and I tune my workflow to use it, then I'm spending a lot of time learning to deal with one LLM. If that particular version of an LLM later becomes unavailable

as has happened to users in the past

then it may be that all the workflow and workarounds that I've developed are more-or-less useless, if the provider decides to alter the revision of the available model or entirely remove it. I enjoyed using Stable Diffusion 1.5, and picked up and developed a number of techniques that work well with it. But those same techniques don't work well with even all models derived from SD 1.5, and if one's using a different diffusion model like Flux, then suddenly all the rules go out the window and one is starting at ground zero.

In the case of Stable Diffusion and Flux, I'm okay with that. I'm not professionally an image manipulator, so I'm not building much expertise on a foundation of sand, and I run both of them locally, so my ability to run them can never be taken away. But that's not true when cloud services enter the picture.

The reproducibility issues might be mitigated in some ways at a business level

AI service companies could enter into some sort of escrow agreement under what an LLM is guaranteed to be available as a service for N years or something, and if they go under some other company automatically becomes a provider, but frankly, I don't think that any benefits now warrant that level of hassle.

My expectation is that existing LLM service cloud providers

which are currently losing money

will, later on, do things like raise prices or otherwise use their leverage to make more money. That is, they are currently in a growth phase, where they accept losses to build their user base. Later, they will shift to a monetization phase. If you are heavily locked into use of that service, they can extract from you up to the cost of shifting off of their service, and you will keep using the service. My guess is that the costs of transitioning off might be quite substantial.

EDIT: Okay, one exception to the "I wouldn't refuse" case. If (a) I were working at a startup and (b) a substantial amount of my compensation were in the form of stock options or similar and (c) I were personally convinced that use of AI-assisted-coding would be an extremely bad move for the company, then I might take a "if we do LLMs, I walk out the door" position, because then it's my capital on the line, not just the company's. Part of the point of equity compensation is precisely to give you a kick in the rear to get you to act as you see being in the interests of the company. That being said, I'd try to talk to whoever was involved in making the decision to use it first in a scenario like that, to try to understand our difference in opinion on the matter, see if it couldn't be reconciled.