> 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.
DanielHB 11 hours ago [-]
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).
datsci_est_2015 6 hours ago [-]
My cope goes one level further, I’m already seeing incidents where poorly designed code (not necessarily purely “vibecoded”) has made it extremely difficult to figure out why a system is failing. Errors like “SegFault” and “Driver unresponsive” still exist, and so far even $100 of AI credits don’t seem to be able to solve those issues.
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).
thinkindie 15 hours ago [-]
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.
AyanamiKaine 10 hours ago [-]
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.
tripleee 23 minutes ago [-]
Employees are rewarded by the process
Employers/owners are rewarded by the end result
It's obvious why employees using an LLM would get burnt out
luipugs 9 hours ago [-]
There is no art without process though. The art is the process. Is an automatic piano more beautiful than a world class pianist? Of course not.
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.
phoghed 8 hours ago [-]
Maybe for the person who automated the piano it is
dare944 8 hours ago [-]
Well, a large swath of both sides are wrong in that they insist theirs is the only valid perspective.
hdjrudni 14 hours ago [-]
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.
Schlagbohrer 12 hours ago [-]
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.
encyclopedism 11 hours ago [-]
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
deaux 7 hours ago [-]
Of course not, this makes no sense. It's the opposite, most of LLM generated apps are indeed uninteresting, yet it's not inherent at all. Most photos, most drawings, most human-written articles are uninteresting and have been so since forever. Nothing about that is inherent. And in the exact same manner, no, others can't generate the same thing. They physically can, but that has never been a barrier.
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.
encyclopedism 6 hours ago [-]
I think you missed my point I'm not denying the code does not produce a function of effect. The code however is uninteresting because almost anyone can also generate it.
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.
DanielHB 11 hours ago [-]
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.
thinkindie 7 hours ago [-]
I know exactly what he means - and as I said it all depends on personal drivers/motivation etc etc. take doctors: some starts the profession to make money other to care about people. Both categories can live under the same roof in a hospital.
zelphirkalt 6 hours ago [-]
Going with the doctor analogy: One type tries to be genuinely helpful, the other type suggests unnecessary operations, since it costs more.
pegasus 6 hours ago [-]
Isn't steering the agent the new journey? Why shouldn't that provide "little intrinsic rewards"?
iso1631 10 hours ago [-]
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
customguy 8 hours ago [-]
All you're saying is that for you only the destination ever mattered. But it's very apparent that is not true for a lot of people.
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.
thinkindie 7 hours ago [-]
It’s not just the destination - there are infinite shades of caring too much about every single line of code (spaces! Tabs! Inline open curly braces! Next line) and caring about the final result without attention to what is running under the hood.
6 hours ago [-]
iso1631 8 hours ago [-]
And it is true for a lot of people. It's also true for the people paying my salary.
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.
customguy 6 hours ago [-]
> 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
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.
throw1234567891 10 hours ago [-]
I think you don't understand that they understand. For them it's the destination that matters. Their journey is different.
bluefirebrand 8 hours ago [-]
They are admitting pretty directly that even they don't value their own journey only their destination
elmer2 6 hours ago [-]
This sounds like development/engineering will eventually go from a knowledge-based career to a factory worker, with a reduction in salary.
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.
fragmede 13 hours ago [-]
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.
verdverm 16 hours ago [-]
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
georgemcbay 15 hours ago [-]
> 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.
IanCal 12 hours ago [-]
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)
j1elo 12 hours ago [-]
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.
bob1029 11 hours ago [-]
> 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.
encyclopedism 11 hours ago [-]
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. '
bob1029 8 hours ago [-]
> That's a situation your employer sets up for you!
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.
encyclopedism 7 hours ago [-]
> Who says you need a boss or other human coworkers?
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.
baq 8 hours ago [-]
The customer can absolutely tell the difference between a Caterpillar digger and a dude in it vs 100 dudes with shovels
encyclopedism 7 hours ago [-]
Attempting to illustrate why your analogy is flawed and explain myself a little better I would add that there are quantitive things and qualitative things. If the object was to remove some volume of earth (quantitive) then whether it is moved by a Caterpillar or by 100 men with shovels does not matter.
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?
baq 6 hours ago [-]
I'm saying I'd rather have a dude in a digger than a hundred folks who need to be supplied, some of them drunk, some of them thieves, some of them just plain bad at digging and only making a mess of the dig site.
claudiulodro 5 hours ago [-]
In this metaphor, your dude in a digger could also be drunk or a thief or bad at his job, and that'd be a bigger problem vs. a few people from a 100 person hand crew.
baq 4 hours ago [-]
This is true, but my priors say it’s much less likely to get a thief or a drunk in a digger than in a group of a hundred folks with shovels.
dnemmers 9 hours ago [-]
Disagree.
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!"
j1elo 8 hours ago [-]
I think it's not as bad of an analogy. Where you dedicated time and perfectionism for each piece of clothing (line of code), now you push a button and get them all done for you.
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.
nibbleyou 15 hours ago [-]
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.
DanielHB 11 hours ago [-]
It is all about the destination now where it used to be about the journey and the destination.
zem 18 hours ago [-]
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.
1473-bytes 17 hours ago [-]
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.
zelphirkalt 12 hours ago [-]
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.
hahahaa 18 hours ago [-]
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.
Terr_ 16 hours ago [-]
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.
zem 16 hours ago [-]
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.
Terr_ 15 hours ago [-]
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.
zem 14 hours ago [-]
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.
carimura 16 hours ago [-]
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.
user43928 11 hours ago [-]
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.
roomey 12 hours ago [-]
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
leethargo 12 hours ago [-]
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.
taneq 11 hours ago [-]
Employee Role: Blameable Component.
NoGravitas 3 hours ago [-]
Employee Role: Meat Shield
throw1234567891 10 hours ago [-]
And when was it not...
bluefirebrand 3 hours ago [-]
I initially read this as "Blameable Compost" and honestly I sometimes feel like that's how executives think of me, so it still is accurate
bad_username 14 hours ago [-]
> 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.
hdjrudni 14 hours ago [-]
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.
dspillett 9 hours ago [-]
> Amusingly, when I know my peer is just going to point his AI at my feedback, I write for their AI, not for them.
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…
Henchman21 50 minutes ago [-]
Thanks for this, I feel slightly less alone in my feelings towards tech these days.
titanomachy 6 hours ago [-]
Maybe tech workers are going to evolve into a different species, immune to emotional arguments and no longer capable of mating with humans
boorang 12 hours ago [-]
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.
doginasuit 9 hours ago [-]
I think that the fatigue that many people are feeling is coming from the loss of control that is the inevitable result of more momentum combined with more chaos.
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.
BrandonM 13 hours ago [-]
> 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.
ryandrake 5 hours ago [-]
Someone in a HN thread a few months ago put it in a way that makes a lot of sense to me: "AI seems good at things you are not good at."
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.
anthonypasq 54 minutes ago [-]
this is pure cope, and the realm of things you are better than it at will continue to shrink, and you need to be mentally and economically prepared for this.
bluefirebrand 2 hours ago [-]
This rings true to me. There are some pretty notable software engineers that are saying otherwise, that they are getting tons of value out of AI, but there are also some very notable engineers saying otherwise. There are studies that say there are no improvements, some that say there are small improvements, some that say there are actually decreases. We're very far from any settled understanding of what LLM use is doing
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.
Terr_ 17 hours ago [-]
> 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
adamddev1 14 hours ago [-]
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.)
ryandrake 5 hours ago [-]
Sadly, I've met too many professional software developers in the industry, who never progressed beyond "Try something, see if it works, then try something else." AI is great for these programmers, since it's somewhat better than what they've done as a career for decades.
throw1234567891 10 hours ago [-]
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.
skydhash 8 hours ago [-]
> 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
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.
adamddev1 4 hours ago [-]
> Using LLM is like hiring an unreliable translator when I already know the language.
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!"
dsego 11 hours ago [-]
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.
eugmai86 2 hours ago [-]
Part of the fatigue comes from agents explaining everything in prose. When important operations happen through constrained tools, the human can review structured inputs, results and logs instead of reconstructing the entire conversation. Fatigue comes when doing same things many times day by day. What we did in our team - created MCP server that does most of routine operations automatically for us. We explicitly state to LLM that output shall be in simple words; structured in this or that way depending on the project and task. Yes architecture and decision making still on our shoulders but this is the part of the dev job nowadays
rsanek 10 hours ago [-]
> 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.
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.
hahahaa 18 hours ago [-]
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.
anon373839 17 hours ago [-]
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.
matltc 8 hours ago [-]
I am with you but I inevitably think it's a skill issue. Some devs put a lot of work into the harness. I tried doing this, felt like running in place to me. the lack of RFC-tier standardization and ever-shifting api is demotivating as well since you might have written a harness that will be obsolete with next model gen/version bump
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
bluefirebrand 15 hours ago [-]
> 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
Schlagbohrer 12 hours ago [-]
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.
bluefirebrand 2 hours ago [-]
I agree with you completely and I push for saner work-life balance anywhere I work. Unfortunately this unhealthy work culture is really entrenched most places
discreteevent 13 hours ago [-]
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.
jillesvangurp 8 hours ago [-]
I just made chat gpt list all the key indications that this article was LLM generated. I'll spare you the details, it's a very long list.
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.
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.
ameliaquining 16 hours ago [-]
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.
It's so tempting to drop the text of that paper into Pangram. :)
johnfn 15 hours ago [-]
Pangram clearly says "Remember, our results aren’t based on this evidence." when you turn on supporting evidence.
sokoloff 8 hours ago [-]
That’s an unusual use of “supporting” for sure.
lelanthran 15 hours ago [-]
> 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.
Schlagbohrer 12 hours ago [-]
I also thought "I'm so glad this isn't AI" but maybe I can only recognize ChatGPTs crappy writing style.
VulgarExigency 11 hours ago [-]
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.
postsantum 18 hours ago [-]
"It's not" - 3 matches
Dashline - present
Yes, it's AI-written
tharkun__ 16 hours ago [-]
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:
Barbing 16 hours ago [-]
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.)
Schlagbohrer 12 hours ago [-]
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. :-)
Barbing 4 hours ago [-]
lol :)
samplatt 18 hours ago [-]
"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.
normie3000 15 hours ago [-]
Would AI have spelt "noticeable" correctly?
parl_match 18 hours ago [-]
"If you can't be bothered to write it, I can't be bothered to read it."
maxcoder3344 18 hours ago [-]
[flagged]
happytoexplain 18 hours ago [-]
I have such a hard time believing the implied premise of these complaints-about-complaints.
Just say you don't mind AI writing - make that argument. Don't make this nonsensical, defeatist, "if it's common, stop criticizing it" argument.
singingtoday 18 hours ago [-]
Well put. This kind of rebuttal, the "I'm not A, you're A", is not only tired, it's a strait up school yard fallacy.
maxcoder3344 17 hours ago [-]
[flagged]
Barbing 15 hours ago [-]
>Enjoy reading nothing ever again
Is it likely for AI written content of the HN front page to exceed 90%? Many would seek out the final 10%.
And wouldn’t you expect human and generated writing to be indistinguishable someday anyway in which case complaints should significantly drop off?
drdeca 16 hours ago [-]
Do you think the sort of people who complain about articles being AI-written are incapable of writing articles or something? Why would not being willing to read articles produced that way result in not reading any articles?
_fs 17 hours ago [-]
You created a new account for this?
maxcoder3344 17 hours ago [-]
No. I created an account for this. Hacker news used to be a place I could come read interesting content and peoples reactions and thoughts to it. now it's interesting articles with 100% of the comments whining that it's written by AI. Sad what hackernews has become
Barbing 15 hours ago [-]
Finished the thread, <50% complaining about article I think
15 hours ago [-]
newsicanuse 16 hours ago [-]
This guy is just another one of those ai-pilled noob coders
singingtoday 18 hours ago [-]
If complaining is exhausting to you, then I recommend avoiding Internet comments.
maxcoder3344 17 hours ago [-]
Nah just whining about AI. At least it has given the hoards of uninteresting people something to comment on every single hackernews article now
lelanthran 15 hours ago [-]
> Nah just whining about AI. At least it has given the hoards of uninteresting people something to comment on every single hackernews article now
Don't worry about it; notice how people are still talking to uninteresting whiners like yourself :-)
(Did you not notice you were whining?)
bgun 18 hours ago [-]
Complaints about complainers are even more exhausting.
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.
Barbing 15 hours ago [-]
> 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.
Schlagbohrer 12 hours ago [-]
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
nsbk 13 hours ago [-]
Such a good read. Makes you think. Thanks for sharing!
DavidPiper 10 hours ago [-]
Oh that hit me more than I thought it would, thank you.
Avicebron 17 hours ago [-]
This is a great read, thanks.
krysp 13 hours ago [-]
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.
xtracto 16 hours ago [-]
>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...
ryandrake 5 hours ago [-]
Yes, that was a weird one for me, too. I've always thought of programming as, at its purest form, a solitary activity. "Pair Programming" and "Programming Teams" are ideas companies graft onto the activity, or force on us, to build bigger things. At its core, programming is a single person, typing commands into a computer.
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.
carimura 16 hours ago [-]
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.
Schlagbohrer 12 hours ago [-]
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...
imp0cat 15 hours ago [-]
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.
xtracto 9 hours ago [-]
Oh but it really is. An LLM is no magic wand. It's a model as its name rigthly indicates.
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.
queenkjuul 8 hours ago [-]
I really think LLMs are capable of screwing up good input. They're not deterministic like a meat grinder
streb-lo 4 hours ago [-]
I think you mean "They're not deterministic, like a meat grinder"
> 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.
Schlagbohrer 12 hours ago [-]
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.
zelphirkalt 3 hours ago [-]
If only we listened more to people who studied CS on the job. Many disasters could prevented entirely.
recursivedoubts 18 hours ago [-]
You are right to push back on that.
AaronAPU 10 hours ago [-]
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.
ozgung 13 hours ago [-]
> 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.
luciana1u 16 hours ago [-]
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
magnio 16 hours ago [-]
> 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).
Schlagbohrer 12 hours ago [-]
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
aeternum 14 hours ago [-]
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.
applfanboysbgon 18 hours ago [-]
> 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?
greyface- 18 hours ago [-]
Clicks, views, attention. This blog is part of Pydantic's sales funnel.
jongjong 18 hours ago [-]
> 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.
singingtoday 17 hours ago [-]
It got a lot of clicks here. Clicks equal money.
inigyou 8 hours ago [-]
What does any spammer get from their spam?
applfanboysbgon 8 hours ago [-]
Well, usually advertising themselves. Spambots used to be really straightforward. "Come buy our penis enlargement pills at x.com!".
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.
hyperhello 18 hours ago [-]
It's just as easy to do the second one as the first one.
queenkjuul 8 hours ago [-]
I read "honest" and thought, "look at me, i can't even read the word honest without thinking it's Claude"
Then i read "is real and it's worth naming" and thought god dammit, these assholes actually did use Claude
dwroberts 8 hours ago [-]
This is an advert for a product, no idea why this on the front page, did anyone actually read it beyond the title
queenkjuul 8 hours ago [-]
I tried, but gave up very quickly. AI slop with little to say was my impression
ay 8 hours ago [-]
Oh the irony of using AI to create a piece of writing complaining about AI :-)
K0balt 6 hours ago [-]
Holy crap this piece is spot on. I’ve been trying to get my head around the weird thing that my work has become, and this article does a good job of painting the picture.
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?
thrymenarenot 17 hours ago [-]
It stresses me out for some reason and I'm just working on a hobby project.
ptrl600 16 hours ago [-]
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?
spiderxxxx 15 hours ago [-]
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.
ptrl600 14 hours ago [-]
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.
skydhash 15 hours ago [-]
> 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)?
superxpro12 15 hours ago [-]
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.
...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.
queenkjuul 8 hours ago [-]
> That loss is real and it's worth naming.
Thanks Claude.
Turns out the human reading this is tired, too
verdverm 17 hours ago [-]
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
bluefirebrand 15 hours ago [-]
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.
JackSlateur 14 hours ago [-]
[..] that the wealthy business owners and investors and all the AI users are building for us.
BugsJustFindMe 15 hours ago [-]
Name one time in all of history when increased productivity translated to workers working less. I'll wait.
verdverm 59 minutes ago [-]
We used to have people, including children, working up to 80 hours a week. We now have laws that limit those things. One does not have to create a direct causal relationship. One should more likely expect them to be separate because of the adversarial aspects between labor-capital.
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
BugsJustFindMe 15 hours ago [-]
> 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".
dgan 8 hours ago [-]
The whole premise of Anthropic and openai is to replace developers. I don't understand what mental gymnastics people are going thru to justify their 5 open claude sessions and tokenmaxxing
Like, they want to professionnaly, kill you. Theh are as much as a tool as is a cord pending from the ceiling
otter-in-a-suit 18 hours ago [-]
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.
the_real_cher 8 hours ago [-]
It would be cool if they forked one of these big open source projects and just merged all of the unsolicited AI generated PRs into the fork just to see what kind of monster that would create.
HackerThemAll 11 hours ago [-]
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.
sgarland 8 hours ago [-]
> That loss is real and it's worth naming.
Annnnnd TFA is written by AI. I want to get off Mr. Bones' Wild Ride.
inigyou 8 hours ago [-]
HN should ban any domain that's submitted with AI content. HN already shadowbans AI comments.
queenkjuul 7 hours ago [-]
I've lost count of how many times I've said "i want off Mr Altman's wild ride" out loud in real life
viccis 14 hours ago [-]
>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.
nojvek 6 hours ago [-]
Man. I wish they didn’t use AI to write an article about AI slop.
“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.
JimmaDaRustla 5 hours ago [-]
> ...but the human reviewing, directing, and course-correcting feels worse, not better.
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.
madikz 10 hours ago [-]
[flagged]
claud_ia 11 hours ago [-]
[flagged]
Schlagbohrer 12 hours ago [-]
[flagged]
hacker-matrix 13 hours ago [-]
[flagged]
madikz 10 hours ago [-]
[flagged]
1g10k 8 hours ago [-]
[flagged]
bickov 13 hours ago [-]
[dead]
bickov 13 hours ago [-]
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.
Avery29 11 hours ago [-]
[flagged]
joka88xj 16 hours ago [-]
[flagged]
UnfitFootprint 18 hours ago [-]
[dead]
lardosaurusrex 18 hours ago [-]
[flagged]
kaashif 17 hours ago [-]
Indeed. I guess we're talking about it, which is the point of marketing blog posts like this.
If it weren't claudeslop, it would still have to be marketing corposlop.
fizzbuzzdizz 18 hours ago [-]
[dead]
misja111 14 hours ago [-]
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.
sashank_1509 14 hours ago [-]
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.
misja111 14 hours ago [-]
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.
sashank_1509 7 hours ago [-]
> If what you like is creating things, AI lets you do it at 10 times the speed.
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.
three_burgers 14 hours ago [-]
Sorry but is this a bot comment? (Not replying, asking other readers)
misja111 14 hours ago [-]
Lol I guess this is our future, we have to prove that we are not bots. How would I prove this to you?
panting 14 hours ago [-]
He might have just used an AI translation tool.
Rendered at 20:37:31 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
Employers/owners are rewarded by the end result
It's obvious why employees using an LLM would get burnt out
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.
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.
It is all about the destination now where it used to be about the journey and the destination.
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.
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.
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.
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)
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. '
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?
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.
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.
my anecdotal advice is to avoid the entire "agent" temptation, and treat the LLM as a code generator. have a single session running at a time. come up with a plan, iterate on it until you are satisfied, then tell it to execute the plan, and watch it. not necessarily to the extent of reading the scroll (though I sometimes do do that too!) but as it finishes each step look over what it has done, suggest improvements and course corrections, and then let it go on to the next step. at the end you will have a pretty good grasp of the state of the code, and the overall time it will take you isn't really any longer than trying to churn out reams of code and then go through it all at once.
the other option if you want something closer to a one shot workflow is to go into far more detail during the planning stage, have it describe not just architectural details but actual code (if you're a senior engineer especially you probably know what the key pieces of code that will drive a lot of other decisions mechanically are likely to be).
also refactoring is cheaper than it has ever been, if something feels hard to grasp to you stop and work with the LLM until you like the looks of it better.
and again, the key bit is to have one LLM doing one thing at a time, and to stay engaged in the process while it does so.
Edit: I will say it's taken me some months of working with Claude to get to this working process. If you let claude operate with free reign, the inevitable mess and struggle it runs into burns and stresses you out. Also, keeping up with some manual coding when you feel like it and punting to Claude when you have had enough manual coding ensures you still feel in control of the codebase.
We want to end up with code that makes sense generally, to whomever is editing or or debugging it in the future. That next-person usually won't (or shouldn't need to) mine the git history to understand the current project in front of them.
when the stack is complete and all the commits are uploaded to wherever (we use phabricator but i'm sure github has an equivalent) for review i just need to sit back (or work on something else) while my reviewer(s) go through each commit and validate that it looks like it does what it says on the tin. as soon as the bottom of the stack gets approved i can merge it in, or i can wait for everything to be reviewed. if there are any changes i do them and rebase the rest of the stack on top of the changed commit, fixing merge conflicts if needed. (it really helps if your tooling supports this workflow, of course!). and when it's all reviewed and merged, the effect is exactly the same as if i'd just sent in a 2000 line combined commit and merged it in - there's no need to go look through the git history for anything, the code will hopefully make sense as part of the codebase.
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.
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
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…
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.
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.
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.
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.
Right, it's more like pulling the lever on slot machine. Oooh, 677, bad luck, do a ritual and try again, and maybe this time...
Sure, regular programming also has a feedback loop, but normal errors are--as much as possible and by design--things that happen consistently for reasons, reasons that force you to engage you mind to discern them and then eliminate them (hopefully) forever. Experienced developers don't just try something random, hope it works, and if it works you just dismiss it as unknowable.
> But the bottleneck was never the code. It was always the human attention, the engineering judgment, the ability to hold a coherent vision for a system. We just didn't notice because writing code felt like the hard part.
Unless, perhaps, you were already fatigued trying to deal with many stakeholders who can't agree what the system even is. :p
Then when I learned more I got less and less of that guessing feeling. I understood what I was building and what would work, I began using typed languages and could keep on track with the compiler/LSP. This brought me more into a satisfying flow state, and I had less of that addicting "wait let me see if this will work" magic.
It seems like coding with Claude etc is a lot like a trip back to the guesswork stage, and I don't want to go back there.
(Sometimes, when I'm doing some dev-opsy type stuff of stringing a bunch of messy components together or working with a pile of complex APIs, I can feel myself back in the blind guessing territory, and incidentally this is where I find a chat with an LLM most helpful.)
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.
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!"
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...
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.
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.
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.
- 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...
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.
Dashline - present
Yes, it's AI-written
There are certain writing styles, which even if you wrote them all yourself, most people will now attribute to AI. The all-too-common em-dash, yes sure. Guess what, it's a thing that was actually taught as "the thing to use if you write properly". So guess what lots of folks consciously put into their writing to sound more professional even before AI. Bingo!
Similarly CVs. A lot of the stuff that lots of us complain about post-AI was "good practice to do" pre-AI. But most people didn't bother. Couldn't be bothered. Now that AI was trained on it and people ask their AIs to write CVs, it's all over the place.
A cover letter that actually picks up on the actual job description posted and connects it up to your CV? That used to be hard work and most people didn't bother. It made you stand out. Now it "reeks of AI" :shrug:
And try to substitute them, you may; but the bell might still ring.
(Yeah it stinks we have to adapt to avoid sounding like a model, especially for the best writers who were probably ripped off a lot more than the rest of us.)
Firefox doesn't seem to discriminate between em-dashes and hyphens using ctrl-F so I'm not sure about those.
Having said that the tone REEKS of AI generation, so meh.
Just say you don't mind AI writing - make that argument. Don't make this nonsensical, defeatist, "if it's common, stop criticizing it" argument.
Is it likely for AI written content of the HN front page to exceed 90%? Many would seek out the final 10%.
And wouldn’t you expect human and generated writing to be indistinguishable someday anyway in which case complaints should significantly drop off?
Don't worry about it; notice how people are still talking to uninteresting whiners like yourself :-)
(Did you not notice you were whining?)
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.
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.
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...
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.
> "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.
Nicely done, thank you.
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.
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.
Sadly, this is a question for his boss, not him. It’s not existential. It’s economical.
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).
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.
> 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.
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.
Then i read "is real and it's worth naming" and thought god dammit, these assholes actually did use Claude
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?
A lot of the time, what I want to build, doesn't have a succinct English sentence to describe it. If I describe the user requirement I just get a Fisher-Price toy thing that kind of ignores most of the adjectives and adverbs in my requirement. So I'd have to prompt with a big list of specs and algorithms for the specific thing I want. Then what's the point?
Well I do have an idea for some awesome software, I know exactly what the user experience should be, but the lemmings are producing useless software that resembles my idea in the way a Fisher-Price phone resembles a real phone. With frontier models, now far less buggy useless software following code conventions perfectly.
That sounds like programming with extra steps.
Here's my No-AI workflow: I read the requirements and devise pretty much instantly have a solution. I Check the web/manuals/docs/source code for missing information so I can refine the solution from a hunch to an implementation plan. This can be pretty fast or can be the slowest part. I start coding, building a small subset that work and iteratively adding on top, feeling the design as I go, refactoring if necessary. Then after testing, I send it to review.
The "finding information" part is the most important one as accuracy is paramount. And for most AI workflows, it seems that's very much an afterthought.
The "coding" part is the relaxing one, except for a few moments where some nuggets of information are lies or misleading. Again, there's no practice to catch those in AI workflows.
If you have a good testing methodology in place, the last part can be fast tracked, where you mostly scanning for bad practices and modifications to important areas. Again in AI workflows, you see that either they rely on preexisting test suites (the big rewrites), or mostly trust the generated suite with no evidence that it's actually suitable.
The questions I have are: How do you ensure the accuracy of the software's model of the domain? And What do you do to retain the knowledge of that model (as in you have a good intuition of the current behavior of the software or at least can easily locate the code responsible)?
Tell us why.
http://tired.com
One could hope that the author is making a meta-point.
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.
Thanks Claude.
Turns out the human reading this is tired, too
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
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".
Like, they want to professionnaly, kill you. Theh are as much as a tool as is a cord pending from the ceiling
> with my colleague Douwe
Wait, meltano Douwe? Small world. Glad to see you're doing well. I always liked meltano.
> In an era when anyone can produce reasonable-looking UI
Identical looking slop? Every Claude-based vibe coded app looks identical.
> The fear of skill rot is legitimate. And the fear that if you don't go fast enough you'll be left behind is — while often overstated — not entirely unfounded.
You know what, that's OK. I just hit "OK" on LLM Scala code I _actually_ think is awful. It works. It's probably faster than the "pure" code I'd write by hand. The code I would write - as a FP and Scala/Elm/Haskell/... enjoyer - would actually be maintainable for humans, but LLMs struggle with it. But LLMs writing code for LLMs? Sure, have at it. Objectively lower barrier of entry.
> So if you're feeling overwhelmed, destabilized, simultaneously more productive and less happy, know that you're not alone.
But yes, I am indeed simultaneously more productive and less happy.
https://skaldmaps.com, my little side project, was only possible _because_ I was able to feed my real world knowledge about real estate, combined with GIS and SWE knowledge into various torment nexus... pardon me, LLM prompts.
Since I don't have the _time_ to write boilerplate react code (it's pepper and tomato season in Georgia, which _actually_ brings me joy), telling Claude/Codex/... how to write dbt models saves me time and I objectively get a lot more done, but it's not fun.
I guess that's also why I still enjoy blogging. You can't use LLMs for blogs without people noticing immediately. Shameless plug: https://chollinger.com/blog/
Enjoy my entirely human typos, since that's clearly rare these days.
I 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.
Annnnnd TFA is written by AI. I want to get off Mr. Bones' Wild Ride.
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 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.
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.
If it weren't claudeslop, it would still have to be marketing corposlop.
What used to tire me: being forced to have a sharp eye for syntax errors when programming, or simply the effort of all the typing and navigating through source files. Trying to visualize details of the codebase I was changing, while at the same time keeping a high level picture in my head of the feature I was changing.
With AI, I can focus on the high level picture. I can focus on the steps to get there and the steps to verify that it works. I don't have to focus on syntax anymore and there is much less need to visualize large parts of my code base. With AI, work is still tiring but much less, and in a different way.
In return, there is not much of mastery anymore. Being a craftsman is a deeply human desire that AI is destroying, not sure if this is a fun future to look forward to.
> Being a craftsman is a deeply human desire that AI is destroying, not sure if this is a fun future to look forward to.
AI is giving me back the feeling I had when I first learned to program, when I was 14. At 14, I suddenly had a tool in my hands that was like an extension of my imagination. I could create tools, games and what not with it, this is what I loved. AI is that same tool on steroids. If what you like is creating things, AI lets you do it at 10 times the speed.
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.