On LLMs in programming
45 points by nathell
45 points by nathell
This is a beautifully written piece and really successfully articulates the major issue I also have with LLMs.
I've been feeling a little dismal this whole last week thinking about how outsourcing programming to AI seems actually ridiculously-effective with few downsides when done by already technically competent people. I had been thinking about it before I saw the comment, but what ~osa1 said on here the other day did a good job at bringing back up my emotions around this sort of stuff. I couldn't quite put my feelings into words at the time, I could only describe them as vaguely... a problem with this outsourcing removing the whimsy of programming, turning it from an interest and a craft into something measured only by productivity and cold dead metrics.
It's anxiety. Yeah, it's anxiety. It's exactly as ~nathell says here. To it, I would only add that a particular piece of anxiety that I can piece out from how I'm generally feeling is anxiety around that fun I also have with learning, exploring, and applying programming. I'm anxious that future programmers aren't going to have that same experience. I'm anxious that code will become even more a means to an end than it already is. Lots of people don't have this anxiety -- just recently, someone I follow online shared an obviously-vibecoded project as an example of having fun with computers. And okay, sure, I suppose that may be some sort of fun. It's really not the fun I value. I think there's something neat about the process of programming, about expressing intention and thought and creativity and communication in a structured fashion. I disagree with this online acquaintance (and with my friends IRL who hold the same views) that computers are no more than a practical tool.
Frankly, it's hard for me to look at the people who are doing this and convince myself that they still care about the process of programming and not only the end results. And maybe this has always been the case! But it makes me sick, because primarily for the reasons articulated in this post (as well as -- and here i might differ from ~nathell -- throwing money at chatgpt or gemini or whatever to turn programming into a subscription/dependence to a big tech company) it is so deeply against my morals. And frankly also, this all makes me jealous! Because it does assist the technically competent, and because I will never do this, I will forever be less productive.
What a strange bundle of anxiety / sadness / jealousy / boredom / disappointment this all is.
Frankly, it's hard for me to look at the people who are doing this and convince myself that they still care about the process of programming and not only the end results.
There are many parts of the process of programming though!
Even before LLMs I had the problem of liking to solve the hard parts and disliking doing the now-obvious parts in full necessary details.
Fortunately, I like debugging. So a local LLM offers me a balance I like: I do need to provide enough grounding, and I most probably will have to debug something absurd — but the worst slog will be covered by slop.
turn programming into a subscription/dependence to a big tech company
Yeah, letting illegal monopolies decide who can program and at what price is a horrible idea, I fully agree with you here.
As of companies using closed LLMs — it is appalling how nobody learns anything, Gemini is from the company literally memetic for two things! Entering/destroying/abandoning markets, and dropping the promised data-use-restrictions. And people think that actively giving that company the smallest details of their plans, via a product with already weak controls evone before dropping the restrictions, is a good idea??
I think it might help your anxiety to think about some of the tasks that are getting delegated and whether they really pertain to the craft. When someone types "please checkout curl from GitHub" into Claude code and it does it for them, what they've avoided is memorizing a bunch of flags from a man page. That's perfectly fine! That was the drudgery, not the craft.
It can be just drudgery, when you already have the foundation. But when such assistance is your starting point, you don't learn what the terminal is about or what you can do with it in the abstract. You need that to exercise craft. Even before LLMs, Stack Overflow was crutch enough. A lot of folks I worked with would just use the terminal as a short list of incantations they knew, but they hadn't read enough manual pages to absorb patterns and intent, and they couldn't be creative at the shell. When it came time to own a CI script, they were starting from zero.
It took me less than 10 seconds to go to Github, search curl and get the repo. And right there, with a big green button is the command line to clone it, which can be cut-n-pasted into a terminal (which is pretty much just git clone https://github.com/curl/curl.git---where are the bunch of flags I saved typing?).
10 seconds is longer than typing "clone curl from GitHub" and it's a task you already knew how to do. A better example might be using rsync or ffmpeg, but if you're being honest with yourself and thought about it for two seconds you already knew this.
but if you're being honest with yourself and thought about it for two seconds you already knew this.
How dare you claim you know what I'm thinking! I could claim that you are an idiot that hands off your thinking to a glorified Markov generator. How do you know that Claude didn't download https://github.com/cujojs/curl or https://github.com/lwthiker/curl-impersonate instead of the proper curl repository? How do you know that Claude won't confabulate options for rsync and wipe out your home directory? If I'm having Claude do that for me because I can't be bothered to read a man page, how will I know the command is safe to execute?
a problem with this outsourcing removing the whimsy of programming, turning it from an interest and a craft into something measured only by productivity and cold dead metrics.
I agree with your sentiment, but not necessarily with the conclusions. Granted, companies live and die on metrics (and on brain-dead "ecosystem" reports using those, such as https://www.greptile.com/state-of-ai-coding-2025 's that conflates LoC with team velocity ). But the craft of programming isn't dead because that toolmaking is a deeply human instinct. To me, an interesting and positive byproduct of code being sort of cheaper to write at scale is that we can fill any "gaps" in the OSS library ecosystem. That too can be a matter of volume rather than sheer craft (e.g. data format adapters, perhaps not so fun to write but necessary).
perhaps a technicality, but just now I'm co-working on a new Haskell library, prompting away (a direct HDF5 binding). What I just did was say "enable -Wall -Werror and fix all resulting breakage", ie. turn compiler warnings into errors, and the agent loop is happily plugging away. The net effect is that the library will be easier to use for downstream users: shorter build times, fewer spurious warnings, more compact interface (no unused definitions or module exports), and so on. This level of polish would have been pretty tedious to fix by hand.
I think there's something neat about the process of programming, about expressing intention and thought and creativity and communication in a structured fashion.
I could not agree more. I have always loved that feeling when you build each function, bit by bit and then throw them all on a line together and realize that it all just works. On the one hand there's all the time that went into planning and executing those functions, but on the other the last line feels so quick and simple because you already built all the things to get there.
Two years ago I predicted in the future (now the today) we would see people label code not written by LLMs as "artisanal" to get across the same level of craft as watching a sculptor carve what a 3d-printer could just spit out with no effort. There's a difference in sense of accomplishment for many.
Something else that's been bothering me: in a world where all code is LLM written and developers only do reviews, my skills atrophy. I can see the incentive for management to push for more and solving problems "faster", to them it's just more output, faster. To me, it's in part sacrificing the process of understanding and discovery I attach to development and it makes me lesser in a way and indeed, makes me anxious. You can also see Karpathy's recent comment on feeling behind as a programmer, it reads as anxious as well.
On the other hand @simonw's posts make me hopeful there's a way to enjoy using LLMs and get something from them, in terms of learning and building. Yet I also don't want the little creativity I can muster to be judged under a productivity lens.
I started the year feeling the same and ended it at the other end of the spectrum: I get to explore parts of programming that otherwise would be inaccessible, because the effort to get to the interesting part exceeds the time I have available for programming-as-a-craft.
Over the holidays I managed to ship a from scratch reimplementation of TCL: https://www.feather-lang.dev which gave me an incentive to learn about WASM in more detail.
Is it a useful project? Maybe - it's just something I want to exist and without LLMs it just wouldn't
That's a very positive experience! How did you manage the active learning part without delegating all the thinking to the LLM? I'm often struggling with getting an idea started but the LLM comes up with too much stuff I'm unfamiliar with to stay comfortable working with it.
Thinking through a problem by talking to an LLM helps. For Feather, I fell deep into the slop trap and deleted all of the code at some point - it was painful, but necessary.
Then I iterated on the API design with Opus 4.5 in the Claude Desktop app, and eventually typed out the C header file defining the interface.
My mistakes with the full commit history and all conversations can be found here: https://github.com/dhamidi/tclc
management to push for more and solving problems "faster"
sacrificing the process of understanding
Yeah, and given that this yields systems that are not understood and thus less reliable, it is tempting to start rooting for the villains (who are going to abuse this loss of reliability in a way that even management will have to notice).
I guess the real question is how to avoid pushing the most competent people on the inside towards also rooting for the villains, as you can't do concentration-based work well while secretely wishing to fail… and I am not sure if most large companies have decision-making processes that can robustly maintain this question in focus… and I am no longer sincerely sure if this deficiency of the decision making is a bad thing…
I find it fascinating that articles like this are still being written. This would have made a lot of sense if it had appeared in February or March of this year, but at this point the evidence running counter to the overall tone of the post feels overwhelming.
Are we all 10x programmers now?
I believe that once you learn how to use an AI coding agent, you become a significantly more productive programmer, and many differences in prior experience are flattened. I like to think about it as the shift from manual field labor to using a steam machine. Physical strength used to matter a great deal; now it does not. Anyone can operate the machine equally well, but only if they learn how to use it.
Now, with the advent of LLMs, I can’t help feeling that we’re going through this all over again. New technology appears that purports to save us all precious time; and then, some time later, we discover that we have just as little free time as we used to.
From my experience, this is not the same situation at all. For one, very few people are actually trying coding agents today. Adoption is still extremely limited. Whenever I have convinced someone to use them seriously for more than a week, the experience has been very different from what they expected. Many people assume they will not be very productive with these tools, and only discover their power once they actually commit to using them. We are simply very early in the adoption curve.
The second point, and the one more directly relevant to the quote, is that these agents unlock a level of capability that allows us to tackle work we previously had to leave on the back burner. This is especially true for internal tooling, building proper reproduction cases for bugs, and similar tasks. This does not map well to the idea that once the basics are done, we merely invent new ways to fill the day. In reality, engineering teams have long been constrained by limited capacity. Backlogs have been dominated by work we could never properly address, simply because there were not enough people or time.
This constraint is not disappearing entirely, but we can now do meaningfully more than before. At least in my experience, we already are. And that, to me, is the most important change.
How do you reconcile that with learning what goes on behind the scenes and keep your skills sharp? You are by all metrics, a very experienced developer. Said experience was most likely built in the trenches of Flask, Sentry and all the other projects you worked on. How does someone at the start of the journey benefits from what you're saying while also learning the fundamentals in enough depth to be able to understand, debug and steer the agents in the right direction?
I'm not doubting that many people can become incredibly productive with agents, especially once we've all settled on tried workflows. But right now, I'm not seeing how to build juniors/mediors up and avoid skill atrophy in the long run.
How do you reconcile that with learning what goes on behind the scenes and keep your skills sharp?
For me the act of punching keys into the keyboard has never been the defining quality of being a programmer and the more I work with authentic coding tools the more and more it becomes clear to me that that just is not the definition of an engineer. You don't stop being an engineer just because you change the way in which you program a machine.
If anything I have learned so much more over the last year than at any time over my career. I have also written a lot more, and I have reflected much more on what my profession is about. If there is a skill atrophy, it's not there for me.
How does someone at the start of the journey benefits from what you're saying while also learning the fundamentals in enough depth to be able to understand, debug and steer the agents in the right direction?
I don't know how this is going to affect future generations. Less so because of the change to the software engineering profession, but because I think that the world that LLMs is opening up is asking some pretty fundamental questions about how we work as societies and we don't yet know how to respond to all of the changes. Those questions are going to be much more fundamental to the question of future engineers than is going to be the question of how an individual engineer is doing to use agentic coding tools. There is so much more that we need to discover and build. For sure, it's a seismic shift, but it's just the tools that are changing, not the fundamentals.
I mostly worry here about how much we are all going to become dependent on large corporations, particularly in Europe where we have nothing to show for, and more labor will be absorbed by US capital.
I entirely agree with you that punching the keyboard is not the important part, it could be writing runes or throwing wood and bones or talking to machines genies. I think where I'm struggling is if and when you ask an LLM to work on a task you are passively familiar with. A couple years ago, you would have done this yourself, maybe research and try out some code in the process and push your understanding. Here, an LLM can come up with reasonable looking and working code, you are faster but the knowledge building is lessened. You will probably tell me I should slow down and understand every moving part but in my opinion, it's much more difficult to do so when you are pressed for time and the solution is right there. I usually don't use LLMs too much at work for that reason, because I want to understand and be responsible for every line of code. For personal projects, I don't really mind but it's harder to navigate where the help happens and where I might be delegating decision-making, especially if I'm less familiar with the material. Maybe it's a me problem but I think a lot of people struggle with this. It's also why I've been really interested in what you've been writing, the experience seems completely different.
I'm also European and I share a lot of your worries.
I think where I'm struggling is if and when you ask an LLM to work on a task you are passively familiar with. A couple years ago, you would have done this yourself, maybe research and try out some code in the process and push your understanding.
I find that I find it much easier to learn with an LLM, particularly because it's so good at adapting to my understanding. We're not paid to do work we don't understand as engineers, and even if we write our own projects, we better not ship things we don't understand. But with an LLM I can trivially work my way through much harder problems because I can get the LLM to pull information into the context, help me review it and set things in context.
I don't really mind but it's harder to navigate where the help happens and where I might be delegating decision-making, especially if I'm less familiar with the material.
I will say that initially there is for sure a feeling that you can just turn off your brain, but it really does not scale and you learn that lesson quite quickly.
There is the risk of not knowing what is being happy-path-shortcutted away and whether you need it. Not exclusive to LLMs — MongoDB tutorials that were leaving unauthenticated world-reachable instances if executed on servers come to mind as a well known failure case; for LLMs I guess «knowledge needed for debugging» might be deferred for new stuff. Although it depends on what exactly you ask.
(From that point of view a slightly weaker LLM can even end up safer… and also locally runnable. Maybe open-weight ~200B Qwen/Mistral models in a few years will be a sweet spot?)
For me, one source of anxiety about the future we're heading toward can be seen by looking at the "Choice Of Language" section in your Agentic Coding Recommendations article. You settled on Go, Tailwind, and React. On the backend, I don't think I have to convince you that Rust has some significant advantages over Go, in terms of verified safety and expressiveness. On the front-end, criticisms of typical React-based stacks are widespread, particularly from those who care deeply about working with the grain of the web platform for maximum accessibility in the broadest sense of the term, including running efficiently on low-end devices. So, I have trouble interpreting these choices as anything other than casting aside quality in the name of producing more, more, more, ever faster. Maybe that's an overly cynical interpretation, though.
I find it fascinating that articles like this are still being written. This would have made a lot of sense if it had appeared in February or March of this year
I only recently stumbled upon the MERT paper that suggests otherwise, though it's based on early-2025 models. Are there any more recent studies on the matter?
I don't have any experience with the "agentic" type of AI tooling, but the Copilot-like AI completion tools were quite irritating and disturbed my workflow.
I have also heard a few horror stories related to using AI-based LSPs in old C/C++ codebases. One wrong "go to definition" action can waste hours of work, making you look at the wrong class and mess with the programmer's head by being non-deterministic.
So, from my perspective, this is far from being a clear-cut matter.
I only recently stumbled upon the MERT paper that suggests otherwise, though it's based on early-2025 models. Are there any more recent studies on the matter?
I have no idea. But what I can tell about this particular study is that it was in Sonnet 3.7 times prior to Claude Code and this is just not at all in any way comparable to what has happened since. I have written about this before so if you're curious you can read up on why so much changed with Claude Code: https://lucumr.pocoo.org/2025/6/4/changes/ (this post is from June).
So, from my perspective, this is far from being a clear-cut matter.
You admitted yourself that you're not using authentic AI tooling and so I can only reiterate these are completely different worlds that are entirely non comparable.
I have written about this before so if you're curious you can read up on why so much changed with Claude Code: https://lucumr.pocoo.org/2025/6/4/changes/ (this post is from June).
Thank you! I just realized that I read your "I Think AI Would Kill my Wife" article quite a while ago (I still have doubts about letting an "agent" direct access to my PC).
You admitted yourself that you're not using authentic AI tooling and so I can only reiterate these are completely different worlds that are entirely non comparable.
I cannot deny it, though they didn't seem much different from other AI-based tooling before you emphasized it. Looks like I need to take some time and give a tool like Amp or Claude Code a proper try (most probably in a sandbox).
Horsehoe theory:
I still have doubts about letting an "agent" direct access to my PC
— I have doubts about letting browsers unchecked access to my PC, so sandboxing investment to try an agent is close to zero (my dislike of un-freezable dependencies is another story, which is why I am trying to learn best what various 30B-A3B versions of Qwen are useful for, and where 27B version of Gemma3 is still better)
(But yeah, in any case I highly recommend having a sandboxing tool around that allows easy RO and RW bind-mounts, it is a multi-purpose capability)
Agreed. There’s nothing magical going on here with using coding agents. It’s the same stuff I was doing with myself or with a pair Eng. I tell the agent to tdd and it does a great job at that because it has a validation step. I force the code agent to validate their work and once you do that it’s pretty competent. It’s also amazing at debugging just by reading your code. I tell skeptics all the time: just use it as a read only search engine catered to your codebase. You’ll have huge shortcuts just from that alone
For one, very few people are actually trying coding agents today. Adoption is still extremely limited.
I am not sure how our experiences diverse so much on this topic. I can't point a single developer around me who haven't tried coding agents. Would you care giving more details on who are these people? My data points are the ones in start-up/scale-up is the limited adoption at big enterprise level?
I can't point a single developer around me who haven't tried coding agents.
There's a huge difference between trying an agent and actually using one. Becoming productive with a coding agent takes a surprisingly long time. The learning curve is nit very steep, but it's long and slow; it took me over a month before things really clicked.
My experience is that many people say they've tried it, but never got past the unproductive phase. As a result, they conclude it doesn't help and move on. I'm reminded of this repeatedly now because it's Christmas and people in my circle whom I talked to about this back in May only just found the uninterrupted time to properly sit down with it.
Once they did, they were struck by how different the experience is when you actually push through the learning curve.
I am this but slightly more enthusiastic, sure:
I might call myself a “conscious LLM-skeptic”. That is, while my attitude towards LLMs is far from enthusiastic, I do use them and have found them genuinely useful on multiple occasions in day-to-day programming.
and I identify with this:
So why the anxiety, instead of, say, enthusiasm? I guess a large part of it is due to the change itself. Especially given the pace of it. A lot of things that I have grown accustomed to are now different than what they used to be; things that I had taken for granted no longer are. > Change naturally breeds anxiety.
and especially this:
But the older I get, the more I keep coming back to this attic analogy. Especially since I’ve learned about my ADHD a few years ago. I now believe that Holmes has a point here: that one needs to be careful and conscious when deciding what to furnish their brain with. Not necessarily with respect to facts, as per Holmes, but certainly with attention.
Here it's hard not to think about this old M. Aurelius quote: The things you think about determine the quality of your mind. Your soul becomes dyed with the color of its thoughts.
Author's conclusions:
I care about the fundamentals of my craft... Most importantly, I care about the fun I’ve had
I'll keep using LLMs, too, but I find increasingly that their main use for me is to get to the interesting parts of the craft faster. In terms of personal use, if I use them thoughtfully, I get a lot out of them. I worry a great deal of what wreckage and expectations they are creating at work, though.