(Yeah, I know, I'm still completely failing to diarize beyond hot takes on Mastodon. This makes me sad, but I'm torn in too many directions at once these days. But here's at least what has been chewing up a lot of my time and attention. Cross-posted to all of my blogs, since they mostly have separate audiences.)
Early this year, I started to realize that the inevitable moment had arrived: the frontier LLMs no longer suck at writing code. So after a couple of years of largely ignoring the hype wave, it was time to knuckle down and learn how to use them for that purpose.
Mind, I've been using them for research for years -- Kagi Assistant is very much my friend, and I use it several times a day.
(I don't use them for writing: I care too much about my personal "voice". All this em-dash and parenthesis abuse comes from my own Gen X, OG Internet style -- I'm the guy the LLMs learned all that from. Sorry.)
The early LLMs wrote such bad code that it wasn't worth my time to even really kick the tires much, but Claude Opus and GPT Codex are now able to write decent Scala code -- not fabulous, but good enough to actually be a net plus.
I've been using them hard for a couple of months now, so let's talk about that. Nothing here is revolutionary -- it's just an anecdotal report from someone who has been programming for 50 years, in many paradigms, environments and languages, about what this next paradigm is like.
For context, I'm using Claude Code (mostly Opus) for Querki, and GitHub Copilot (mostly on top of Claude Opus and GPT Codex) at work.
(Note: yes, yes, the AI Industry is mostly staggeringly evil, and likely to collapse under the weight of its nonsensical economics sometime soon. Let's take that as read, and not get derailed by it too much in this post. If folks want to engage in meaningful discussion about the downsides in comments that's fine, but I'm not impressed by extremist arguments on either the pro or con sides: it's a complex and subtle set of topics.)
There's a lot of exaggeration being spouted in terms of the quality of the output, with some people saying it's all terrible crap and others saying "fire all the engineers, the LLM is enough". The reality seems to be somewhere smack in the middle.
I'm using the LLMs both for greenfield development (I've been booting up a new microservice at work), and legacy work (notably Querki, whose codebase is ancient and creaky, and needs a lot of TLC). It's been particularly useful for cross-repo development: for example, lifting code out of a service and moving it into a library -- that's traditionally a pain, but is proving pretty easy this way.
I can get very good results from the current-generation models, but that doesn't happen magically. I've been putting a fair amount of effort into building up AGENTS.md files (which is how you give generalized instructions to the LLM about how to behave in this code), and a lot of effort into each prompt.
People talk a lot about "vibe-coding": give the LLM a minimal prompt, and just YOLO the results. Far as I can tell, that's still a terrible idea for serious, long-lived code bases -- the things just don't produce very good code when left to their own devices.
(Long-lived code needs to be well-designed and well-factored. That's more important in the brave new world of AI, not less, because badly-written code is going to cost more to maintain in the long run, just in terms of the number of tokens you have to shove around and the amount of reasoning effort needed by the agentic LLMs. So leave the vibe-coding for throwaway projects and prototypes.)
Yes, LLMs might eventually get to the point of producing genuinely good code without much oversight; frighteningly, "eventually" might well be within the next few years. But we're not there yet.
So in practice, I'm typically spending a bunch of time preparing for each PR ("pull request" -- basically a unit of work in modern programming). I make sure I understand the problem decently well, and write up a deeply-detailed prompt: typically a couple of paragraphs, and a bullet list of the key things I want to make sure it deals with, usually with some specifics about how the code should be factored.
Paired with that is the all-important "don't trust the AI" for the outputs. The code tends to look good, in the same way that chatting with an LLM sounds human-like, but it's prone to similar problems of being over-confident and weak on the details.
So in practice, I do a detailed code review of the output, even before I open the PR. I'll often tell the LLM to restructure it in various ways, to clean up the code paths so that everything is tighter and easier to maintain.
This is where it is critically important not to anthropomorphize the thing. If this was a human, I might well be tempted to softball it: to not hassle them too much about details, lest I burn out an engineer. But these aren't people (ignore the chirpy obsequiousness), and politely but firmly bossing them around is how you get the best results.
A key point here: using LLMs effectively and responsibly requires critical thinking. A lot of critical thinking. We've never been collectively all that good about teaching that in school, and I worry quite a lot that this is one of the ways in which that is going to bite society in the ass.
Anyway, at the end I often have another LLM pass to do its own critical review of the code. That's generally bad at finding maintainability problems, and they're horribly prone to whining about picky details that don't actually matter, but they do fairly often pick up on bugs that are worth fixing.
Now let's talk about productivity.
There was a lot of hype a while back about a study showing the LLM usage wound up making programmers less productive, not more. I recommend ignoring that: it was a fairly narrow study, as far as I could tell, largely about testing using LLMs badly, in a very specific and naive way -- of course that produced bad results. I don't think it matches what you get when you use the things mindfully and carefully.
The key thing, I'm finding, is to separate "designing" from "typing". I'm still doing all of the high-level designing, and most of the detailed design, myself. But for PRs of any serious size, I'm letting the LLM do most of the actual typing. That's a pretty serious speedup, provided that most of that typing is correct -- which at this point it mostly is when using the best models, carefully-steered.
It's by no means instantaneous, mind: those detailed prompts typically take me half an hour or more to craft. But I usually do all that planning anyway, and being forced to write down the plan in advance isn't a bad thing. And that's followed by 2-20 minutes of the LLM cranking away, often replacing what would have taken me a day of type, compile, type, compile, type, compile, test. (Rinse, lather, repeat.)
Anecdotally, my sense is that my overall coding productivity is getting boosted three-to-five-fold. That's not a small thing, especially given that I'm not a slow programmer to begin with. I'm cranking through tickets significantly faster than I traditionally could, and I'm using enough care that I don't believe quality is suffering.
That said, it's not magic. It does require attention and time if you want great results -- I suspect that a five-fold speedup is probably somewhere around the cap without sacrificing quality, at least until and unless the LLMs are genuinely good enough to operate unattended.
And mind, coding is only a fraction a senior engineer's workday. Most of my time is spent dealing with higher-level product architecture and design, research, problem analysis, and of course meetings and discussions in chat. LLMs can help a bit there as well (Kagi Assistant in Research mode has enormously sped up the technical-research side for me), but there are limits.
So overall, that's a major speedup for a fraction of my job; the total speedup is necessarily smaller. Too many people forget to do that math properly, and expect unrealistic miracles.
And of course, this stuff costs actual money. It's been effectively-free up until now, but with quota limits that I often bump my head against, stopping my work for a time. GitHub Copilot is especially egregious here, with a one-month quota granularity: if you overuse the LLMs at the beginning of the month, you can be dead in the water for the rest of it unless overages are authorized.
But those "effectively-free" prices have been mostly a over-the-top loss leader by the LLM companies, which have been blitzscaling to a degree we've never seen before, burning a bonfire of cash in order to attract market share. I believe we're nearing the end of that, and we're starting to see more-realistic pricing creeping in.
So I expect the cost of LLM-driven programming to rise by an order of magnitude or more in the coming months. I believe that's still going to be a good deal when you factor in the realistic productivity benefits, but it's going to be enough that the bean-counters at many companies are going to get cranky about it, and with good reason. Folks are going to have to start budgeting realistically and appropriately around it (along with training engineers in how to use it well), and just using it profligately for fun is going to become less of a thing.
Anyway, that's my initial take. It's a powerful tool, and a generally beneficial one for programming if you use it responsibly. IMO any serious programmer should be kicking the tires and learning how to use it, or you're going to be in danger of being left behind. (Which happens with every major paradigm shift in this industry -- if you don't keep up with the times, you can easily find yourself unemployable.)
As a side-note: all of this has left me doubling down on my long-held assertion that Scala is the best current programming language for most business use cases. (Rust is probably the best language for the rest of them.) The rise of LLM-driven programming is making that more true, not less: Scala's strengths nicely complement the needs of LLMs. But I've talked enough here, so I'll leave that for my next post...
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
zhelana at 01:32am on 31/05/2026 under 140 in 1400
