One reason would be to raise the ceiling of what your project can do within the budget of time and motivation you have. Or, as it often happens, to be able to finish the project at all.
A credo I have held for some time is:
When making software, remember that it is a snapshot of
your understanding of the problem. It states to all,
including your future-self, your approach, clarity, and
appropriateness of the solution for the problem at hand.
Choose your statements wisely.
I don't code for a living in any way, but I teach IT. And for years and years I've had little script ideas and tasks (e.g. music organization) that worked decently, but also life got in the way and I have that thing where I want it to work just right etc, and now that the pipeline is orders of magnitude shorter, man this stuff is FUN for me again.
It's more a big picture view of everything tech related that I see as important to be aware of, as well as filling in some blanks. Most of my students get "straight up programming" in other classes. So I actually have always done "here is Bash scripting and what it's good for." And I definitely teach "the controversy," e.g. This AINT what you want for big and professional, but also, knowledge of bash (and similar) is a very useful "swiss army knife."
The actual issue is that then you need something still that makes money. I think, for a programmer, that's fairly unproblematic too, for the foreseeable future: all those agents will need direction. Anyone can do that up to some level of complexity on their own, sure, but it simply is hard for humans to structure requirements and reason about a big enough systems and I don't see demand for those decreasing.
This sounds very strange.
I'm using Claude (Opus 4.5 via Code) every day and it's very good with regexes, sed, awk and similar bash oneliners.
We don't know what the author asked it to do, but this smells like the problem started at least several messages before that.
To author's point: code brings me joy. I'm currently learning Zig, for no reason whatsoever other than intellectual challenge and I, subjectively, like the language. I'm writing silly little programs that nobody will ever see. It's fun.
Then I switch over to a paid project, and claude[0] another task from my backlog.
There's code, and then there's code. You can find joy in some code and absolutely want to avoid coding in something else.
[0] code using Claude
Author here. It was what I assumed would be a fairly simple task, fixing some duplicate closing frontmatter delimiters.
I think the LLM took a wrong turn early on, and then just spiralled. It was morbidly fascinating watching it rabbit hole.
Oh yes, it's like slow-motion train wreck.
Once it gets off the rails, the best thing is to nuke the context, reset the state (git reset --hard or equivalent) and retry, this time with foresight.
So much this! Nondeterministism in LLMs does not mean you simply "reroll" your prompt and hope for the best; the incremental reprompting is what helps.
The joy aspect aside, if you're writing code professionally obviously that is no substitute for knowing how Awk works because you still need to make sure that what it produced is correct, because I sincerely hope that you're not pushing code into production, in particular not a piece of code some tool got wrong for 20 minutes, without understanding what it does.
If that were an intern rather than a machine and you as the programmer don't know how the code works you're not doing your job. AI systems have not freed people from acquiring "arcane knowledge" it makes that knowledge more important than ever, the only thing it does is type faster than you do.
> I sincerely hope that you're not pushing code into production... without understanding what it does.
I do not. That hasn't changed.
> ...the only thing it does is type faster than you do.
LLMs can do many, many things that I cannot. Their breadth of knowledge dwarfs mine.
Anything more "serious" (client work, for example) usually falls within my sphere of knowledge, at least to the point where I can accurately review the LLM's solution.
My long-standing habit of practising TDD also helps.
One can certainly enjoy the laborious handcrafted process of building your own table, and yet go back to a shop that churns out cheap furniture that’s nonetheless useful for many others, and see the value in both.
Obviously there’s more degrees of freedom in software, but I’m trying to see it that way to rationalize how I’m feeling with the current state of things.
I am curious where this train of thought has come from. For decades, there have been
a) some human programmers who worked faster than others
b) other non-LLM programming tools that enabled productivity boosts
While maybe (maybe?) slower programmers aspired to be faster, and maybe (maybe?) their managers wished they were faster, it was generally accepted. You might have someone who codes slowly, or medium, or fast, or superhuman fast. Just so long as they were "fast enough" for your business needs, it wasn't a huge issue. There wasn't a culture of shaming all of the medium-speed programmers into the ground.
And while maybe some programming tools did indeed offer productivity boosts, there really wasn't a culture of demanding all possible boosting tools be used. If you want to use Nano to edit, great, up to you. Emacs? Great. Visual Studio Code? Great. Debuggers? Great. Print statements? Great. Outside of some highbrow programmer ivory towers, there wasn't a widespread insistence that "only these tools shall be used because they let you write code the fastest".
But now it seems that there is demand that LLMs be used to write code as fast as possible as possible.
Why? Why now, is it suddenly important that code be written as fast as possible, and anything less should be mocked and derided?
And I have first hand seen programming teams where there was clearly more than a 25% difference — some could code much, and some could barely code at all.
I think it would be quite fair to say that, between tools and individual skill, there could easily be a 5x speed difference between slower and faster programmers, maybe more. Granted, LLMs are even faster, but I don’t think a 5x potential speed up was a slouch.
The slow developers have false starts, have to rework their code as they discover edge cases they didn't think about before, or get all the way through and realize they've solved the wrong problem altogether, or it's too slow at production scale.
You still write the code! We do lots of things that could be done more efficiently. People build their own furniture and make their own clothes and brew their own beer. If you love doing something for its own sake, keep doing it.
I'll give some examples:
Novel algorithms: PageRank, BitTorrent, Like buttons, disappearing pictures, etc.
Artistic styles: Cubism, impressionism, Wes Anderson, etc.
The above algorithms are (relatively) straightforward to implement and could be implemented by Claude Code in a matter of hours if not minutes. But, you'd still need a means to distribute them.
Similarly, you can have AI generate an image in any of the above styles (or a combination thereof), but the image won't have intrinsic value unless you can finds a means of (profitable) distribution.
Put another way, there's limited value in being able to master physical tasks (playing piano, typing fast), but fundamental skills that lead to creative innovation will remain important...along with being able to package/market/distribute the AI-implementation of your ideas.
I'm starting to think programming might become the same thing; people that program will be the people that just like to tinker with code and have no real ideas to implement, while the people that have ideas will use LLMs to implement the code so they can just work on their idea.
I've seen the same thing with Linux. There are people that like to tinker with Linux, playing with every setting and every window manager, but don't actually use the computer to DO anything, and then there are people that don't care what the OS is, and are just using the computer as an actual tool to get something done.
So people installing and tinkering with Linux but somehow not being able to install a browser?
In reality I think depth of tinkering and productivity are two separate axes. I’ve seen plenty of examples of all combinations of each extreme.
You can get a hand-crafted, beautiful, solid, chair made by a guy who knows all the tricks of carpentry. He's spent his whole life perfecting the technique of how to drill the holes, how to fit everything together, how to balance the chair.
It used to be the only way.
Then someone invents a machine that can make you a hundred crappy chairs. Sometimes the legs don't fit in the seat, sometimes the chair isn't balanced. But it's close enough often enough.
On top of it, the new tool is not in the lineage of the old tools. It doesn't FEEL like you are crafting a chair.
Conventionally programming software needed you to know your tools like language, framework, OS, etc. pretty well. There’s a divergent set of solutions dependent on your needs and the craftsmen (programmers/engineers) you went to. Many variables you needed to know to produce something useful. You need to know your raw materials, like your wood.
With LLMs it’s weirdly convergent. Now there’s so many ways to get the same thing because you just have to ask with language. It’s like mass produced furniture because it’s the most common patterns and solutions it’s been trained on. Like someone took all the wood in the world, ran it through some crazy processing, and now you are just the assembler of IKEA like pieces that mostly look the same.
There’s a lost in necessity in craft. It helps to know the underlying craft, but it’s been industrialized and most people would be happy enough with that convergent solution.
If I had a nickle every time I heard the equivalent of "close enough often enough" on root-cause analysis bridge calls during prod outages...
I had booked a trip to Cartagena. I hadn't realized that I arrived on Fat Tuesday, and I don't think that it would have mattered.
Arriving there, bathing in the insubstantial "joy d'vivre," the sinking feeling lifted.
I remember that well, and it's cure. I love Latin America for this reason.
Point is though, you don't need to see the code to debug it, so the fact that the code was generated should not be the thing holding you back.
---
When given only three words, is the rewrite any good? When given to a human intern, would it be any good? Instead "refactor the foo that's repeated n bar, baz and qux into one reusable shared class/component/the appropriate thing for the given language" is good actual software engineering that a human would do, or ask an intern to do.
This sounds like an awful way to debug. Operating on less information just makes things harder for no reason.
If you just need a regex, why are you letting Claude Code run rampant all over your code base? Just use a web gui? Or another terminal?