The human-in-the-loop is tired(pydantic.dev) |
The human-in-the-loop is tired(pydantic.dev) |
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.
Thanks Claude.
Turns out the human reading this is tired, too
What used to tire me: being forced to have a sharp eye for syntax errors when programming, or simply the effort of all the typing and navigating through source files. Trying to visualize details of the codebase I was changing, while at the same time keeping a high level picture in my head of the feature I was changing.
With AI, I can focus on the high level picture. I can focus on the steps to get there and the steps to verify that it works. I don't have to focus on syntax anymore and there is much less need to visualize large parts of my code base. With AI, work is still tiring but much less, and in a different way.
In return, there is not much of mastery anymore. Being a craftsman is a deeply human desire that AI is destroying, not sure if this is a fun future to look forward to.
> Being a craftsman is a deeply human desire that AI is destroying, not sure if this is a fun future to look forward to.
AI is giving me back the feeling I had when I first learned to program, when I was 14. At 14, I suddenly had a tool in my hands that was like an extension of my imagination. I could create tools, games and what not with it, this is what I loved. AI is that same tool on steroids. If what you like is creating things, AI lets you do it at 10 times the speed.
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?
“The honest truth … worth naming”.
“But the bottleneck was never the code. It was always the human attention”
Perhaps this is human audit over a first AI draft. But had enough AI speak that it puts it off.
Just write like a human with human mistakes. That’s okay.
One could hope that the author is making a meta-point.
Tell us why.
I’d add another dangerous bit; for some people (me) it has a side effect. Where before, if I spent 6 hours in deep hack, I felt like I had accomplished something, and I was mentally spent. I was done for the day, a job well done, not desiring or really capable of more productive work.
Now, the work is lower intensity, higher levels of abstraction, and I can do it for 16 hours a day, effectively, and still feel like I’m not done. I’m covering 6x the ground, but I feel like I accomplished less. It’s a bizarre productivity trap , fiending for dopamine like golemn fiending for the ring, exhausted but not spent, producing more than ever but never enough.
At least I’m not working for someone else, but sometimes I wonder if I would handle it better if I was?
> 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.
Has this person ever been a design or tech-lead for a team? I'm still tired and I've moved on from that role over 5 years ago. Gathering requirements, designing a solution, implementing as tickets, handing off to developers, staying involved in the feedback loop, then reviewing the code and iterating on PRs is absolutely exhausting. The only thing greater than the naive take that HITM is tiring is the privilege to not understand how asinine it is.
Quote:
...i hate the code it generates, i hate the feeling of getting everything i ask for and nothing i want. I hate the subtle offness around vibe coded things. It is just driving me nuts.
Annnnnd TFA is written by AI. I want to get off Mr. Bones' Wild Ride.
Like, they want to professionnaly, kill you. Theh are as much as a tool as is a cord pending from the ceiling
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)?
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.
I’ve heard some version of this take many times, all I can say is that is not what being a craftsman is. Ands that’s fine I suppose for some people and not fine for others.
The best analogy is think of a musician. As he gets better, he learns to play better tunes, and develop better tunes. Now in the future (not too distant), let us say he just needs to prompt an LLM and say make this melody a bit longer, a lower pitch etc, he is effectively making music but it is no longer the same process, and I think the joy is gone for a majority of the people, though I’m sure some exceptions will exist who prefer just prompting an AI to generate music.
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.
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’m already personally seeing the diminishing returns of AI generated code, especially in light of the increase in token prices (or tokens required per task, both are the same).
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.
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.
It is all about the destination now where it used to be about the journey and the destination.
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.
It takes way less knowledge and experience to guide an LLM, than it does to write it yourself. Especially if LLMs are already being trained on previous knowledge.
I'm already seeing people on Linkedin having almost no previous experience (or a Junior at best) getting hired as AI engineers.
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.
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.
At this point, why not just talk directly to the AI?
Asking as someone who is likely leaving dev, and maybe tech completely, very soon, possibly to go wait tables, as he hates everything about the way things have gone in the last half decade or more with remote work, stupid levels of unnecessary complication everywhere (people architecting to be the next Amazon as soon as, or even before, they have three users, and just about every thing client-side), and now generative AI, and would rather be replaced by a Claude license and a monkey to use it than deal with generative AI & related agents himself…
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.
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
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
Coding has generally been a slow and deliberate process, now we can go much faster if we let the LLM drive. As an intelligence, it is somewhere between a savant and a toddler, and watching from the backseat is both thrilling and terrifying. I think people will do it for a while and then realize that walking wasn't so bad, it's kind of nice. You are more likely to end up in a place you want to be.
> That loss is real and it's worth naming
I think I will not heed the first sentence and bear with this. What motivates people to do this? What do they get out of prompting Claude for some vapid "thought piece" and spamming it on the internet?
Yep classic Claude-ism.
The fact that this article was likely AI generated is the real load-bearing factor in this discussion. Or, as previous versions of Claude would say; it cuts through the heart of the issue.
Then i read "is real and it's worth naming" and thought god dammit, these assholes actually did use Claude
I guess this is also meant to be an advertisement but it's really roundabout. And while this case is maybe an ad, a lot of these LLM spam articles are on empty blogs not associated with a product.
This happens to everyone, very sadly. Arguably, feeling your own decay is not just sad, it's the greatest possible sadness and also what drove most mad people mad.
The author was 70 (now 75) and argues wishes he'd treated his own body better, but if he had, he would still be in the same position, but would have missed out on experiences whose memories I'm sure he now treasures. He once played in the snow too long and got frostbite? His feet would still be sore today if he hadn't, but he wouldn't have played in the snow.
Take care of your body as much as you can, but you can't treat it like a potion in a video game that you're always afraid to use in a fight because you might need it for the next fight. Eventually you get to the end of the game without using the potion.
And more somberly, every part of you can be sacrificed once or zero times to achieve something you believe is a greater purpose.
I'm still in some kind of emotional crisis as thinking about this sort of thing makes me break down crying.
(only ~5 paragraphs left now so y’all might as well finish it :) )
Thanks, lots of hackers can use the reminder.
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...
[0] https://static1.squarespace.com/static/644321e78cd2dd37613af...
Not related to the article, but I've seen this thought before and I think its wrong.
This isn't what good academic instructions gets you. Instead, they provide a systematic approach to learning foundational/core formalisms which let you recognize other problems as being of the same kind.
An academic background should let the person reason from a place of pre-explored essential complexity, instead of first having to rediscover & deconstruct the accidental complexity.
Building scar tissue about why things are a certain way is practical experience for (non)academics alike.
It was a massive disadvantage for them. They could carefully recreate the exact same thing over and over for new products that were similar to the previous version, but it was ALL cargo culted so they were terrified of any change, because they had no idea why a PCB was built in a certain way or what it meant to alter some aspect of a circuit board. So they were extremely, extremely resistant to any sort of change whatsoever.
And I as a young hardware engineer would get laughed at for saying things like "Do we have any fine copper wire? I need to make my own inductor for this test" because they didn't understand that an inductor is just coiled wire. Our board designer didn't understand why vias would be placed in a ground pad to link it thermally with the ground plane on a different layer, and laughed at me when I said we needed to "move heat around". He put a single via in the center of a huge ground pad. I asked him to put a grid of vias, so he humored me while having zero idea what the vias were for, or that having many vias linking two thermal planes would transfer more heat than just a single lonely via in a big pad.
Shit like that.
So I agree with you, the theory learned in academia plus the pedagogy is hugely useful and lets someone skip over decades of blind struggle.
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...
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.
Nicely done, thank you.
Perhaps on the way to UBI and the end of labor, we could get a 32 and 24h work wweek with lots more vacation, my hope at least
It's a really smart future that the wealthy business owners and investors are building for us.
https://www.aeaweb.org/research/workweek-restrictions-great-...
As a broad historical trend? Maybe not
But fewer people working, right now? Absolutely
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.
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.
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).
Sadly, this is a question for his boss, not him. It’s not existential. It’s economical.
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.
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.
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.
So, if you're not actually a programmer, or not a good programmer, you look at AI output and think "Wow, I could never have done that so well/fast. AI is great at this!" It's solving something he's not good at.
On the other hand, if you already are a good/skilled programmer, AI is not solving anything for you. Its output is flawed and has to be manually fixed and refactored. When you consider the prompting and the waiting and the cajoling and the fixing and the refactoring, it's not really doing things faster than you could.
I'm not an artist. To me, AI art seems great, because it's doing something I am very bad at. I think the same is true for AI programming.
This seems to not coincide with the reality of some very skilled programmers saying exactly the opposite.
Just to quote the latest one, here's Linus Torvalds, who I think we can agree is a good programmer:
> AI is a tool, just like other tools we use. And it's clearly a useful one.
> It may not have been that "clearly" even just a year ago, but it's no longer in question today.
> There are other questions around AI (like what the economy of it will actually look like in the end), but "is it useful" is no longer one of those questions. Anybody who doubts that clearly hasn't actually used it.
Lots of noise, and no actually measureable improvements. Just a lot of anecdotes
And people should keep in mind how much money that there is riding on this. Especially on a site like this, there's probably people who are multi-, maybe even hundred-, millionaires if their AI bets continue to pay off.
I dunno. There's a lot of dust in the air. All I know is I hate using it for code generation. I don't like being personally accountable for code I didn't write. I don't like TDD and I don't think large test suites are a guarantee of good software anyways. I'd rather work with a team of eager juniors than prompt an LLM all day.
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.)
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.
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.
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 actually possible to counter some of this stuff with skills and guard rails. The author clearly has not mastered how to do that and sound more authentic.
It's all a bit stunted, cringe, long winded, repetitive, etc.
I find it very tiresome and repetitive and simply too grating to read at this point, after already working with Claude all day.
Dashline - present
Yes, it's AI-written
There are certain writing styles, which even if you wrote them all yourself, most people will now attribute to AI. The all-too-common em-dash, yes sure. Guess what, it's a thing that was actually taught as "the thing to use if you write properly". So guess what lots of folks consciously put into their writing to sound more professional even before AI. Bingo!
Similarly CVs. A lot of the stuff that lots of us complain about post-AI was "good practice to do" pre-AI. But most people didn't bother. Couldn't be bothered. Now that AI was trained on it and people ask their AIs to write CVs, it's all over the place.
A cover letter that actually picks up on the actual job description posted and connects it up to your CV? That used to be hard work and most people didn't bother. It made you stand out. Now it "reeks of AI" :shrug:
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.
> "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.
Those of us who have worked in modeling and simulations know two principles of models:
- garbage in, garbage out
- all models are wrong, some are useful.
Point being, usually when "the model is wrong" it's because we put the wrong input (too complicated prompt for the model?) or something similar. Its just a machine, like a meat grinder that we turn then cogs.
Working with an LLM doesn't really feel like programming at all. It's more like telling an intern to program, which some might like, but I find totally unsatisfying and not anything like programming.
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".
I am not strictly equating this to coding though. Like the GP sometimes I am driven more by the product than by being able to make it by hand. But that does not mean vibe coding, I still make sure the code is up to my standards.
Employers/owners are rewarded by the end result
It's obvious why employees using an LLM would get burnt out
We want to end up with code that makes sense generally, to whomever is editing or or debugging it in the future. That next-person usually won't (or shouldn't need to) mine the git history to understand the current project in front of them.
when the stack is complete and all the commits are uploaded to wherever (we use phabricator but i'm sure github has an equivalent) for review i just need to sit back (or work on something else) while my reviewer(s) go through each commit and validate that it looks like it does what it says on the tin. as soon as the bottom of the stack gets approved i can merge it in, or i can wait for everything to be reviewed. if there are any changes i do them and rebase the rest of the stack on top of the changed commit, fixing merge conflicts if needed. (it really helps if your tooling supports this workflow, of course!). and when it's all reviewed and merged, the effect is exactly the same as if i'd just sent in a 2000 line combined commit and merged it in - there's no need to go look through the git history for anything, the code will hopefully make sense as part of the codebase.
Not really the same feeling. It’s more like speaking a foreign language. At the beginning, you’re always guessing at words, and what’s the correct structure/expression. After a few years, you can go direct from idea to sentences.
Today, my brain is familiar with “computer speak”. More often than not, it goes straight from ideas to algorithms and data structures. My time is mostly spent on checking assumptions (what’s the data type returned by this call,…) and verifying results (debugger, tests, printf,…).
Using LLM is like hiring an unreliable translator when I already know the language. Yes, it may speak faster than me, but I do not a faster pace of conversation.
Fantastic analogy. And when you don't really know the language that well you're just amazed at the translator, like "wow you can speak really well!"
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.)
Your slop, my slop, their slop it's all 'slop' and no one can really care about slop. The novelty is wearing thin fast
If I make uninteresting art, it's not because I physically lack the ability to use my hands in a manner that would create interesting art. It's because I can't come up with the ideas, and lack the taste, to produce interesting art.
I'm interested in the source code to Quake but not in the source code to an LLM generated Quake equivalent, I love to hear about the Fast Inverse Square Root formula in Quake that Id software wrote but I'm unmoved by the generated LLM version.
There probably is a correct way to do this, but your average "vibe coder", or even a competent solo dev just yoloing a project, are not implementing such harnesses. In the former case, they may not be able to; in the latter, you're probably better off in 1:1 human to agent workflow due to indeterminate/bad outputs and the amount of back-and-forth in prompts/specs/reviews required to get high-quality work
Then again, I saw Matz harness for his compiled ruby project was just like perms.allow find and grep. No skills, no agents.md or anything like that. Would love to see those prompts! I'm sure the fact that it was Matz had a lot to do with that working, though
Because if they don't they feel like they will be replaced by someone who will
Basically a bad relation to labor and sustainable lifelong work.
But of course the AI guys are preying on this anxiety in order to dominate. They are all over HN, either personally or with their bots. Which is why HN is no longer a place that you could go to get mainly unbiased anecdotes and experience. That is still available but it is being drowned out by FUD because the average HN user is now the mark.
- Use a descriptive triad of "reviewing, directing, and course" (it incorrectly misunderstood 'course correcting'). That's not common in writing but humans do do it occasionally.
- Using the word 'thoughtful'. I don't understand that as evidence of AI.
- Using the words 'Book Apart' together, which would be a clear AI signal if it wasn't the name of a publisher of short books, and being used in that context in the article.
I don't think you should put much stock in the output of pangram.com.
The classifier itself has a very low rate of false positives: https://bfi.uchicago.edu/wp-content/uploads/2025/09/BFI_WP_2...
Sometimes I want to cook, that’s a thing I want to actively do. Sometimes I cook because I want to put dinner out, dinner being out is the thing I want and cooking is just a required step.
Sometimes I want to solve a problem, sometimes I want a problem solved.
Here’s the tricky part for me now and I think others are hitting it - when a machine can solve the problem does that devalue the feeling of doing it by hand? Solving a sudoku feels good even though I know I have multitudes of machines in my house that could solve it faster than I could pick up the pen. Games that place a dollar value on some item I can also achieve makes me feel like the effort is only worth $ though. This isn’t logical but I’m ok being human.
So for a personal project do I get the same feeling doing it by hand? Will it feel like I’ve just made my life harder for no reward or will it be a nice satisfying thing?
As the models get so much better the goalposts shift too, the less I direct the less I was needed.
It’s a weird time. Fascinating, exciting and definitely useful - but so much of what I’ve learned is rapidly becoming less and less important for many tasks. Still, I’ve argued for many years that more people should code because it’s such a powerful tool even used basically, I guess I’ve got my wish (and that side I genuinely love, seeing people make things with their domain knowledge and not having to learn exactly how brackets work in order to automate something)
Now for every problem I know Claude/Codex will do it, and they do. I just don't get that feeling on finishing 10 features now.
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.
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.
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. '
The 'washing machine' problem, was solved decades ago.
Improvements in detergent allows basically anything to be washed with cold water.
Added 'features' from late model machines do very little to improve the experience, and instead drive up purchase price, and decrease lifespan.
It's weird that so many pro-LLM arguments rely on bad analogies of other technologies that aren't perfect, and say, "We're not perfect either. That stuff is embedded in society, so you should do that for us too!"
You mention improvements on how good clothes are washed for you, after decades of technical progress. Oitside of the analogy, we are literally living through that, but in 10x speed on a day to day basis regarding how well AI writes code.
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
And "solving needs" is kinda vague. We drank from lead cups for a long time, because perfect knowledge of material and biology was secondary to just having a cup. And no single sip from any lead cup killed or maybe even much harmed any person, but it all added and adds up.
Of course the comparison with lead is kinda over the top, but it's just to illustrate the principle. If your software crashes the computer 1 out of 1000 runs, and it otherwise crucial and unique, people will still use it, and the longer and the more people use it, the more human lifetime it "destroys". If it would take you 1 year to find the source of the crash, it may not be worth it, if it would take you 30 minutes, it might be. You just won't get recompensated for it, you'd have to get satisfaction from it via something like craftsmanship.
Your users don't know either way, so it's your job to know. Saying it's not, everybody just has to be content with the transaction, is a bit like saying a doctor doesn't have to do medicine according to what they know is likely best, but according to what their patient thinks they need.
If you're making a plane, crashing 1 in 1000 times is terrible, if you're making some administrative thing which if it crashes costs 5 minutes work then it's likely fine
But you're still implying that the fancy software crafted by hand is better.
I have handmade crafted products and I have assembly line products. Not only are the latter cheaper and more consistent, they're often better. I don't want my beer to come in a handcrafted artisan glass while I'm watching the football, I want it in a pint glass of a known size and quality.
Yes, and if it doesn't crash it's better than fine. Objectively.
> I have handmade crafted products and I have assembly line products. Not only are the latter cheaper and more consistent, they're often better.
Completely ignoring the care and work that (ideally) goes into making and running the machines at assembly lines, and the cleaning that takes place every day, or sometimes several times a day, all the strict regulations. You cannot compare 99% of software engineering with food production in modern countries. Similar for furniture, it can hurt or even kill, and it would do at a much higher rate if it was made like most software is.
There's gross factory food, and super nice street food, there's healthy factory food and super gross street food. That has nothing to do with anything. All else being the same, you want the person who prepares your food or runs the factory to pay attention and not be sloppy, or you end up with food poisoning, glass shards, and other fun stuff. You just take allll of that for granted, instead of imagining how awesome computing could be if the people involved in it took it similarly seriously instead of just applauding their own laziness.
1) spending more time handcrafting the code makes it less likely to crash
2) That the cost of the crash is more than the cost of the artisinal crafting
Who says you need a boss or other human coworkers?
Start your own consultancy and take 100% of the pie. The term "employee" evaporates in this context, as does an entire universe of lazy, negative tropes about work ethic, etc.
I didn't. However most people on here and around the world are employed I am merely pointing out that your employer dictates so much of what you do.
> Start your own consultancy.
Great, but realise then that you are talking about creating a business. Which is a whole other field altogether. You can have a business in software, or in legal, or mining etc. But that's a different conversation. It's about business and not about software or LLM's.
If you're 'no longer looking at the code' or 'looping everything' then you are implicitly moving towards a more quantitive outlook of software development. How it does so becomes less and less meaningful and why would you even care?