Say what you will about the Claudisms in this piece, this bit certainly rings true for me. With old school coding, there was always a reward at the end, the harder it was, the more satisfying it felt.
With agentic coding, I really doesn’t feel like that, at least not in the same way. It feels more like continually riding a wave of productivity, where small features or huge features have similar levels of interaction required. And that’s exciting in the beginning but quickly becomes very tiring.
Features might be easier to create, but I rarely ever get the feeling of I did that anymore from writing software.
"I told the LLM to do that" is different and far less satisfying for me.
Better to find joy in other parts of the process! Hanging clothes out is still a widespread practice in Europe, and some enjoy it. Likewise for software quality controls, testing, and full product lifecycle.
Sometimes I want to cook, that’s a thing I want to actively do. Sometimes I cook because I want to put dinner out, dinner being out is the thing I want and cooking is just a required step.
Sometimes I want to solve a problem, sometimes I want a problem solved.
Here’s the tricky part for me now and I think others are hitting it - when a machine can solve the problem does that devalue the feeling of doing it by hand? Solving a sudoku feels good even though I know I have multitudes of machines in my house that could solve it faster than I could pick up the pen. Games that place a dollar value on some item I can also achieve makes me feel like the effort is only worth $ though. This isn’t logical but I’m ok being human.
So for a personal project do I get the same feeling doing it by hand? Will it feel like I’ve just made my life harder for no reward or will it be a nice satisfying thing?
As the models get so much better the goalposts shift too, the less I direct the less I was needed.
It’s a weird time. Fascinating, exciting and definitely useful - but so much of what I’ve learned is rapidly becoming less and less important for many tasks. Still, I’ve argued for many years that more people should code because it’s such a powerful tool even used basically, I guess I’ve got my wish (and that side I genuinely love, seeing people make things with their domain knowledge and not having to learn exactly how brackets work in order to automate something)
Now for every problem I know Claude/Codex will do it, and they do. I just don't get that feeling on finishing 10 features now.
That’s why a was always keen on cutting some corners when and where necessary in order to think about the user first and the code beauty second.
Of course I appreciate well structured and maintainable code but you can always strike a balance, even with LLMs assisted coding sessions.
It is more accurate, in terms of, it only matters when something goes wrong.
Edit:"On the hook" is a general expression that means if something goes wrong it lands on you as the responsibile party, generally in a negative way. As in, if it goes right, you don't get kudos, if it goes wrong, you're on the hook for it
my anecdotal advice is to avoid the entire "agent" temptation, and treat the LLM as a code generator. have a single session running at a time. come up with a plan, iterate on it until you are satisfied, then tell it to execute the plan, and watch it. not necessarily to the extent of reading the scroll (though I sometimes do do that too!) but as it finishes each step look over what it has done, suggest improvements and course corrections, and then let it go on to the next step. at the end you will have a pretty good grasp of the state of the code, and the overall time it will take you isn't really any longer than trying to churn out reams of code and then go through it all at once.
the other option if you want something closer to a one shot workflow is to go into far more detail during the planning stage, have it describe not just architectural details but actual code (if you're a senior engineer especially you probably know what the key pieces of code that will drive a lot of other decisions mechanically are likely to be).
also refactoring is cheaper than it has ever been, if something feels hard to grasp to you stop and work with the LLM until you like the looks of it better.
and again, the key bit is to have one LLM doing one thing at a time, and to stay engaged in the process while it does so.
Edit: I will say it's taken me some months of working with Claude to get to this working process. If you let claude operate with free reign, the inevitable mess and struggle it runs into burns and stresses you out. Also, keeping up with some manual coding when you feel like it and punting to Claude when you have had enough manual coding ensures you still feel in control of the codebase.
We want to end up with code that makes sense generally, to whomever is editing or or debugging it in the future. That next-person usually won't (or shouldn't need to) mine the git history to understand the current project in front of them.
when the stack is complete and all the commits are uploaded to wherever (we use phabricator but i'm sure github has an equivalent) for review i just need to sit back (or work on something else) while my reviewer(s) go through each commit and validate that it looks like it does what it says on the tin. as soon as the bottom of the stack gets approved i can merge it in, or i can wait for everything to be reviewed. if there are any changes i do them and rebase the rest of the stack on top of the changed commit, fixing merge conflicts if needed. (it really helps if your tooling supports this workflow, of course!). and when it's all reviewed and merged, the effect is exactly the same as if i'd just sent in a 2000 line combined commit and merged it in - there's no need to go look through the git history for anything, the code will hopefully make sense as part of the codebase.
I noticed the opposite. When reviewing and directing a colleague or subordinate, I spend probably 30% of my brain cycles, and 70% of my activation energy, to weigh the technical merit of my feedback against the human impact it will make: bruised egos, differing architectural convictions, correct and polite tone of comments, additional workload for the colleague. The dread of potentially seeing that the code is not good at all, and needing to decide _what to do in that situatuon_, trading off technical debt in the future vs team dynamics and psychological impact right now.
LLM does not care about any of that. It is so much easier.
Right, it's more like pulling the lever on slot machine. Oooh, 677, bad luck, do a ritual and try again, and maybe this time...
Sure, regular programming also has a feedback loop, but normal errors are--as much as possible and by design--things that happen consistently for reasons, reasons that force you to engage you mind to discern them and then eliminate them (hopefully) forever. Experienced developers don't just try something random, hope it works, and if it works you just dismiss it as unknowable.
> But the bottleneck was never the code. It was always the human attention, the engineering judgment, the ability to hold a coherent vision for a system. We just didn't notice because writing code felt like the hard part.
Unless, perhaps, you were already fatigued trying to deal with many stakeholders who can't agree what the system even is. :p
Then when I learned more I got less and less of that guessing feeling. I understood what I was building and what would work, I began using typed languages and could keep on track with the compiler/LSP. This brought me more into a satisfying flow state, and I had less of that addicting "wait let me see if this will work" magic.
It seems like coding with Claude etc is a lot like a trip back to the guesswork stage, and I don't want to go back there.
(Sometimes, when I'm doing some dev-opsy type stuff of stringing a bunch of messy components together or working with a pile of complex APIs, I can feel myself back in the blind guessing territory, and incidentally this is where I find a chat with an LLM most helpful.)
Not related to the article, but I've seen this thought before and I think its wrong.
This isn't what good academic instructions gets you. Instead, they provide a systematic approach to learning foundational/core formalisms which let you recognize other problems as being of the same kind.
An academic background should let the person reason from a place of pre-explored essential complexity, instead of first having to rediscover & deconstruct the accidental complexity.
Building scar tissue about why things are a certain way is practical experience for (non)academics alike.
It was a massive disadvantage for them. They could carefully recreate the exact same thing over and over for new products that were similar to the previous version, but it was ALL cargo culted so they were terrified of any change, because they had no idea why a PCB was built in a certain way or what it meant to alter some aspect of a circuit board. So they were extremely, extremely resistant to any sort of change whatsoever.
And I as a young hardware engineer would get laughed at for saying things like "Do we have any fine copper wire? I need to make my own inductor for this test" because they didn't understand that an inductor is just coiled wire. Our board designer didn't understand why vias would be placed in a ground pad to link it thermally with the ground plane on a different layer, and laughed at me when I said we needed to "move heat around". He put a single via in the center of a huge ground pad. I asked him to put a grid of vias, so he humored me while having zero idea what the vias were for, or that having many vias linking two thermal planes would transfer more heat than just a single lonely via in a big pad.
Shit like that.
So I agree with you, the theory learned in academia plus the pedagogy is hugely useful and lets someone skip over decades of blind struggle.
All kinds are needed for different types of work, and it's not discussed enough that LLMs make some developer archetypes more effective and others more exhausted. Great article.
Turning to the substance of the article: why do people feel the need to run this fast? I have certainly experimented with letting coding agents run amok. The first few times you try it, it feels like a superpower. Then you start examining the icky choices they made in a codebase that is now a dense forest. Then you have to expend a bunch of effort beating it back into submission. Or I guess you can YOLO and throw more AI at it, but then I agree with the person quoted saying "at that point, what am I still doing here?" This is not a satisfying or sustainable way to build, and there really is no reason other than hype and FOMO to do it.
Because if they don't they feel like they will be replaced by someone who will
Basically a bad relation to labor and sustainable lifelong work.
But of course the AI guys are preying on this anxiety in order to dominate. They are all over HN, either personally or with their bots. Which is why HN is no longer a place that you could go to get mainly unbiased anecdotes and experience. That is still available but it is being drowned out by FUD because the average HN user is now the mark.
My standard reply to claims like this is: post a pre-2022 link with an LLM style that matches your claims.
Usually people claim "LLMs sound like the way they do because that's how people write". Your claim is only a little different: "LLMs sound like the way they do because that's how corporate writes".
You may be correct, but I'd still like to see a pre-2022 link confirming this.
- Use a descriptive triad of "reviewing, directing, and course" (it incorrectly misunderstood 'course correcting'). That's not common in writing but humans do do it occasionally.
- Using the word 'thoughtful'. I don't understand that as evidence of AI.
- Using the words 'Book Apart' together, which would be a clear AI signal if it wasn't the name of a publisher of short books, and being used in that context in the article.
I don't think you should put much stock in the output of pangram.com.
The classifier itself has a very low rate of false positives: https://bfi.uchicago.edu/wp-content/uploads/2025/09/BFI_WP_2...
Dashline - present
Yes, it's AI-written
There are certain writing styles, which even if you wrote them all yourself, most people will now attribute to AI. The all-too-common em-dash, yes sure. Guess what, it's a thing that was actually taught as "the thing to use if you write properly". So guess what lots of folks consciously put into their writing to sound more professional even before AI. Bingo!
Similarly CVs. A lot of the stuff that lots of us complain about post-AI was "good practice to do" pre-AI. But most people didn't bother. Couldn't be bothered. Now that AI was trained on it and people ask their AIs to write CVs, it's all over the place.
A cover letter that actually picks up on the actual job description posted and connects it up to your CV? That used to be hard work and most people didn't bother. It made you stand out. Now it "reeks of AI" :shrug:
And try to substitute them, you may; but the bell might still ring.
(Yeah it stinks we have to adapt to avoid sounding like a model, especially for the best writers who were probably ripped off a lot more than the rest of us.)
Firefox doesn't seem to discriminate between em-dashes and hyphens using ctrl-F so I'm not sure about those.
Having said that the tone REEKS of AI generation, so meh.
Just say you don't mind AI writing - make that argument. Don't make this nonsensical, defeatist, "if it's common, stop criticizing it" argument.
Is it likely for AI written content of the HN front page to exceed 90%? Many would seek out the final 10%.
And wouldn’t you expect human and generated writing to be indistinguishable someday anyway in which case complaints should significantly drop off?
Don't worry about it; notice how people are still talking to uninteresting whiners like yourself :-)
(Did you not notice you were whining?)
I keep wondering what I’m missing in the AI enthusiasm, and maybe this is a big part of it? Writing code has never felt like the hard part to me.
In my 20s, I was excited about using a computer. AIM trained fast touch typing. I learned modal editing with vim. I learned all the common Unix commands to transform text files and filesystems in myriad ways. I learned to script and to create my own productivity keyboard shortcuts. I ran Gentoo Linux at home. Then I started my software career.
There, I learned git inside and out. I learned that IDEs all have vim keybindings, so you can have seamless language integration alongside speed-of-thought text manipulation. I became an expert in Java.
When I’m programming, if I know what I’m building, I’m moving at maximum speed. I’m not thinking about typing or syntax or using my mouse much. I’m learning the shape of the code I’m changing. I’m figuring out the right changes to make for myself and future work. When I pause, I’m pausing to think. Sometimes I realize the entire approach won’t work, but I learned something valuable, and I restart the work in a better direction with fewer pauses.
The code was never the bottleneck. Coding never feels like the hard part. When it does feel hard, I build a better abstraction or use IDE refactoring tools or craft a gnarly Unix pipeline with one or more sed invocations.
But this AI excitement is making me think perhaps this combination of skills is unusual. Maybe a lot of devs haven’t been exposed to great tooling or mastered the tools. If I put myself in those shoes, then coding seems much harder, and AI coding seems like a bigger win.
If I were in my 20s today, I might not spend so much time mastering the skills I take for granted. In that context, AI would feel like a magic productivity boost. For my part, though, I got excited about software engineering when I truly grasped that none of it was magic.
(only ~5 paragraphs left now so y’all might as well finish it :) )
Thanks, lots of hackers can use the reminder.
Sadly, this is a question for his boss, not him. It’s not existential. It’s economical.
I just want to comment on this. Maybe im part of some spectrum, but building stuff with AI in that "solitary mode" ive found it really enjoyable. It takes me too the times 30 years ago when I was a 14 year old writing my own games on Basic and C++ with Allegro.
I had nobody but tutorials and books. And the hky of building, compiling and seeing the result for myself was very enticing.
Maybe it's because I found peers my age uninteresting. I lived in a small Mexican town where 14 year olds where thinking in bullying someone, and unfortunately that someone was usually me.
If someone remembers The Hackers Manifesto (The Conscience of a Hacker) I feel that again after so many years, with AI. Edit: particularly this part:
---
I made a discovery today. I found a computer. Wait a second, this is cool. It does what I want it to. If it makes a mistake, it's because I screwed it up. Not because it doesn't like me...
Or feels threatened by me...
Or thinks I'm a smart ass...
Or doesn't like teaching and shouldn't be here...
> "If it makes a mistake, it's because I screwed it up. "
Is that really true though with an LLM? I don't think so.
I still prefer it to the responsive pages where stuff moves unpredictably and annoyingly. Before you never had that feeling that the webpage was fighting you.
I sometimes wonder if there is an equivalent loss for this new AI world and one that I've noticed is a kind of sameness that is slowly spreading across the internet.
It's so funny and somber to see programmers having an existential crisis when they get a glimpse of what work is like for business managers, the demographics many programmers detest.
I am also guilty of holding the business majors in contempt back in college, and now here I am, doing what they are doing in office in a much more indifferent and unenjoyable manner. At least I don't get into trouble with HR from calling my agents a stupid fuck (yet).
> That loss is real and it's worth naming
I think I will not heed the first sentence and bear with this. What motivates people to do this? What do they get out of prompting Claude for some vapid "thought piece" and spamming it on the internet?
Yep classic Claude-ism.
The fact that this article was likely AI generated is the real load-bearing factor in this discussion. Or, as previous versions of Claude would say; it cuts through the heart of the issue.
A lot of the time, what I want to build, doesn't have a succinct English sentence to describe it. If I describe the user requirement I just get a Fisher-Price toy thing that kind of ignores most of the adjectives and adverbs in my requirement. So I'd have to prompt with a big list of specs and algorithms for the specific thing I want. Then what's the point?
Well I do have an idea for some awesome software, I know exactly what the user experience should be, but the lemmings are producing useless software that resembles my idea in the way a Fisher-Price phone resembles a real phone. With frontier models, now far less buggy useless software following code conventions perfectly.
That sounds like programming with extra steps.
Here's my No-AI workflow: I read the requirements and devise pretty much instantly have a solution. I Check the web/manuals/docs/source code for missing information so I can refine the solution from a hunch to an implementation plan. This can be pretty fast or can be the slowest part. I start coding, building a small subset that work and iteratively adding on top, feeling the design as I go, refactoring if necessary. Then after testing, I send it to review.
The "finding information" part is the most important one as accuracy is paramount. And for most AI workflows, it seems that's very much an afterthought.
The "coding" part is the relaxing one, except for a few moments where some nuggets of information are lies or misleading. Again, there's no practice to catch those in AI workflows.
If you have a good testing methodology in place, the last part can be fast tracked, where you mostly scanning for bad practices and modifications to important areas. Again in AI workflows, you see that either they rely on preexisting test suites (the big rewrites), or mostly trust the generated suite with no evidence that it's actually suitable.
The questions I have are: How do you ensure the accuracy of the software's model of the domain? And What do you do to retain the knowledge of that model (as in you have a good intuition of the current behavior of the software or at least can easily locate the code responsible)?
One could hope that the author is making a meta-point.
Perhaps on the way to UBI and the end of labor, we could get a 32 and 24h work wweek with lots more vacation, my hope at least
It's a really smart future that the wealthy business owners and investors are building for us.
As a broad historical trend? Maybe not
But fewer people working, right now? Absolutely
This isn't a useful definition of working less in the thread context and is not the kind of working less that I meant.
If it helps, imagine that I had asked for "when increased productivity translated to workers personally reaping the benefits of the increased productivity by being able to thrive while doing less instead of either being laid off or just being expected to do more".
> with my colleague Douwe
Wait, meltano Douwe? Small world. Glad to see you're doing well. I always liked meltano.
> In an era when anyone can produce reasonable-looking UI
Identical looking slop? Every Claude-based vibe coded app looks identical.
> The fear of skill rot is legitimate. And the fear that if you don't go fast enough you'll be left behind is — while often overstated — not entirely unfounded.
You know what, that's OK. I just hit "OK" on LLM Scala code I _actually_ think is awful. It works. It's probably faster than the "pure" code I'd write by hand. The code I would write - as a FP and Scala/Elm/Haskell/... enjoyer - would actually be maintainable for humans, but LLMs struggle with it. But LLMs writing code for LLMs? Sure, have at it. Objectively lower barrier of entry.
> So if you're feeling overwhelmed, destabilized, simultaneously more productive and less happy, know that you're not alone.
But yes, I am indeed simultaneously more productive and less happy.
https://skaldmaps.com, my little side project, was only possible _because_ I was able to feed my real world knowledge about real estate, combined with GIS and SWE knowledge into various torment nexus... pardon me, LLM prompts.
Since I don't have the _time_ to write boilerplate react code (it's pepper and tomato season in Georgia, which _actually_ brings me joy), telling Claude/Codex/... how to write dbt models saves me time and I objectively get a lot more done, but it's not fun.
I guess that's also why I still enjoy blogging. You can't use LLMs for blogs without people noticing immediately. Shameless plug: https://chollinger.com/blog/
Enjoy my entirely human typos, since that's clearly rare these days.
I don't think it's common for any compsci programs to (competently at least) teach architecture and code quality.
>The honest truth is that in the last few months, there have been days when I have spent close to two full days writing a plan for an LLM to execute: obsessively clarifying, specifying, re-specifying, only to have it still do something inexplicably stupid.
It's because LLMs are actually taking us back in time to the pre-agile days where there was a career path (architect) that involved almost nothing but painstaking spec authoring and endless meetings to review and course correct the work of the engineers whose job was to implement what you designed as closely as possible. I have to emphasize that this was a different career path than what we think of as a senior engineer today. Not everyone likes this.
If it weren't claudeslop, it would still have to be marketing corposlop.
What used to tire me: being forced to have a sharp eye for syntax errors when programming, or simply the effort of all the typing and navigating through source files. Trying to visualize details of the codebase I was changing, while at the same time keeping a high level picture in my head of the feature I was changing.
With AI, I can focus on the high level picture. I can focus on the steps to get there and the steps to verify that it works. I don't have to focus on syntax anymore and there is much less need to visualize large parts of my code base. With AI, work is still tiring but much less, and in a different way.
In return, there is not much of mastery anymore. Being a craftsman is a deeply human desire that AI is destroying, not sure if this is a fun future to look forward to.
> Being a craftsman is a deeply human desire that AI is destroying, not sure if this is a fun future to look forward to.
AI is giving me back the feeling I had when I first learned to program, when I was 14. At 14, I suddenly had a tool in my hands that was like an extension of my imagination. I could create tools, games and what not with it, this is what I loved. AI is that same tool on steroids. If what you like is creating things, AI lets you do it at 10 times the speed.