Speak for yourself, OP. I have my gripes with LLMs but they absolutely can and will help me create and understand the code I write.
> At least, they value it far less than the end result.
This does not appear to apply to OP at all, but plenty of programmers who like code for the sake of code create more problems the solve.
In summary, LLMs amplify. The bad gets worse and the good gets better.
The thing I don't value is typing out all of that code myself.
Is it wild the thing I took a while to learn is now done basically by a GPU? Yes. But hand writing code is not my identity. Never has been.
This happens, but it's only one way to use a coding agent. I'm working on a small, personal project, but I ask it to do "code health" tasks all the time, like complicated refactorings, improving test coverage, improving the tooling surrounding the code, and fixing readability issues by renaming things. Project quality keeps getting better. I like getting the code squeaky clean and now I have a power washer.
You do have to ask for these things, though.
Some people like using hand tools and others use power tools, but our goals aren't necessarily all that different.
I've found it very unsatisfactory (both experience and results) to use them to replace code production. But in terms of augmenting the process - used to critique, explore alternatives, surface information - they're getting really quite handy.
If you try to do anything outside of typical n-tiered apps (e.g. implement a well documented wire protocol with several reference implementations on a microcontroller) it all falls apart very very quickly.
If the protocol is even slightly complex then the docs/reqs won't fit in the context with the code. Bootstrapping / initial bring-up of a protocol should be really easy but Claude struggles immensely.
The sloppier a web app is, the more CSS frameworks are fighting for control of every pixel, and simply deleting 500,000 files to clear out your node_modules brings Windows to it's knees.
On the other hand, anything you can fit in a small AVR-8 isn't very big.
Whatever you do, your mileage may vary.
Claude Opus 4.5 is truly impressive.
The reality is that the vast majority of software is nowhere near those levels of priority aside from the big social media apps. Like many jobs, many apps out there are helpful because they increase the money flow in the economy not because they are critical
For an old grey beard, this is actually fine, but if you're still in love with coding, it must be a loss.
I value writing and playing my own music.
Most are happy enough to listen to other people’s music.
Somehow with music this isn’t a religious war.
My point is, though, it occurred to me why he's excited about it. He has no ability whatsoever to write music in notes, or song lyrics. But with his tool, he's able to make music that he finds decent enough to feel excited about helping to shape it.
No criticism to those who can't do a thing on their own, but are excited to be able to do it with a tool. And yes, you can certainly elaborate on and debate craftsmanship, and the benchmarks and measures of quality of an end result when made through expert skill and care, or by amateurs with a powerful (and perhaps imperfect or imprecise) tool.
So personal anecdote, using generative code has not interested me personally, because I love writing code, and I'm very good at it, and I'm very fast. Of course machines can do things faster than me (once I learn the different skill of prompting), but speed hasn't really been a massively limiting factor for me when trying to build things. (There are lots of other things that can get in my way!)
I'm reminded of the oft used quote, "He who can, does; he who cannot, teaches" - George Bernard Shaw. (Just, now the teaching is that of a machine, who then does.)
Interestingly, "Suno" in one of the world languages (Hindi) means "listen".
they can not only generate code but also explain code, concepts, architecture and show you stuff
great learning tool
This comes with the assumption that everyone is vibe coding. Which just isn’t the case in the professional circles I’m part of. People are steering tools and putting up guard rails to save time typing. The “creating” part of coding has very little to do with the code, in fact my perspective is that it’s the most insignificant part of creating software.
At the end of the day, how code gets into a pr doesn’t matter. A human should be responsible to review, correct, and validate the code.
FWIW I find these statements trivializing of the craft and the passion. Some of us do like the craft of creating a massive structure that we understand from the pylons to the nuts and bolts. Reviewing AI-generated code doesn't bring us close to the understanding of the problem that comes from having solved the problem ourselves.
If this level of detail-orientation doesn't interest you, that's fine, and it perhaps shouldn't bother you to have someone say that? We can agree these are subjective values.
This is very similar to the statement - People who love using Python (or other language not C or assembly) to create software are loving it because they don’t value the act of creating & understanding the software.
Also the whole I am more productive vibe, well management will happilly reduce team size, it has always been do more with less, and now the robots are here.
Each day one step closer to have software development reach the factory level.
Yes some will be left around to maintain the robots, or do the little things they aren't still yet able to perform (until they do), and a couple of managers.
All the rest, I guess there are other domains where robots haven't yet taken over.
I for one am happier to be closer to retirement, than hunting for junior jobs straight out of a degree, it is going to get though out there.
- Person learns how to do desirable hard thing
- Person forms identity around their ability to do hard thing
- Hard thing is so desired that people work to make it easier
- Hard thing becomes easy, lowering the bar so everybody can do it (democratization)
- Good for society, but individual person feels their identity, value and uniqueness in the world challenged. Sour grapes, cope, and bitterness follow.
The key is to not form your identity around "Thing." And if you have done so, now is the time to broaden this identity and become a more well rounded individual instead of getting bitter.
You should form your identity around more lasting/important things like your values, your character, your family, your community, and the general fact that you can provide value to those around you in many ways.
No, in 10 years you probably won't be able to reach the top 1% of society by responding thumbs up to slack messages and then re-creating a dropdown in React for the 100,000th time. But you were smart enough to figure out how to do [Hard thing] in the first place. You will absolutely figure out other valuable things to contribute that you will also enjoy doing.
For instance, I use a React form library called Formik. It's outdated and hasn't seen a real commit in years. The industry has moved onto other form libraries, but I really like Formik's api and have built quite a bit of functionality around it. And while I don't necessarily need a library to be actively worked on to use it, in this instance, it's lack of updates have caused it to fall behind in terms of performance and new React features.
The issue is that I'm also building a large, complex project and spend 80-90% of my waking time on that. So what do I do? Do I just accept it and move on? Take the time to migrate to a form library that very well be out-of-date in a year when React releases again? Or, do I experiment with Claude by asking it to update Formik to using the latest React 19 features? Long story short, I did the latter and have a new version of Formik running in my app. And during that, I got to watch and ask Claude what updates it was making and most importantly, why it was making those updates. Is it perfect? No. But it's def better than before.
I love programming. I love building stuff. That doesn't change for me with these tools. I still spend most of my time hand-writing code. But that doesn't mean there isn't a place for this tech.
> I’ll likely never love a tool like Claude Code, even if I do use it, because I value the task it automates. [...] Like other technologies, AI coding tools help us automate tasks: specifically, the ones we don’t value.
Where the article talks about value, you're talking about time [savings] - but you both actually mean the same thing: Getting a fair amount of value for the time spent.
I also don't seem to get your React Formik example... programming isn't solely about "SemVer numbers going up", it's about designing powerful abstractions for (re-)occurring problems. Being on the consuming side of a UI form library is something different from designing its API.
For one thing, I'm sure stable products have been build with Formik@1.0.0^ (it's at @2.4.9 currently). For a second thing, I don't think doing the manual labor of playing a smarter dependabot is as valuable as you think it is. Formik still has 3 million weekly downloads with its latest release being 2 months old, why don't you upstream your changes?
It's extra hilarious to hear someone you _thought_ treated their code work as a craft refer to "producing 3 weeks worth of work in the last week" because (a) I don't believe it, not for one bit, unless you are the slowest typist on earth and (b) it clearly positions them as a code _consumer_, not a code _creator_, and they're happy about it. I would not be.
Code is my tool for solving problems. I'd rather write code than _debug_ code - which is what code-gen-bound people are destined to do, all day long. I'd rather not waste the time on a spec sheet to convince the llm to lean a little towards what I want.
Where I've found LLMs useful is in documentation queries, BUT (and it's quite a big BUT) they're only any good at this when the documentation is unchanging. Try ask it questions about nuances of the new extension syntax in c# between dotnet 8 and dotnet 10 - I just had to correct it twice in the same session, on the same topic, because it confidently told me stuff that would not compile. Or in the case of elasticsearch client documentation - the REST side has remained fairly constant, but if you want help with the latest C# library, you have to remind it all the time of the fact - not because it doesn't have any information on the latest stuff, but because it consistently conflates old docs with new libraries. An attempt to upgrade a project from webpack4 to webpack5 had the same problems - the llm confidently telling me to do "X", which would not work in webpack 5. And the real kicker is that if you can prove the LLM wrong (eg respond with "you're wrong, that does not compile"), it will try again, and get closer - but, as in the case with C# extension methods, I had to push on this twice to get to the truth.
Now, if they can't reliably get the correct context when querying documentation, why would I think they could get it right when writing code? At the very best, I'll get a copy-pasta of someone else's trash, and learn nothing. At the worst, I'll spin for days, unless I skill up past the level of the LLM and correct it. Not to mention that the bug rate in suggested code that I've seen is well over 80% (I've had a few positive results, but a lot of the time, if it builds, it has subtle (or flagrant!) bugs - and, as I say, I'd rather _write_ code than _debug_ someone else's shitty code. By far.
> we automate stuff we don't value doing, and the people automating all their code-gen have made a very clear statement about what they want to be doing - they want _results_ and don't actually care about the code (which includes ideas like testing, maintainability, consistent structure, etc)
It's like the "bucket" tool in Paint. You don't always need to click pixel by pixel if you already know what you want to fill.
Whatever your design document/spec, there are generally a lot of ways and variations of how to implement it, and programmers like the OP do care about those.
You don’t have Paint perform the flood fill five times and then pick the result you like the most (or dislike the least).
> Whatever your design document/spec, there are generally a lot of ways and variations of how to implement it, and programmers like the OP do care about those.
Of course, there are many ways to write the same thing, but the end performance is usually the same (assuming you know what you are doing).
If your spec is strong enough to hold between different variations, you shouldn't need to worry about the small details.
I havent run into this type yet, thankfully. As an AI lover, the architecture of the code is more important than before.
* It’s harder to understand code you didn’t write line by line, readability is more important than it was before.
* Code is being produced faster and with lower bars; code collapsing under its own shitty weight becomes more of a problem than it was before.
* Tests/compiler feedback helps AI self correct its code without you having to intervene; this is, again, more important than it was before.
All the problems I liked thinking about before AI are how I spend my time. Do I remember specific ActiveRecord syntax anymore? No. But that was always a Google search away. Do I care about what those ORM calls actually generate SQL wise and do with the planner? Yes, and in fact it’s easier to get at that information now.