> Here's a term for what I think is happening: the human reward function problem. In machine learning, a reward function tells an agent what good looks like. Writing code by hand was never easy, but it was full of small rewards. Solving a problem in your head. Understanding a gnarly bit of logic. Watching the code compile. The feeling of control. LLM-assisted programming has automated much of the work that generated those dopamine hits and replaced it with the cognitive load of review and supervision. The satisfying part shrank. The exhausting part grew. And there are no new rewards to fill the gap.
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.
You put it in a good way, I have been saying this for my partner that I don't fear my job is at risk. I fear I am going to hate my job soon.
I am coping a bit by still doing stuff by hand, especially stuff where prompting the LLM doesn't save that much time. And what I call "adding good taste" to LLM output where I move things around to structure them in a more human-understandable way (by hand usually).
I think it all depends on your personal driver: personally I rather see a product I built in whatever way used by ever growing number of people because they find it useful. It means that the time I spent working on that helped other people solving a problem (hopefully).
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.
I don't even want to put 'my' code or apps out into the wild anymore. I've built a a few things I think are useful and I'm using myself but I'm afraid it'll just get called slop or my only users will be bots. What's the point. So I don't get the joy out of sharing it nor the joy of the achievement. But I've widdled down what I thought was an endless backlog of features to nearly zero, I guess that's something.
If it's code built by an LLM it's almost inherently uninteresting in that 'anyone' can also generate the same slop. Beyond the initial novelty the 'achievement' really doesn't stretch that far.
Your slop, my slop, their slop it's all 'slop' and no one can really care about slop. The novelty is wearing thin fast
Github's weekly Top Trending repos list is depressing. Slop on top of slop, many doing the exact same thing as each other with so much low-quality content it's challenging to read through and compare similar repos.
You don't understand what the OP said, your brain can get a intrinsic reward from seeing users use your LLM work. But LLM remove all the little intrinsic rewards from coding elegant systems to get to the point where you see users using your work.
It is all about the destination now where it used to be about the journey and the destination.
I wrote some software nearly 20 years ago, haven't touched it for over a decade.
The code was terrible, but I don't care, it did the job, and people still use it despite a whole team of people who have tried to replace it with "elegant" code in frameworks which have come and gone.
The reason people still use it is that it solves their needs, not the programmer's needs.
The goal was to make the user's life better, not to make a work of art
Setting up a loop so the AI can test its output, so you can have it go off on its own, gives me a dopamine hit. The more rube Goldberg-ian the hit, the bigger the dopamine hit. I setup a network->usb-c keyboard dongle, and a fingerbot so codex could remote control a laptop, plus a webcam so it could see what the laptop was doing, so that I could get hibernate working on that specific hardware with that Linux kernel.
Maybe it's different between professional and personal projects, but I get that feeling more often as features are not only easier to create, but also come out more polished and consistent. I'm able to focus on a single project for a month and have something pretty good by the end. Doing rewrites to clean up and reorganize has never been easier, so I get to see and feel more of the design space in action. The can be pretty damn frustrating at times, half of which is me/context, the other their nature
When my wife has a thing she says she needs to do and I can help, I now ask “do you want this done or do you want to do it?”. I think this is a similar kind of split.
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)
We're just getting used to the invention of the washing machine. All clothes are equally cleansed on average, with good enough results even if afterwards some particular pieces need a bit of extra care, while before we had to clean them all one by one and paying attention to minutia and details on each piece's needs. Nowadays you just control a couple buttons and hope for the best.
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.
> Better to find joy in other parts of the process!
I recommend the joy of helping the customer get what they truly want. Spend more time on client calls and intercept additional hot potatoes now that we have extra free time to work with.
The technology is a blank canvas. These LLMs are like 600DPI color laser printers. The customer cannot tell the difference between hand painted and LLM generated at even a short distance. Once you get your head out of the worry that not hand painting everything is somehow an abdication of your professional capacity, you may find this whole thing goes a lot better. Try to think of it more like a heavy equipment operator climbing into the cab of a Caterpillar D9. You could do the job by hand, but the customer would probably get upset with how long it takes. Why not just finish the damn thing? Fire the infernal machine up for a few minutes and then move onto the next task.
You may find that by using the big scary machines that you get to engage with far more interesting technology problems than if you had insisted on hand coding. The only real difference is that you get to enjoy the problems from the comfort of an air conditioned cabin rather than a hot, muddy field.
> a Berkeley Haas study which describes how AI usage increases the intensity of work
The marketing around this 'study' has been impressive. They published the HBR article [0] and other promotional material [1] over 5 months ago, but as far as I can tell, the actual study itself (even a preprint version) still isn't available anywhere. Hard to evaluate how believable the results are without being able to actually see the details of how the study was done. For now, all we know is that it's based on ~40 qualitative interviews from a single company in a single industry.
unlike the op, I've been having a wonderful time using claude, both at work and for my own personal projects, so I will share what has worked for me, just in case it resonates with anyone else.
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.
Agree with this. I have learned to interact with Claude the same way. Detailed hashing it out at the beginning, then finally execute, even maybe with your scaffolding at the beginning to guide the process. I tried writing this process down in a 'zen of Claude' as a reminder https://github.com/ctomkow/claude/blob/main/README.md I've started being able refactor legacy code into a new architecture with great success. Work I've been putting off due to the grind of the work.
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.
Sounds very reasonable. It is similar to what I do. I have a chat completely separate from my editor, where I only paste necessary pieces of code, that should be considered, add some constraints or ideas to discuss and once I am satisfied, I copy back code into my editor, where I might rename things and might further improve things. Other times, I just code it myself, when it is already clear to me or seems enjoyable. I think for me it is important to engage in doing things oneself, here and there, and make the architectural decisions, to actually feel a connection to a project and develop an in-depth understanding.
Unfortunately the incremental approach doesn't help when it comes to the review step by another user, they've still gotta take it as a lump and apply fresh eyes on it.
not if you break your work into a stack of PRs, which is the standard practice for my team at work. you just keep adding PRs to the top of the stack while the reviewer proceeds from the bottom. if something changes you propagate the change up the stack, which LLMs are also pretty good at doing.
I'm all in favor of stacking PR's to break reviews into chunks, but if they're being used to explain the reasoning or correctness of the final code to a reviewer, then that's a process-smell. It's like "teaching to the test", a shortcut that will hurt in the long run.
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.
i'm not sure i understand your objection. here's a concrete example of what i'm talking about:say i want to add a new feature to my code analyser, exception-aware code analysis. it ends up being 2000 lines worth of diffs, touching a bunch of files, and definitely too much to review in one go. so what i do is, first i write a doc file describing the feature, to show what i'm working towards. then i write a small commit, "add a new `exception_handlers` member to the context struct, and a small class containing its datatype", and upload it for review. why is this new member needed? see the plan doc pointed to by the commit message! now i needn't wait for it to be reviewed, i can stack another commit on top of it, "populate the exception_handlers info by walking the AST". it depends on the exception_handlers member being in the struct, but, crucially, it doesn't depend on that code being merged in, because it's there in the stack below this commit. i can keep adding things like "inherit exception_handlers when analysing function calls", "validate that all explicitly raised exceptions are caught by an exception handler in the current scope", etc - there are a lot of moving parts to analyse exception handling, but each commit is fairly small, does one precise thing, and is therefore relatively easy to review.
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've also been having a wonderful time with the other approach, churning out reams of code for a mobile app.
It is taxing, the context switching is not easy. It takes effort to keep up with 3-5 conversations, remember what you deployed to the device, what is to be tested, and what feedback needs to be provided.
At the end of the day I am proud of the results, and I feel like I achieved something.
Contrary to popular belief it is still often hard work to vibecode.
Lots of QA work, UX decisions, debugging and steering efforts, as well as weighing architectural concerns and what should or should not be refactored.
While the code basically writes itself, the app still does not create itself on its own. Not to mention business and market research, as well as App Store Optimization.
We've started calling it "Human on the hook" instead of human in the loop in work.
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
That's perfect, I will use that term from now on whenever somebody proposes any kind of automation and will see how often somebody will try to correct me.
> Yes the code (sorta) writes itself, but the human reviewing, directing, and course-correcting feels worse, not better.
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.
Amusingly, when I know my peer is just going to point his AI at my feedback, I write for their AI, not for them. I'm much more curt. Maybe not so amusing but I don't feel bad about dumping a laundry list of fixes for them.
yes- as a technical lead that has gone back and forth with engineers on PRs who kept saying "it's good enough", it's nice to be able to say "just do it the right way" and not get pushback.
I’m finding you can still get into flow state, but you need to find that sweet spot where the context switching is pushing you right up to your limits but not too far.
If one of your agents is working with you on something which requires deep focus, that naturally requires more of your mental resources. So it’s all a dynamic scheduling problem. It exercises your ability to recall contexts very rapidly and I’m enjoying growing that capacity.
> I felt that one in my bones. I was up until nearly 2am recently, prompting, because I was so close to getting a plan right. Or so I thought. [...] And it's addictive in a way that makes the isolation worse.
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
I remember when I was just learning how to code and making some web app, I had to do a lot more blind guessing and running. "Ok let me try this... Will that work now?" I remember staying up really late, feeling stuck to the computer in that slot machine mode.
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.)
It's a trip back to a guesswork stage because most of the training data looks like the process you described your beginnings have been like.
Now you know how to do things first shot. When you write the code, your inner voice reminds you ahead of time to do it like this and that. And that "this and that" is what your prompt needs to have to avoid the trip to guesswork. Working with agents is like working with juniors. If you don't give them the direction and explain how, they'll be as lost as the LLM. The difference is, your brain finds guardrails as you solve the problem, the LLM doesn't have this context, you have to give it upfront. Like, you know, a good manager would.
Yes, and now they don't have to agree, they ask an LLM, and we get half baked plans and quarterly goals and are left to figure it out ourselves. So the stakeholders have some ideas, some half assed designs get put together by an LLM, stories are generated by an LLM, technical details are filled in by an LLM, the implementation and code review are LLM. I can already notice the lack of critical thinking and scrutiny in the whole process, we're offloading all thinking and just creating these artifacts, designs, documentation, code, to what purpose I'm not sure. I'm having trouble even keeping up with everything going on. Of course, plans are more likely to change at any minute and we'll just rewrite everything on a whim.
> 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.
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.
While I appreciate and agree with the key points of the post, Claude's writing style fingerprints are all over it and I guess it's even more exhausting to read someone's AI written article.
The writing style, if not AI, is at least a bit tryhard.
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.
This attitude gets people to willingly engage in abusive crunch practices such as in the games industry. I think the people who are like this are the ones who later talk about crunch like it was good in some way or necessary.
Basically a bad relation to labor and sustainable lifelong work.
This happens all the time, even before LLMs. And it happens even when there is no threat. A lot of the time the race to the bottom is driven by anxious people running from imaginary threats. Which is why its often useful to have a person in a group who tells people not to panic (this is often an older person).
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.
> I don't think it is AI, but I bet it has been through editing/review to match a corporate style. LLMs were trained on this.
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.
If you switch on the 'Supporting Evidence' on that site, it seems to be basing it's opinion on three things:
- 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.
Pangram's "Supporting Evidence" feature is misleading and you should ignore it. It's entirely separate from the classifier that determines whether text is AI; it just takes text that's already been classified as AI and looks for some hardcoded AI tells in it. I kind of wish they'd get rid of it, but nontechnical users really like it.
I think it was written mostly by AI, but with a lot more human intervention than the average AI written article, so it doesn't bother me as much as usual.
This very well may be AI written. Then again, the stuff our PMs output, all pre-AI, now would all qualify as "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:
I’m sure—pretty sure—we can use em-dashes w/o setting off the slop bells.
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.)
I have started honing a method of trolling where i intentionally write like a crappy AI, but, do it by hand, just to prank my anti-AI friends. Gotta get my kicks somewhere. It's not just fun-- it's annoying. :-)
"It's not" only has two matches; the third is "It's noticable". The other two are a whole paragraph dedicated to "it's not X, it's Y" which is a little more than you'd normally expect.
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.
> The animal is aging. Not surprising; I knew it would happen eventually, but I didn't make any provisions to deal with that eventuality. Somehow the reality crept up on me. And now it must be dealt with, day after day.
(only ~5 paragraphs left now so y’all might as well finish it :) )
> I came to the formalisms of software engineering through painful experience rather than academic instruction. If anything, that made me take those principles more seriously once I understood them.
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.
I worked for years at a manfuacturing facility where the engineers were men who only had a high school education and slowly (from the 80s through to the late 2010s) had been promoted up to doing engineering, but, with ZERO academic or theoretical background.
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.
>It's also, frankly, quite lonely. Programming with an LLM is an intensely solitary activity.
> You and the machine, going back and forth, refining and prompting and reviewing.
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...
Ya my memories are similar: ~12 years old building BBS's late into the night, then after college first startup, programming from midnight to 5am "in the flow" - nobody around or online. Just me and the problem at hand.
Being able to ask an AI an embarassing newbie question that I should really know but I just need someone to remind me / confirm my half-forgotten knowledge...
There are different kinds of developer. Some will find their joy through building fast, they tend to love LLMs. Some love the art of writing code; they don't tend to love LLMs. And there are others too. Those that enjoy fully understanding a piece of code can find the process deeply draining, while those that look at things from a system level find the LLM frees them from the details.
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.
Pinch to zoom on an early iphone navigating those fixed-width sites worked surprisingly well.
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.
> He described waking up to thirty PRs every morning, each one pulled overnight by someone's AI, and needing to make snap judgment calls on every single one. The temptation to delegate the review itself to an AI was enormous. But, as he put it: "at that point, what am I still doing here?".
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).
Business managers get to delegate their work, make big money, and just spend their time at work gossiping before leaving at lunch to go play golf or work on a second job as a consultant, or on the board of another company, or creating a new startup. Pretty good deal imo
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?
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?
I've not had that problem, but I have 35 years of programming experience, so I can describe exactly what I want. Maybe that's the difference. It doesn't have to be a single sentence, I write a whole paragraph or even pseudocode most of it and tell it to use the pseudocode as comments for the code it will produce. It'll give me a plan and I'll refine the plan until it seems to be what I want. Then we'll get it to start writing and I'll give it feedback and keep it on track. If it tends to overthink a problem, I'll interrupt it and have it talk over the issue, until it gets a clear understanding of what I want. You have to treat it like a coworker more than just a code monkey.
The dream is "I have an idea for some awesome software, I will set an army of lemmings out to do all the tough work of figuring out how it actually works".
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.
> It doesn't have to be a single sentence, I write a whole paragraph or even pseudocode most of it and tell it to use the pseudocode as comments for the code it will produce. It'll give me a plan and I'll refine the plan until it seems to be what I want. Then we'll get it to start writing and I'll give it feedback and keep it on track. If it tends to overthink a problem, I'll interrupt it and have it talk over the issue, until it gets a clear understanding of what I want.
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)?
The 2 a.m. prompting bogs down to FOMO of not being fast enough with ideas, and that some other people will implement it faster and one won't make the share of money they envisioned.
I certainly don't have this problem. Even with LLM assistance, my hobby projects experience slow, steady growth, but it's done on my terms. I code when I have a mood, with or without LLM.
Recently I bought a Claude subscription only to use it for 3 days to speed up some coding. Then I cancelled it and stopped. My creative days ended, and I got to other stuff. I know I'll lose 27 days of possibilities, but I couldn't care less. If I'm in the mood to code with AI, I'll buy another month, maybe only for another couple of days.
People, stop accelerating at full throttle, find some real joy in life. It's not about the amount of lines, features or products shipped, let alone about amount of dollars you brag about, if they need this much effort and sacrifice.
> Every single worker that has been laid off due to "increased AI productivity" is working less
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".
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.
>When you've earned your opinions about architecture and code quality the hard way, they feel less like textbook rules and more like scar tissue.
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.
The tiredness isn't from being in the loop. It's from what the loop hands you. Reading a wall of an agent's prose to check if it understood a screen is exhausting. The same check as a marked element with coordinates takes a second.
It's not a human-attention problem, it's format problem. Models emit prose because it's cheap to generate, not cheap to review.
I feel the opposite, AI is making me less tired at the end of a working day even though I get much more done.
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.
You were probably just inexperienced in coding. AI has completely bridged that gap. Someone with a 1000 hours coding experience has almost the same speed as someone with 10 hours of experience who gets stuck on syntax like you said.
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.
Lol, I have 42 years of experience in coding, of which 29 paid.
I learned to program when I was 14 years old, studied computer science and went to work in IT. I'm 56 years old now and working as a tech lead.
> 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.
> Here's a term for what I think is happening: the human reward function problem. In machine learning, a reward function tells an agent what good looks like. Writing code by hand was never easy, but it was full of small rewards. Solving a problem in your head. Understanding a gnarly bit of logic. Watching the code compile. The feeling of control. LLM-assisted programming has automated much of the work that generated those dopamine hits and replaced it with the cognitive load of review and supervision. The satisfying part shrank. The exhausting part grew. And there are no new rewards to fill the gap.
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.
You put it in a good way, I have been saying this for my partner that I don't fear my job is at risk. I fear I am going to hate my job soon.
I am coping a bit by still doing stuff by hand, especially stuff where prompting the LLM doesn't save that much time. And what I call "adding good taste" to LLM output where I move things around to structure them in a more human-understandable way (by hand usually).
I think it all depends on your personal driver: personally I rather see a product I built in whatever way used by ever growing number of people because they find it useful. It means that the time I spent working on that helped other people solving a problem (hopefully).
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 seems to be a big fight between the I am interested in the end result and I am interested in the process.
Some people think the same regarding art, they dont see art in the process only in the end result.
I believe no one is right, but also no one is wrong.
I don't even want to put 'my' code or apps out into the wild anymore. I've built a a few things I think are useful and I'm using myself but I'm afraid it'll just get called slop or my only users will be bots. What's the point. So I don't get the joy out of sharing it nor the joy of the achievement. But I've widdled down what I thought was an endless backlog of features to nearly zero, I guess that's something.
If it's code built by an LLM it's almost inherently uninteresting in that 'anyone' can also generate the same slop. Beyond the initial novelty the 'achievement' really doesn't stretch that far.
Your slop, my slop, their slop it's all 'slop' and no one can really care about slop. The novelty is wearing thin fast
Github's weekly Top Trending repos list is depressing. Slop on top of slop, many doing the exact same thing as each other with so much low-quality content it's challenging to read through and compare similar repos.
You don't understand what the OP said, your brain can get a intrinsic reward from seeing users use your LLM work. But LLM remove all the little intrinsic rewards from coding elegant systems to get to the point where you see users using your work.
It is all about the destination now where it used to be about the journey and the destination.
I wrote some software nearly 20 years ago, haven't touched it for over a decade.
The code was terrible, but I don't care, it did the job, and people still use it despite a whole team of people who have tried to replace it with "elegant" code in frameworks which have come and gone.
The reason people still use it is that it solves their needs, not the programmer's needs.
The goal was to make the user's life better, not to make a work of art
I think you don't understand that they understand. For them it's the destination that matters. Their journey is different.
Setting up a loop so the AI can test its output, so you can have it go off on its own, gives me a dopamine hit. The more rube Goldberg-ian the hit, the bigger the dopamine hit. I setup a network->usb-c keyboard dongle, and a fingerbot so codex could remote control a laptop, plus a webcam so it could see what the laptop was doing, so that I could get hibernate working on that specific hardware with that Linux kernel.
Maybe it's different between professional and personal projects, but I get that feeling more often as features are not only easier to create, but also come out more polished and consistent. I'm able to focus on a single project for a month and have something pretty good by the end. Doing rewrites to clean up and reorganize has never been easier, so I get to see and feel more of the design space in action. The can be pretty damn frustrating at times, half of which is me/context, the other their nature
> but I get that feeling more often as features are not only easier to create, but also come out more polished and consistent.
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.
When my wife has a thing she says she needs to do and I can help, I now ask “do you want this done or do you want to do it?”. I think this is a similar kind of split.
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)
We're just getting used to the invention of the washing machine. All clothes are equally cleansed on average, with good enough results even if afterwards some particular pieces need a bit of extra care, while before we had to clean them all one by one and paying attention to minutia and details on each piece's needs. Nowadays you just control a couple buttons and hope for the best.
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.
> Better to find joy in other parts of the process!
I recommend the joy of helping the customer get what they truly want. Spend more time on client calls and intercept additional hot potatoes now that we have extra free time to work with.
The technology is a blank canvas. These LLMs are like 600DPI color laser printers. The customer cannot tell the difference between hand painted and LLM generated at even a short distance. Once you get your head out of the worry that not hand painting everything is somehow an abdication of your professional capacity, you may find this whole thing goes a lot better. Try to think of it more like a heavy equipment operator climbing into the cab of a Caterpillar D9. You could do the job by hand, but the customer would probably get upset with how long it takes. Why not just finish the damn thing? Fire the infernal machine up for a few minutes and then move onto the next task.
You may find that by using the big scary machines that you get to engage with far more interesting technology problems than if you had insisted on hand coding. The only real difference is that you get to enjoy the problems from the comfort of an air conditioned cabin rather than a hot, muddy field.
That's such a naive take, the joy of helping the customer ha! That's a situation your employer sets up for you!
Try reading your sentence above and swapping in 'EMPLOYEE':
'These LLMs are like EMPLOYEES. The customer cannot tell the difference between EMPLOYEE painted and LLM generated at even a short distance. '
I used to get overjoyed and would tell my partner how amazing programmer I am every time I built something that felt difficult at the beginning.
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.
It is all about the destination now where it used to be about the journey and the destination.
> a Berkeley Haas study which describes how AI usage increases the intensity of work
The marketing around this 'study' has been impressive. They published the HBR article [0] and other promotional material [1] over 5 months ago, but as far as I can tell, the actual study itself (even a preprint version) still isn't available anywhere. Hard to evaluate how believable the results are without being able to actually see the details of how the study was done. For now, all we know is that it's based on ~40 qualitative interviews from a single company in a single industry.
[0] https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies...
[1] https://newsroom.haas.berkeley.edu/ai-promised-to-free-up-wo...
Another good read about automation in general is [0] Ironies of Automation. I believe the same principles can be applied to AI automation.
[0] https://static1.squarespace.com/static/644321e78cd2dd37613af...
unlike the op, I've been having a wonderful time using claude, both at work and for my own personal projects, so I will share what has worked for me, just in case it resonates with anyone else.
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.
Agree with this. I have learned to interact with Claude the same way. Detailed hashing it out at the beginning, then finally execute, even maybe with your scaffolding at the beginning to guide the process. I tried writing this process down in a 'zen of Claude' as a reminder https://github.com/ctomkow/claude/blob/main/README.md I've started being able refactor legacy code into a new architecture with great success. Work I've been putting off due to the grind of the work.
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.
Sounds very reasonable. It is similar to what I do. I have a chat completely separate from my editor, where I only paste necessary pieces of code, that should be considered, add some constraints or ideas to discuss and once I am satisfied, I copy back code into my editor, where I might rename things and might further improve things. Other times, I just code it myself, when it is already clear to me or seems enjoyable. I think for me it is important to engage in doing things oneself, here and there, and make the architectural decisions, to actually feel a connection to a project and develop an in-depth understanding.
I've found that I can go back and forth between two workstreams (at most) but beyond that my brain gets fried from the context switching.
I agree I think Vibe coding (even with myraid loops) is more burnouty than using it like an assistant and being closer to the output.
Unfortunately the incremental approach doesn't help when it comes to the review step by another user, they've still gotta take it as a lump and apply fresh eyes on it.
not if you break your work into a stack of PRs, which is the standard practice for my team at work. you just keep adding PRs to the top of the stack while the reviewer proceeds from the bottom. if something changes you propagate the change up the stack, which LLMs are also pretty good at doing.
I'm all in favor of stacking PR's to break reviews into chunks, but if they're being used to explain the reasoning or correctness of the final code to a reviewer, then that's a process-smell. It's like "teaching to the test", a shortcut that will hurt in the long run.
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.
i'm not sure i understand your objection. here's a concrete example of what i'm talking about:say i want to add a new feature to my code analyser, exception-aware code analysis. it ends up being 2000 lines worth of diffs, touching a bunch of files, and definitely too much to review in one go. so what i do is, first i write a doc file describing the feature, to show what i'm working towards. then i write a small commit, "add a new `exception_handlers` member to the context struct, and a small class containing its datatype", and upload it for review. why is this new member needed? see the plan doc pointed to by the commit message! now i needn't wait for it to be reviewed, i can stack another commit on top of it, "populate the exception_handlers info by walking the AST". it depends on the exception_handlers member being in the struct, but, crucially, it doesn't depend on that code being merged in, because it's there in the stack below this commit. i can keep adding things like "inherit exception_handlers when analysing function calls", "validate that all explicitly raised exceptions are caught by an exception handler in the current scope", etc - there are a lot of moving parts to analyse exception handling, but each commit is fairly small, does one precise thing, and is therefore relatively easy to review.
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've also been having a wonderful time with the other approach, churning out reams of code for a mobile app.
It is taxing, the context switching is not easy. It takes effort to keep up with 3-5 conversations, remember what you deployed to the device, what is to be tested, and what feedback needs to be provided.
At the end of the day I am proud of the results, and I feel like I achieved something.
Contrary to popular belief it is still often hard work to vibecode.
Lots of QA work, UX decisions, debugging and steering efforts, as well as weighing architectural concerns and what should or should not be refactored.
While the code basically writes itself, the app still does not create itself on its own. Not to mention business and market research, as well as App Store Optimization.
We've started calling it "Human on the hook" instead of human in the loop in work.
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
That's perfect, I will use that term from now on whenever somebody proposes any kind of automation and will see how often somebody will try to correct me.
Employee Role: Blameable Component.
And when was it not...
> Yes the code (sorta) writes itself, but the human reviewing, directing, and course-correcting feels worse, not better.
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.
Amusingly, when I know my peer is just going to point his AI at my feedback, I write for their AI, not for them. I'm much more curt. Maybe not so amusing but I don't feel bad about dumping a laundry list of fixes for them.
yes- as a technical lead that has gone back and forth with engineers on PRs who kept saying "it's good enough", it's nice to be able to say "just do it the right way" and not get pushback.
I’m finding you can still get into flow state, but you need to find that sweet spot where the context switching is pushing you right up to your limits but not too far.
If one of your agents is working with you on something which requires deep focus, that naturally requires more of your mental resources. So it’s all a dynamic scheduling problem. It exercises your ability to recall contexts very rapidly and I’m enjoying growing that capacity.
> I felt that one in my bones. I was up until nearly 2am recently, prompting, because I was so close to getting a plan right. Or so I thought. [...] And it's addictive in a way that makes the isolation worse.
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
I remember when I was just learning how to code and making some web app, I had to do a lot more blind guessing and running. "Ok let me try this... Will that work now?" I remember staying up really late, feeling stuck to the computer in that slot machine mode.
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.)
It's a trip back to a guesswork stage because most of the training data looks like the process you described your beginnings have been like.
Now you know how to do things first shot. When you write the code, your inner voice reminds you ahead of time to do it like this and that. And that "this and that" is what your prompt needs to have to avoid the trip to guesswork. Working with agents is like working with juniors. If you don't give them the direction and explain how, they'll be as lost as the LLM. The difference is, your brain finds guardrails as you solve the problem, the LLM doesn't have this context, you have to give it upfront. Like, you know, a good manager would.
Yes, and now they don't have to agree, they ask an LLM, and we get half baked plans and quarterly goals and are left to figure it out ourselves. So the stakeholders have some ideas, some half assed designs get put together by an LLM, stories are generated by an LLM, technical details are filled in by an LLM, the implementation and code review are LLM. I can already notice the lack of critical thinking and scrutiny in the whole process, we're offloading all thinking and just creating these artifacts, designs, documentation, code, to what purpose I'm not sure. I'm having trouble even keeping up with everything going on. Of course, plans are more likely to change at any minute and we'll just rewrite everything on a whim.
> 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.
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.
While I appreciate and agree with the key points of the post, Claude's writing style fingerprints are all over it and I guess it's even more exhausting to read someone's AI written article.
I don't think it is AI, but I bet it has been through editing/review to match a corporate style. LLMs were trained on this.
The writing style, if not AI, is at least a bit tryhard.
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.
> why do people feel the need to run this fast
Because if they don't they feel like they will be replaced by someone who will
This attitude gets people to willingly engage in abusive crunch practices such as in the games industry. I think the people who are like this are the ones who later talk about crunch like it was good in some way or necessary.
Basically a bad relation to labor and sustainable lifelong work.
This happens all the time, even before LLMs. And it happens even when there is no threat. A lot of the time the race to the bottom is driven by anxious people running from imaginary threats. Which is why its often useful to have a person in a group who tells people not to panic (this is often an older person).
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.
> I don't think it is AI, but I bet it has been through editing/review to match a corporate style. LLMs were trained on this.
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.
It's AI. https://www.pangram.com/history/09db86cf-37fb-4b27-94bf-a9f2...
If you switch on the 'Supporting Evidence' on that site, it seems to be basing it's opinion on three things:
- 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.
Pangram's "Supporting Evidence" feature is misleading and you should ignore it. It's entirely separate from the classifier that determines whether text is AI; it just takes text that's already been classified as AI and looks for some hardcoded AI tells in it. I kind of wish they'd get rid of it, but nontechnical users really like it.
The classifier itself has a very low rate of false positives: https://bfi.uchicago.edu/wp-content/uploads/2025/09/BFI_WP_2...
It's so tempting to drop the text of that paper into Pangram. :)
Pangram clearly says "Remember, our results aren’t based on this evidence." when you turn on supporting evidence.
I also thought "I'm so glad this isn't AI" but maybe I can only recognize ChatGPTs crappy writing style.
I think it was written mostly by AI, but with a lot more human intervention than the average AI written article, so it doesn't bother me as much as usual.
"It's not" - 3 matches
Dashline - present
Yes, it's AI-written
This very well may be AI written. Then again, the stuff our PMs output, all pre-AI, now would all qualify as "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:
I’m sure—pretty sure—we can use em-dashes w/o setting off the slop bells.
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.)
I have started honing a method of trolling where i intentionally write like a crappy AI, but, do it by hand, just to prank my anti-AI friends. Gotta get my kicks somewhere. It's not just fun-- it's annoying. :-)
"It's not" only has two matches; the third is "It's noticable". The other two are a whole paragraph dedicated to "it's not X, it's Y" which is a little more than you'd normally expect.
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.
Would AI have spelt "noticeable" correctly?
"If you can't be bothered to write it, I can't be bothered to read it."
Reminds me of "The Animal is Tired" (2021) (https://www.robinhobb.com/blog/archives/2021-05)
Oh that hit me more than I thought it would, thank you.
> The animal is aging. Not surprising; I knew it would happen eventually, but I didn't make any provisions to deal with that eventuality. Somehow the reality crept up on me. And now it must be dealt with, day after day.
(only ~5 paragraphs left now so y’all might as well finish it :) )
Thanks, lots of hackers can use the reminder.
To my fellow nerds: Take care of your bodies! Walk, move, exercise, occasionally eat a vegetable, reach for a piece of fruit rather than a soda! <3
Such a good read. Makes you think. Thanks for sharing!
This is a great read, thanks.
> I came to the formalisms of software engineering through painful experience rather than academic instruction. If anything, that made me take those principles more seriously once I understood them.
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.
I worked for years at a manfuacturing facility where the engineers were men who only had a high school education and slowly (from the 80s through to the late 2010s) had been promoted up to doing engineering, but, with ZERO academic or theoretical background.
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.
>It's also, frankly, quite lonely. Programming with an LLM is an intensely solitary activity. > You and the machine, going back and forth, refining and prompting and reviewing.
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...
Ya my memories are similar: ~12 years old building BBS's late into the night, then after college first startup, programming from midnight to 5am "in the flow" - nobody around or online. Just me and the problem at hand.
Being able to ask an AI an embarassing newbie question that I should really know but I just need someone to remind me / confirm my half-forgotten knowledge...
I get your point, but:
> "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.
There are different kinds of developer. Some will find their joy through building fast, they tend to love LLMs. Some love the art of writing code; they don't tend to love LLMs. And there are others too. Those that enjoy fully understanding a piece of code can find the process deeply draining, while those that look at things from a system level find the LLM frees them from the details.
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.
Funny I made some very similar points awhile back in a blog post, thinking of it in terms of mode collapse: https://tonyalicea.dev/blog/single-mode-burnout/
> the runaway inference truck.
Nicely done, thank you.
You are right to push back on that.
> The temptation to delegate the review itself to an AI was enormous. But, as he put it: "at that point, what am I still doing here?".
Sadly, this is a question for his boss, not him. It’s not existential. It’s economical.
Are you tired?
Tell us why.
http://tired.com
the irony of an article about human fatigue being detected as AI-written by half the comments is doing more for the argument than the article itself
Pinch to zoom on an early iphone navigating those fixed-width sites worked surprisingly well.
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.
> He described waking up to thirty PRs every morning, each one pulled overnight by someone's AI, and needing to make snap judgment calls on every single one. The temptation to delegate the review itself to an AI was enormous. But, as he put it: "at that point, what am I still doing here?".
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).
Business managers get to delegate their work, make big money, and just spend their time at work gossiping before leaving at lunch to go play golf or work on a second job as a consultant, or on the board of another company, or creating a new startup. Pretty good deal imo
> The honest truth
> 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?
Clicks, views, attention. This blog is part of Pydantic's sales funnel.
> That loss is real and it's worth naming
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.
It got a lot of clicks here. Clicks equal money.
It's just as easy to do the second one as the first one.
I don't understand how people are using AI.
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?
I've not had that problem, but I have 35 years of programming experience, so I can describe exactly what I want. Maybe that's the difference. It doesn't have to be a single sentence, I write a whole paragraph or even pseudocode most of it and tell it to use the pseudocode as comments for the code it will produce. It'll give me a plan and I'll refine the plan until it seems to be what I want. Then we'll get it to start writing and I'll give it feedback and keep it on track. If it tends to overthink a problem, I'll interrupt it and have it talk over the issue, until it gets a clear understanding of what I want. You have to treat it like a coworker more than just a code monkey.
The dream is "I have an idea for some awesome software, I will set an army of lemmings out to do all the tough work of figuring out how it actually works".
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.
> It doesn't have to be a single sentence, I write a whole paragraph or even pseudocode most of it and tell it to use the pseudocode as comments for the code it will produce. It'll give me a plan and I'll refine the plan until it seems to be what I want. Then we'll get it to start writing and I'll give it feedback and keep it on track. If it tends to overthink a problem, I'll interrupt it and have it talk over the issue, until it gets a clear understanding of what I want.
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)?
Because when i have to build the 12th throwaway gui for some thing at work... i just want to get past it and onto the fun stuff.
It stresses me out for some reason and I'm just working on a hobby project.
Shame. There is something thoughtful in the post, I am sure, but I am so tired of reading Claude that I couldn't get myself to engage.
One could hope that the author is making a meta-point.
It's sad to have to unearth the very human line of thought in this article from the very foamy LLM slop.
The 2 a.m. prompting bogs down to FOMO of not being fast enough with ideas, and that some other people will implement it faster and one won't make the share of money they envisioned.
I certainly don't have this problem. Even with LLM assistance, my hobby projects experience slow, steady growth, but it's done on my terms. I code when I have a mood, with or without LLM.
Recently I bought a Claude subscription only to use it for 3 days to speed up some coding. Then I cancelled it and stopped. My creative days ended, and I got to other stuff. I know I'll lose 27 days of possibilities, but I couldn't care less. If I'm in the mood to code with AI, I'll buy another month, maybe only for another couple of days.
People, stop accelerating at full throttle, find some real joy in life. It's not about the amount of lines, features or products shipped, let alone about amount of dollars you brag about, if they need this much effort and sacrifice.
Should we not get to work less if Ai is increasing productivity so much while also making us exhausted more quickly?
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
Instead of getting 25 hour weeks, half of us will be unemployed permanently and the other half will be working 50 hour weeks.
It's a really smart future that the wealthy business owners and investors are building for us.
[..] that the wealthy business owners and investors and all the AI users are building for us.
Name one time in all of history when increased productivity translated to workers working less. I'll wait.
Every single worker that has been laid off due to "increased AI productivity" is working less
As a broad historical trend? Maybe not
But fewer people working, right now? Absolutely
> Every single worker that has been laid off due to "increased AI productivity" is working less
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".
Relatable.
> 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.
>When you've earned your opinions about architecture and code quality the hard way, they feel less like textbook rules and more like scar tissue.
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.
The tiredness isn't from being in the loop. It's from what the loop hands you. Reading a wall of an agent's prose to check if it understood a screen is exhausting. The same check as a marked element with coordinates takes a second. It's not a human-attention problem, it's format problem. Models emit prose because it's cheap to generate, not cheap to review.
I feel the opposite, AI is making me less tired at the end of a working day even though I get much more done.
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.
You were probably just inexperienced in coding. AI has completely bridged that gap. Someone with a 1000 hours coding experience has almost the same speed as someone with 10 hours of experience who gets stuck on syntax like you said.
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.
Lol, I have 42 years of experience in coding, of which 29 paid. I learned to program when I was 14 years old, studied computer science and went to work in IT. I'm 56 years old now and working as a tech lead.
> 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.
Sorry but is this a bot comment? (Not replying, asking other readers)
Lol I guess this is our future, we have to prove that we are not bots. How would I prove this to you?
He might have just used an AI translation tool.