Why I don't have fun with Claude Code

> People who love using AI to create software are loving it because they don’t value the act of creating & understanding the software.

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.

> People who love using AI to create software are loving it because they don’t value the act of creating & understanding the software.

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 than they solve.

In summary, LLMs amplify. The bad gets worse and the good gets better.

There may be a developmental arc to this. I once enjoyed programming, in all its forms. I loved to express my ideas as projects. Now after three decades of programming, I have seen 95% of the problems I have to solve in any given project before, and that enjoyment is no longer there. So for me, Claude Code is simply excellent. I was once a Systems Engineer, so writing specs, requirements and architecture documents is second nature to me, and I can easily review the code it comes with - but I no longer need to write CURD, boilerplate and all that jazz, not to mention managing dependencies and version creep in libraries.

For an old grey beard, this is actually fine, but if you're still in love with coding, it must be a loss.

I think this is a reasonable article and I do understand the perspective. It's a normal sentiment from those witnessing a craft that they have invested time in mastering become partially automated. However obviously the big picture (as the article alludes to) is that none of us are paid to write software, we're paid to solve problems as efficiently as possible and these tools, used wisely, can massively help with that.

I don't feel this way, but that's because I see them as the coding buddy I never had rather than a slave that knocks off tickets for me.

Now I can try two or three implementations of something that I can throw away in the process of really understanding a problem and then quickly do it right.

Instead of spending a day tracking down a problem in my mental blind spot I have a 70% chance of getting the answer in two minutes.

Instead of overthinking the documentation I can have a prototype running in 10 minutes.

I enjoyed writing git commit messages. I value good commit messages. But at work I recently created a slash command (for those who don’t know, it’s like a snippet for anything) that writes a git commit for staged changes with optional jira tags. Although I always end up amending it, it is so convenient. Does it mean I don’t value good git commit messages? I don’t know… I try my best to review every commit at least.

Here’s a big difference.

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.

> People who love using AI to create software are loving it because they don’t value the act of creating & understanding the software.

That's a pretty sweeping generalization. Just because I don't value the act of typing into a keyboard doesn't mean that I don't value the craft of creating and understanding software. I am not outsourcing my understanding to the LLM, I am outsourcing the typing of the code.

What you are describing is not engineering, it's (pardon the phrase) vibe coding. Claude Code is just a tool, and everyone is going to use that tool differently. There is nothing inherent in the tool itself that requires you to surrender your agency and understanding. If you do, that's on you, not Claude.

I like learning in the pursuit of a goal. I’m greedy. If there’s no learning then I can’t care about the goal, and if there’s no goal then I can’t care about the learning. Actually I see no reason to live at all without this. The evidence is in that most of you guys value the goal above all else, so I’m just going to get outmoded. I think with that inevitability I can either make this short or I can let it be painful.

> People who love using AI to create software are loving it because they don’t value the act of creating & understanding the software.

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.

> People who love using AI to create software are loving it because they don’t value the act of creating & understanding the software.

Most people have a car just to get around, it's true, and some people love tinkering with cars and engines. The car you get around in doesn't have to be the same car as the one you tinker with.

I’ve always enjoyed creating working things for people to use. Which is why I love LLM coding agents.

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 resonates with my own anxiety: https://blog.danieljanus.pl/2025/12/27/llms/

Posted a similar thing yesterday: https://news.ycombinator.com/item?id=46719579

I liked the summary of what you do besides write code, and those things are enjoyable to me too. Understanding something better by writing code that unravels the mystery is a treat, but also sometimes frustrating.

I still do enjoy having an LLM help me through some mental roadblocks, explore alternatives, or give me insight on patterns or languages I'm not immediately familiar with. It speeds up the process for me.

> Ultimately, I don’t want my computer’s OS to be vibe-coded, nor my bank’s systems, nor my car software.

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

> People who love using AI to create software are loving it because they don’t value the act of creating & understanding the software.

Why assign YOUR feeling about an interaction to everyone else? LLMs coding agents are a tool for me to investigate and learn about what I'm doing. For others they can be a therapist, or organizational tool, or whatever.

I think we can boil down the sentiment in this article to roughly this pattern:

- 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.

The origin of the Steinmetz anecdote is less clear than the essay's footnote would suggest:

https://quoteinvestigator.com/2017/03/06/tap/

I get the authors spirit of this article, but a statement like “ People who love using AI to create software are loving it because they don’t value the act of creating & understanding the software.” Just kinda comes off as insulting.

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.

I think these types of articles miss the point. It's not about not loving what I do, or not being interested in problem solving. It's about time.

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.

> People who love using AI to create software are loving it because they don’t value the act of creating & understanding the software.

I'm as critical of AI code generation as the next guy, but unfortunately we live in a world of lots of accidental complexity forced on us, and it's not surprising that a lot of people are simply relieved that they can leave some of the boring and frankly exhausting footwork to collect all the necessary boilerplate to some assistant. That allows them to focus on high level understanding and the actual creative part, rather than the opposite, as OP suggests here.

If you have to review the code afterwards before you ship it because you have to take responsibility for it then you have to know how to code it yourself.

I, personally, don't understand what it is people enjoy about using these tools. I find them tedious, boring, and they often make me angry: subtle bugs and outright lies in the output and no prompt can resolve the problem so I end up having to fix it by hand anyway. It's not pleasant for me.

But other people do and while I don't get it I try not to yuck in their yum too much.

There is no empathy from companies though. They don't care about code and never have.

They should though. Every line of code is a liability. And now we have tools that can generate liability on demand faster than a team of dedicated humans who are trying to be conservative about managing that liability. You still have to be careful of course but now you're taking responsibility for what the machine generates. You're not the one driving anymore and using a tool. You're a tool being used. At least, that's how I feel about it.

Of course to capital holders and investors this doesn't matter, so we may end up being forced to use these tools even if they're not sufficient or useful. Even if they generate liability. We're rather good, as an industry, at deflecting the consequences of liability.

I'm more the final product oriented. I think this made me a less good developer but hopefully I'm going to thrive in the newer world.

coding agents are fantastic for learning more about computers

they can not only generate code but also explain code, concepts, architecture and show you stuff

great learning tool

To each their own. I’m certainly having fun building things and iterating faster on personal tools and projects

The line "for me that just throws out the baby with the bathwater" made my day

I am full in line with the sentiment expressed on the post, and can't wait for the whole must use AI bubble to implode.

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.

Yeah. Whatever. The sort of person that would share their completely baseless assumptions of the motivations of people that aren’t them, is exactly the sort of person that I’d expect to be elitist enough to believe this delusion in the first place. This is dripping with insecurity. If I were interviewing you I wouldn’t touch you with a 60 foot pole. A huge red flag for you to think that the reason that you don’t “get” something is because you’re so much of an enlightened artisan than everyone else.

It was never really about typing the code for me, or solving trivial tasks in isolation.

It was always about building the right abstractions, great api surfaces, growing codebases without having them collapse under their own weight, etc.

I still get to do that everyday with claude code and arguably faster. I just have to be on top of it at all times. So I've kept having fun!

What I don't understand is the people that stopped reading and iterating on the code. That's just insanity to me!

This post brings up a lot of (imo true) points that I honestly can't share with the ai-lovers at work because they will just get in a huff. But the OP is right - 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 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.