Some people love programming, for the sake of programming itself. They love the CS theory, they love the tooling, they love most everything about it.
Other people see all that as an means to an end - and find no joy from the technical aspect of creating something. They're more interested in the end result / product, rather than the process itself.
I think that if you're in group A, it can be difficult to understand group B. In vice versa.
I'm a musician, so I love everything about creating music. From the theory, to the mastery of the instrument, the tens of thousands of hours I've poured into it...finally being able to play something I never thought I'd be able to, just by sheer willpower and practice. Coming up with melodies that feel something to me, or I can relate to something.
On the other hand, I know people that want to jump straight to the end result. They have some melody or idea in their head, and they just want to generate some song that revolves around that idea.
I don't really look down on those people, even though the snobs might argue that they're not "real musicians". I don't understand them, but that's not really something I have to understand either.
So I think there are a lot of devs these days, that have been honing their skills and love for the craft for years, that don't understand why people just want things to be generated, with no effort.
I think it's worth pointing out that most people are both these things at different times.
There's things I care about and want a deep understanding of but there's plenty of tasks I want to just "go away". If I had an junior coder - I'd be delegating these. Instead I use AI when I can.
There's also tasks where I want a jump start. I prefer fixing/improving code over writing from scratch so often a bad AI attempt is still valuable to me.
i mean how far are you willing to take that argument? every decade has just been a new abstraction, imagine people flipping switches or in raw assembly talking about how they don't "understand" you now with your no effort. or even those who don't "understand" why you use your autocomplete and fancy IDE, preferring a simple text editor.
i say this as someone who cut my teeth on this stuff growing up and seeing the evolution, it's both. and at some point it's honestly elitism and gatekeeping. i sort of cringe when it's called a "craft" because it's not like woodworking or something. the process is both full of joy but so is the end result, and the nature of our industry is that the process is ALWAYS changing.
you accumulate a depth of knowledge and watch as it washes away in a few years. that kind of change, and the big kind of change that AI brings scares people so they start clinging to it like it's some kind of centuries old trade lol.
I have actually had some really great flow evenings lately, the likes of which I have not enjoyed in many years, precisely because of AI-assisted coding. The trick is to break the task down in to components that are of moderate complexity so that the AI can handle them (Gemini 2.5 Pro one-shots), and keep your mind on the high-level design which today's AI cannot coordinate.
What helps me is to think of it like I'm a kid again, learning to code full of ideas but without any pre-conceived notions. Rather than the Microsoft QuickBasic manual in my hands, I've got Gemini & Claude Code. I would be gleefully coding up a storm of games, websites, dubious webcrawlers, robots, and lord knows what else. Plenty of flow to be had.
Added joy for me as well mostly by giving me the relevant API calls I need straight away, from publically available documentation, instead of having to read docs myself. "How do I do X in Y"
And if something's not obvious I can always fetch the specifics of any particular calls. But at least I didn't have to find the name of that call in the first place.
This comment section really shows the stark divide between people who love coding and thus hate AI, and people who hate coding and thus love AI.
Honestly, I suspect the people who would prefer to have someone or something else do their coding, are probably the devs who are already outputting the worst code right now.
> This comment section really shows the stark divide between people who love singing and thus hate AI-assisted singing, and people who hate singing and thus love AI-assisted singing.
> Honestly, I suspect the people who would prefer to have someone or something else do their singing, are probably the singers who are already outputting the worst singing right now.
The point is: just because you love something, doesn't mean you're good at it. It is of course positively correlated with it. I am in fact a better singer because I love to sing compared to if I never practiced. But I am not a good singer, I am mediocre at best (I chose this example for a reason, I love singing as well as coding! :-D)
And while it is easier to become good at coding than at singing - for professional purposes at least - I believe that the effect still holds.
I think the analogy/ substitution falls apart in that singing is generally not very stable or lucrative (for 99.999% of singers), so it is pretty rare to find someone singing who hates it. Much less uncommon to find people working in IT who hate the specific work of their jobs.
And I think we do tend to (rightfully) look down on e.g. singers who lip-sync concerts or use autotune to sing at pitches they otherwise can't, nevermind how we'd react if one used AI singing instead of themselves.
Yes, loving something is no guarantee of skill at it, but hating something is very likely to correspond to not being good at it, since skills take time and dedication to hone. Being bad at something is the default state.
I love coding - but I am not very good at it. I can describe what I want in great detail, with great specificity. But I am not personally very good at turning that detailed specification into the proper syntax and incantations.
AI is like jet fuel for me. It’s the translation layer between specs and code I’ve always wanted. It’s a great advisor for implementation strategies. It’s a way to try new strategies in code quickly.
I don’t need to get anyone else to review my code. Most of this is for personal projects.
I don’t really write professionally, so I don’t have a ton of need for it to manage realities of software engineering (large codebases, peer reviews, black box internal systems, etc). That being said - I do a reasonable amount of embedded Linux work, and AI understands the Linux kernel and device drivers very well.
To extend your metaphor: AI is like a magic microphone that makes all of my singing sound like Tony Rice, my personal favorite singer. I’ve always wanted to sound like him - but I never will. I don’t have the range or the training. But AI allows my coding level to get to that corresponding level with writing software.
Right, just how back in the day, people who loved writing assembly hated high level languages and people who found assembly too tedious loved compilers.
What if I prefer to have a clone of me doing my coding, and then I throw my clone under the bus and start to (angrily) hyperfocus explore and change every piece to be beautiful? Does this mean I love coding or I hate coding?
It's definitely a personality thing, but that's so much more productive for me, than convincing myself to do all the work from scratch after I had a design.
I guess this means I hate coding, and I only love the dopamine from designing and polishing my work instead of making things work. I'm not sure though, this feels like the opposite of hate coding.
It is absolutely possible to enjoy both- I have used LLMs to generate code for ideas about alternate paths to take when I write my code- but prompt generation is not coding, and there are WAY too many people who claim to be coding when they have in fact done nothing of the sort.
> a far higher intensity
I'm not sure what this is supposed to mean. The code that I've gotten is riddled with mistakes and fabrications. If I were to use it directly, it would significantly slow my pace. Likewise, when I use LLMs to offer alternative methods to accomplish something, I have to take the time to sit down and understand what they're proposing, how to actually make it work, and whether that route(s) would be better than my original idea. That is a significant speed reduction.
The only way I can imagine LLMs resulting in "far higher intensity" is if I was just yolo'ing the code into my program, and then doing frantic integration, correction, and bugfix work afterwards.
Sure, that's "higher intensity", but that's just working harder and not smarter.
yeah i definitely enjoy the craft and love of writing boilerplate or manually correcting simple errors or looking up functions /s. i hate how it's even divided into "two camps", it's more like a big venn diagram.
Who write boilerplate this day? I just lift the code from the examples in the docs (especially css frameworks). And I love looking at functions docs, because after doing it a few times, you develop an holistic understanding of the library and your speed increases. Kinda like learning a foreign language. You can use an app to translate everything, or asks for the correct word when the needs arises. The latter is a bit frustrating at the beginning, but that’s the only way to become fluent.
Every PR I have to review with an obviously LLM-generated title stuffed with adjectives, and a useless description containing an inaccurate summary of the code changes pushes me a little bit more into trying to make my side projects profitable in the hope that one takes off. It usually only gets worse from there.
Documentation needs to be by humans for humans, it's not a box that's there to be filled with slop.
> The actual documentation needs to be by humans for humans.
This is true for producing the documentation but if there is an LLM that can take said documentation and answer questions about it is a great tool. I think I get the answer far quicker with LLM than sifting through documentation when looking for existence of a function in a library or a property on an object.
I think that comment is conflating 2 different things: 1) people like you and I who use LLMs for exploring alternative methods to our own, and 2) people who treat LLMs like Stack Overflow answers they don't understand but trust because it's on SO.
Yes, there are tasks or parts of the code that I'm less interested in, and would happily either delegate or negotiate-off to someone else, but I wouldn't give those to a writer who happens to be able to write in a way that approximates program code, I'd give them to another dev on the team. A junior dev gets junior dev tasks, not tasks that they don't have the skills to actually perform, and LLMs aren't even at an actual junior dev level, imhe.
I noted in another comment that I've also used LLMs to get ideas for alternate ways to implement something, or to as you said "jump start" new files or programs. I'm usually not actually pasting that code into my IDE, though- I've tried that, and the work to make LLM-generated code fit into my programs is way more than just writing out the bits I need, where I need. That is clearly not the case for a lot of people using LLMs, though.
I've seen devs submitting PRs with giant blocks of clearly LLM-gen'd code, that they've tried to monkey-wrench into working with the rest of the program (often breaking conventions or secure coding standards). And these aren't junior devs, they're devs that have been working here for years and years.
When you force them to do a code review, they know it's not up to par, but there is a weird attitude that LLM-gen'd code is more acceptable to be submitted with issues than personally-written code. As though it's the LLM's fault or job to fix, even though they prompted and copied and badly-integrated and PR'd it.
And that's where I think there is a stark divide. I think you're on my side of the divide (at least, I didn't get the impression that you hate coding), it just sounds like you haven't really seen the other side.
My personal dime-store psych theory is that it's the same mental mechanism that non-technical computer users fall into of improperly trusting/ believing computers to produce correct information, but now happening to otherwise technical folks too because "AI" is still a black box technology to most of us, like computers in general are to non-techies.
LLMs are really really cool, and really really impressive to me, and I've had 'wow' moments where they did something that makes you forget what they are and how they work, but you can't let that emotional reaction towards it override the part that knows it's just a token chain. When you do, people end up (obviously on the very extreme end) 'dating' them, letting them make consequential "decisions", or just over-trusting their output/code.
I like solving problems but I hate coding. Wasting 20 minutes because you forgot a semicolon or something is not fun. AI let's me focus on the problem and not bother with the tedious coding bit.
If you're using those things to do *the core function* of the program you're writing, that's an issue.
SDKs and libraries are there to provide common (as in, used repeatedly, by many) functions that serve as BUILDING BLOCKS.
If you import a library and now your program is complete, then you didn't actually make a useful program, you just made a likely less efficient interface for the library.
BUT ALSO-
SDKs and libraries are *vetted* code. The advantage you are getting isn't just about it having been written for you, it's about the hundreds of hours of human code review, iteration, and thought, that goes into those libraries.
LLM code doesn't have that, so it's not about you benefitting from the knowledge and experience of others, it's purely about reducing personally-typed LoC.
And yes, if you're wholesale copy-pasting major portions of your program from stack overflow, I'd say that's about as bad as copy-pasting from ChatGPT.
No, problem is when others are no longer needed, a machine gets to do everything, and only a few selected humans get to take care of the replicator machine.
People aren't taking LLM code and then thoughtfully refactoring and improving it, they're using it to *avoid* doing that, by treating the generated code as though it's already had that done.
That's why the pro-LLM-code people in this very thread are talking about using it to automate away the parts of the coding they don't like. You really think they're then going to go back and improve on the code past it minimally working?
There will be no advancement from that, just mediocre or bad code going unreviewed and ignored until it breaks.
There's nothing stopping you from coding if you enjoy it. It's not like they have taken away your keyboard. I have found that AI frees me up to focus on the parts of coding I'm actually interested in, which is maybe 5-10% of the project. The rest is boiler plate, cargo-culted, Dockerfile, build system and bash environment variable passing circle of hell that I really could care less about. I care about certain things that I know will make the product better, and achieve its goals in a clever and satisfying way.
Even when I'm stuck in hell, fighting the latest undocumented change in some obscure library or other grey-bearded creation, the LLM, although not always right, is there for me to talk to, when before I'd often have no one. It doesn't judge or sneer at you, or tell you to "RTFM". It's better than any human help, even if its not always right because its at least always more reliable and you don't have to bother some grey beard who probably hates you anyway.
> The rest is boiler plate, cargo-culted, Dockerfile, build system and bash environment variable passing circle of hell that I really could care less about.
Even more so, I remember making a Chrome extension and feeling intimidated. I knew that I'd be comfortable with most of it given that JS is used but I just didn't know how to start.
With an LLM it is way faster to spin up some default config and get going versus reading a tutorial. What I've noticed in that respect is that I just read what it does and then immediately reason why it's there. "Oh, there's a manifest.json file with permissions and a few other things, fair, makes sense. Oh, so you have the HTML/CSS/JS of the extension, you have the HTML/CSS/JS of the page you're injecting some code into and you have the JS of a background worker. Ah yea, I get that."
I think the fear for those of us who love coding, stability and security, that we are going to be confronted with apples that are rotten on the inside and our work, our love, is going to turn (even more so) into pain. The challenge in computing is that the powers that decide have little overview over the actual quality and longevity of any endeavour.
I work as a consultant assessing other people's code and it's hard not to lose my religion, sort of speak.
> doesn't judge or sneer at you, or tell you to "RTFM". It's better than any human help, even if its not always right because its at least always more reliable and you don't have to bother some grey beard who probably hates you anyway.
Like many others writing here, I enjoy coding (well, mostly anyway), especially the when it requires deep thought and patient experimentation to get anywhere. It's also great to preside over finally wiring together the routines (modules, libraries) that bind a project into a coherent whole.
Haven't much used AI to assist. After all, hard enough finding authentic humans capable and willing to voluntarily review/critique one's code. So far AI doesn't consistently provide that kind of help. OTOH seems almost certain over time AI systems will improve in terms of specific and comprehensive "insights" into the particular types of code one is writing.
I think an issue is that human creativity is hard to measure. Likely enough AI is even tougher to assess. Probably AI will increasingly be assigned tasks like constructing project skeletons, assuring parts can be joined together without undue strain, handling "boilerplate" and other routine chores. To be sure the landscape will look different in 50 years, I'm certain we'd be amazed were we able to see what future systems will be doing.
In any case, we shouldn't hesitate to use tools that genuinely boost our creativity. One badly needed role would be enabling development of higher reliability software. Still that's a far cry from the contributions emanating from the best of human originality, talent and motivation.
So much this. The AI takes care of the tedious line by line what’s-the-name-of-that-stdlib-function parts (and most of the tedious test-writing parts) and lets me focus on the interesting bits like what it is I want to build and how the pieces should fit together. And debugging, which I find satisfying.
Sadly, I find it sorely lacking at dealing with build systems and that particular type of boilerplate, mostly because it seems to mix up different versions of things too much and gives you totally broken setups more often than not. I’d just as soon never deal with the he’ll that is front end build/lint/test config again.
No, because it's usually a few years old and already obsolete - the frameworks and the language have gone through a gazillion changes and what you did in 2021 suddenly no longer works at all.
I keep seeing that suggestion as well and the only sensible way I see would be to use one off boilerplate, anything else does not make sense.
If you keep re-using boilerplate once in a while copying it from elsewhere is fine. If you re-use it all the time, just get a macro setup in your editor of choice. IMHO that is way more efficient than asking AI to produce somewhat consistent boilerplate
They perhaps haven’t taken away your keyboard but anecdotally, a few friends work at places where their boss is requiring them to use the LLMs. So you may not have to code with them but some people are starting to be chained to them.
Yes, there are bad places to work. There are also places that require detailed time tracking, do not allow any time to write tests, have very long hours, tons of on-call alerts, etc.
Frankly I don't want to spend 2 hours reading documentation just to find out some arcane incantation that gets the computer to do what I want it to do.
The interesting part of programming to me is designing the logic. It's the 'this, then that, except when this' flow that I'm really interested in, not the search for some obscure library that has some function that will parse this csv.
Llms are great for that, and let me get away from the pointless grind and into the things that I enjoy and are actually providing value.
The pair programming is also a super good thing. I work best when I can spitball and throw out random ideas and get quick feedback. Llms let me do that without bothering others who have their own work to do.
Of course, it all depends how you use the LLM. While the same can be true for StackOverflow, the LLMs just scale the issues up.
> The rest is boiler plate, cargo-culted, Dockerfile, build system and bash environment variable passing circle of hell that I really could care less about.
Except you do care. It's why you're frustrated and annoyed. And good!!! That feeling is because what you're describing requires solving. If something is routine, automate it. But it's really not good to automate in a statistical way, especially when that statistical tool is optimized for human preference. Because remember that also means mistakes are optimized to be missed by humans.[0]
With expertise in anything, I'm sorry, but you also got to do the shit work. To be a great musician you gotta practice boring scales. It's true even if you just want to be a sub par one.
But a little grumpy is good. It drives you to fix things, and frankly, that's our job. The things that are annoying and creating friction don't need be repeated over and over, they need alternative solutions. The scripts you build are valuable. The "useless" knowledge you gain isn't so useless. Those little details add up without you knowing and make you better.
That undocumented code makes you frustrated and reminds you to document your own. You don't want to be a hypocrite. The author of the thing you're using probably thought the same thing: "No one is gonna use this garbage, I'm not going to waste my time documenting it". Yet here we are. Over and over again yet we don't learn the lesson.
I'm not gonna deny there's assholes. There are. But even assholes teach you. At worst, they teach you how not to act.
And some people are you telling you to RTM and not RTFM. Sure, it has lots of extra information in it that you don't need to get your specific job done, but have you also considered that it has lots of extra information in it? The person that wrote it clearly thought the context was important. Maybe it isn't. In that case, you learned a lesson in how not to write documentation!
What I'm getting at is that there's a lot of learning done all over the place. Trying to take out all the work and only have "the fun" is harming yourself and has a large potential to make less time for the fun stuff[0]. I'd be surprised if I'm alone in this, but a lot of stuff I enjoy now was stuff that originally frustrated me. IME this is pretty common! It's true for every person I know. Similarly, it's also true for things I learned that I thought I'd never use again. It always has a way of coming back.
I'm not going to pretend it's all fun and games. I'm explicitly saying it's not. But I'm confident in the long run it's better. Despite the lack of accuracy, I use LLMs (and Google, and even the TFM) like I would a solution guide the homework problems when I was in school. Try first, then consult. The struggle is an investment in your future. It sucks, but if all the best things in life were easy then we'd all have them. I'm just trying to convince you that it pays off.
I'm completely aware this is all context dependent. There's a time and place for everything. But given the percentages you mention (even taken as exaggeration), something sounds wrong. It's hard to suggest specific solutions without details but I'd be surprised if there weren't better and more rewarding solutions than having the LLM do it for you
[0] That's the big danger and what drives distrust in them. Because you need to work extra hard to find mistakes, increasing workload, not decreasing, because debugging is most of the job!
After all, if we lose the joy in our craft, what exactly are we optimizing for?
Solving problems for real people. Isn't the answer here kind of obvious?
Our field has a whole ethos of open-source side projects people do for love and enjoyment. In the same way that you might spend your weekends in a basement woodworking shop without furnishing your entire house by hand, I think the craft of programming will be just fine.
> Solving problems for real people. Isn't the answer here kind of obvious?
No. There are a thousand other ways of solving problems for real people, so that doesn't explain why some choose software development as their preferred method.
Presumably, the reason for choosing software development as the method of solving problems for people is because software development itself brings joy. Different people find joy in different aspects even of that, though.
For my part, the stuff that AI is promising to automate away is much of the stuff that I enjoy about software development. If I don't get to do that, that would turn my career into miserable drudgery.
Perhaps that's the future, though. I hope not, but if it is, then I need to face up to the truth that there is no role for me in the industry anymore. That would pretty much be a life crisis, as I'd have to find and train for something else.
> That would pretty much be a life crisis, as I'd have to find and train for something else.
There's inertia in the industry. It's not like what you're describing could happen in the blink of an eye. You may well be at the end of your career when this prophecy is fulfilled, if it ever comes true. I sure will be at the end of mine and I'll probably work for at least another 20 years.
"There are a thousand other ways of solving problems for real people, so that doesn't explain why some choose software development as their preferred method."
Software development is almost unique in the scale that it operates at. I can write code once and have it solve problems for dozens, hundreds, thousands or even millions of people.
If you want your work to solve problems for large numbers of people I have trouble thinking of any other form of work that's this accessible but allows you to help this many others.
Fields like civil engineering are a lot harder to break into!
> No. There are a thousand other ways of solving problems for real people, so that doesn't explain why some choose software development as their preferred method.
I don't see why we should seek an explanation if there are thousands of ways to be useful to people. Is being a lawyer particularly better than being an accountant?
I'm probably just not as smart or creative as you, but say my problem is I have a ski cabin that I want to rent it to strangers for money. Nevermind a thousand, What are 100 ways without using software that I could do something about that, vs listing it on Airbnb?
Same as when higher-level languages replaced assembly for a lot of use cases. And btw, at least in places I've worked, better traditional tooling would replace a lot more headcount than AI would.
I already see this happening with low code, SaaS and MACH architectures.
What used to be a project doing a CMS backend, now is spent doing configurations on a SaaS product, and if we are lucky, a few containers/serveless for integrations.
There are already AI based products that can automate those integrations if given enough data samples.
Many believe AI will keep using current programming languages as translation step, just like those Assembly developers thought compiling via Assembly text generation and feeding into an Assembly would still be around.
> Solving problems for real people. Isn't the answer here kind of obvious?
Look at the majority of the tech sector for the last ten years or so and tell me this answer again.
Like I guess this is kind of true, if "problems for real people" equals "compensating for inefficiencies in our system for people with money" and "solutions" equals "making a poor person do it for them and paying them as little as legally possible."
Those of us who write software professionally are literally in a field premised on automating other people's jobs away. There is no profession with less claim to the moral high ground of worker rights than ours.
solving real problems is the core of it, but for a lot of people the joy and meaning come from how they solve them too. the shift to AI tools might feel like outsourcing the interesting part, even if the outcome is still useful. side projects will stick around for sure, but i think it's fair to ask what the day-to-day feels like when more of it becomes reviewing and prompting rather than building.
> After all, if we lose the joy in our craft, what exactly are we optimizing for?
For being one of the few lucky ones that gets to stay around taking care of the software factory robots, or designing them, while everyone else that used to work at the factory is now queueing somewhere else.
For me the most surprising part is the phase of wonder, from those that apparently never read anything in the history of industrial revolution, and think everyone will still have a place when we achieve Star Trek replicator level.
In my case, I couldn't agree more, with the premise of the article, but my life today, is centered around writing software the very best that I can; regardless of value or price.
It's not very effective, if I were to be trying to make a profit.
It's really hard to argue for something, if the something doesn't result in value, as perceived by others.
For me, the value is the process. I often walk away from my work, once I have it up and shipping. I do like to take my work all the way through shipping, support, and maintenance, but find that my eye is always drawn towards new shores[0].
“A ship in harbor is safe, but that is not what ships are built for.”
–John A. Shedd
I am mostly pretty underwhelmed with LLMs' code, but this is a use-case that makes perfect sense to me, and seems like a net-positive: using them as a reference manual/ translator/ training aid.
I just wish I saw more people doing this, rather than asking them to 'draw 80% of the owl'.
The author is already an experienced programmer. Let me toss in an anecdote about the next generation of programmers. Vibe coding: also called playing pinball with the AI, hoping something useful comes out.
I taught a lecture in my first-semester programming course yesterday. This is in a program for older students, mostly working while going back to school. Each time, a few students are selected to present their code for an exercise that I pick randomly from those they were assigned.
This guy had fancy slides showing his code, but he was basically just reading the code off the page. So I ask him: “hey, that method you call, what exactly does it do?”.
Um…
So I ask "Ok, the result from that method is assigned to a variable. What kind of variable is it?" Note that this is Java, the data type is explicitly declared, so the answer is sitting there on his slide.
Um…
So I tear into him. You got this from ChatGPT. That’s fine, if you need the help, but you need to understand what you get. Otherwise you’ll never get a job in IT.
His answer: “I already have a job in IT.”
Fsck. There is your vibe coder. You really do not want them working on anything that you care about.
Does your course not have exams or in-lab assignments? Should sort itself out. Honestly, I'm all for homework fading away as professors can't figure out how to prevent people from using AI. It used to be the case that certain kids could get away with not doing much because they were popular enough to get people to let them copy their assignments (at least for certain subjects). Eventually the system will realize they can't detect AI and everything has to be in-person.
Sure, this guy is likely to fail the course. The point is: he is already working in the field. I don't know his exact job, but if it involves programming, or even scripting, he is faking his way with AI, not understanding what he's doing. That is frightening.
This is one of the biggest dangers imo. While I agree with the OP about the deflation of joy in experienced programmers, the related but more consequential effect seems to be dissuading people from learning. A generational threat to collective competence and a disservice to students and teachers everywhere
Can't relate at all. I've never had so much fun programming as I have now. All the boring and tedious parts are gone and I can finally focus on the code I love to write.
I don't know man, maybe prompt most of your work, eyeball it and verify it rigorously (which if you cannot do, you should absolutely never touch an LLM!), run a script to commit and push after 3 hours and then... work on whatever code makes you happy without using an LLM?
Let's stop pretending or denying it: most of us would delegate our work code to somebody else or something else if we could.
Still, prompting LLMs well requires eloquence and expressiveness that many programmers don't have. I have started deriving a lot of value from those LLMs I chose to interact with by specifying clear boundaries on what's the priority and what can wait for later and what should be completely ignored due to this or that objective (and a number of other parameters I am giving them). When you do that well, they are extremely useful.
> most of us would delegate our work code to somebody else or something else if we could.
I saw your objections to other comments on the basis of them seemingly not having a disdainful attitude towards coding they do for work, specifically.
I absolutely do have tasks, coding included, that I don't want to do, and find no joy in. If I can have my manager assign the task to someone else, great! But using an LLM isn't that, so I'm still on the hook for ensuring all the most boring parts of that task (bugfixing, reworks, integration, tests, etc) get done.
My experience with LLMs is that they simply shift the division of time away from coding, and towards all the other bits.
And it can't possibly just be about prompting. How many hundreds of lines of prompting would you need to get an LLM to understand your coding conventions, security baselines, documentation reqs, logging, tests, allowed libraries, OSS license restrictions (i.e. disallowed libraries), etc? Or are you just refactoring for all that afterwards?
Maybe you work somewhere that doesn't require that level of rigor, but that doesn't strike me as a good thing to be entrenching in the industry by increasing coders' reliance on LLMs.
A super necessary context here is that I barely use LLM at all still. Maybe I should have said so but I figured that too much nuance would ruin a top-level comment and mostly casually commented on a tradeoff of using or not using LLMs.
Where I use LLMs:
1. Super boring and annoying tasks. Yes, my prompts for those include various coding style instructions, requests for small clarifying comments where the goal of the code is not obvious, tests. So, no OSS license restrictions. Libraries I specify most of the times I used LLMs (and only once did I ask it to suggest a library). Logging and telemetry I add myself. So long story short, I use the LLM to show me a draft of a solution and then mercilessly refactor it to match my practices and guidelines. I don't do 50 exchanges out of laziness, no.
2. Tasks where my expertise is lacking. I recently used an LLM to help me with making a `.clone()`-heavy Rust code to become nearly zero-copy for performance reasons -- it is a code on a hot path. As much as I love Rust and I am fairly good at it (realistically I'm IMO at 7.5 / 10), all the lifetimes and zero-copy semantics I still don't know yet. A long session with an LLM after, I emerged both better educated and with a faster code. IMO a win-win.
I see this "prompting is an art" stuff a lot. I gave Claude a list of 10 <Route> objects and asked it to make an adjustment to all of them. It gave me 9 back. When I asked it to try again it gave me 10 but one didn't work. What's "prompt engineering" there, telling it to try again until it gets it right? I'd rather just do it right the first time.
I am also barely using LLMs at the moment. Even 10% of the time would be generous.
What I was saying is that I have tried different ways of interacting with LLMs and was happy to discover that the way I describe stuff to another senior dev actually works quite fine with an LLM. So I stuck to that.
Again, if an LLM is not up to your task, don't waste your time with it. I am not advocating for "forget everything you knew and just go ask Mr. AI". I am advocating for enabling and productivity-boosting. Some tasks I hate, for some I lack the deeper expertise, others are just verbose and require a ton of typing. If you can prompt the LLM well and vet the code yourself after (something many commenters here deliberately omit so they can happily tear down their straw man) then the LLM will be a net positive.
It's one more tool in the box. That's all there is to it really. No idea why people get so polarizing.
Prompt engineering is just trying that task on a variety of models and prompt variations until you can better understand the syntax needed to get the desired outcome, if the desired outcome can be gotten.
Honestly you’re trying to prove AI is ineffective by telling us it didn’t work with your ineffective protocol. That is not a strong argument.
Nice. I've got a whole lot of magical things that I need built for my day job. Want to connect so I can hand the work over to you? I'll still collect the paychecks, but you can have the joy. :)
> Let's stop pretending or denying it: most of us would delegate our work code to somebody else or something else if we could.
I don’t think this is the case, if anything the opposite is true. Most of us would like to do the work code but have realized, at some career point, that you’re paid more to abstract yourself away from that and get others to do it either in technical leadership or management.
> I don’t think this is the case, if anything the opposite is true
I'll be a radical and say that I think it depends and is very subjective.
Author above you seems to enjoy working on code by itself. You seem to have a different motivation. My motivation is solving problems I encounter, code just happen to be one way out of many possible ones. The author of the submission article seems to love the craft of programming in itself, maybe the problem itself doesn't even matter. Some people program just for the money, and so on.
Well, does not help that a lot of work tasks are meaningless drudgery that we collectively should have trivialized and 100% automated at least 20 years. That was kind of the core my point: a lot of work tasks are just plain BS.
I wouldn't, I got into software exactly because I enjoy solving problems and writing code. Verifying shitty, mindless, computer generated code is not something I would consider doing for all the money in the world.
1. I work on enjoyable problems after I let the LLM do some of the tasks I have to do for money. The LLM frees me bandwidth for the stuff I truly love. I adore solving problems with code and that's not going to change ever.
2. Some of the modern LLMs generate very impressive code. Variables caching values that are reused several times, utility functions, even closure helpers scoped to a single function. I agree that when the LLM code's quality falls bellow a certain threshold then it's better in every way to just write it yourself instead.
Needlessly polarizing. I love coding since 12 years old (so more than 30 years at this point) but most work tasks I'm given are fairly boring and uninteresting and don't move almost any science or knowledge forward.
Delegating part of that to an LLM so I can code the stuff I love is a big win for my motivation and is making me doing the work tasks with a bit more desire and pleasure.
Please don't forget that most of us out there can't code for money anything that their heart wants. If you can, I'd be happy for you (and envious) but please understand that's also a fairly privileged life you'd be having in that case.
Totally. And yet rigorous proof is very difficult. Having done some mathematics involving nontrivial proofs, I respect even more how difficult rigor is.
Absolutely. That's why I don't give the LLM the reins for long, nor do I tell it to do the whole thing. I want to keep my mind sharp and my abilities honed.
> Still, prompting LLMs well requires eloquence and expressiveness that many programmers don't have
It requires magical incantations that may or may not work and where a missing comma in a prompt can break the output just as badly as the US waking up and draining compute resources.
> work on whatever code makes you happy without using an LLM?
This isn't how it works, psychologically. The whole time I'm manual coding, I'm wondering if it'd be "easier" to start prompting. I keep thinking about a passage from The Road To Wigan Pier where Orwell addresses this effect as it related to the industrial revolution:
>Mechanize the world as fully as it might be mechanized, and whichever way you turn there will be some machine cutting you off from the chance of working—that is, of living.
>At a first glance this might not seem to matter. Why should you not get on with your ‘creative work’ and disregard the machines that would do it for you? But it is not so simple as it sounds. Here am I, working eight hours a day in an insurance office; in my spare time I want to do something ‘creative’, so I choose to do a bit of carpentering—to make myself a table, for instance. Notice that from the very start there is a touch of artificiality about the whole business, for the factories can turn me out a far better table than I can make for myself. But even when I get to work on my table, it is not possible for me to feel towards it as the cabinet-maker of a hundred years ago felt towards his table, still less as Robinson Crusoe felt towards his. For before I start, most of the work has already been done for me by machinery. The tools I use demand the minimum of skill. I can get, for instance, planes which will cut out any moulding; the cabinet-maker of a hundred years ago would have had to do the work with chisel and gouge, which demanded real skill of eye and hand. The boards I buy are ready planed and the legs are ready turned by the lathe. I can even go to the wood-shop and buy all the parts of the table ready-made and only needing to be fitted together; my work being reduced to driving in a few pegs and using a piece of sandpaper. And if this is so at present, in the mechanized future it will be enormously more so. With the tools and materials available then, there will be no possibility of mistake, hence no room for skill. Making a table will be easier and duller than peeling a potato. In such circumstances it is nonsense to talk of ‘creative work’. In any case the arts of the hand (which have got to be transmitted by apprenticeship) would long since have disappeared. Some of them have disappeared already, under the competition of the machine. Look round any country churchyard and see whether you can find a decently-cut tombstone later than 1820. The art, or rather the craft, of stonework has died out so completely that it would take centuries to revive it.
>But it may be said, why not retain the machine and retain ‘creative work’? Why not cultivate anachronisms as a spare-time hobby? Many people have played with this idea; it seems to solve with such beautiful ease the problems set by the machine. The citizen of Utopia, we are told, coming home from his daily two hours of turning a handle in the tomato-canning factory, will deliberately revert to a more primitive way of life and solace his creative instincts with a bit of fretwork, pottery-glazing, or handloom-weaving. And why is this picture an absurdity—as it is, of course? Because of a principle that is not always recognized, though always acted upon: that so long as the machine is there, one is under an obligation to use it. No one draws water from the well when he can turn on the tap. One sees a good illustration of this in the matter of travel. Everyone who has travelled by primitive methods in an undeveloped country knows that the difference between that kind of travel and modern travel in trains, cars, etc., is the difference between life and death. The nomad who walks or rides, with his baggage stowed on a camel or an ox-cart, may suffer every kind of discomfort, but at least he is living while he is travelling; whereas for the passenger in an express train or a luxury liner his journey is an interregnum, a kind of temporary death. And yet so long as the railways exist, one has got to travel by train—or by car or aeroplane. Here am I, forty miles from London. When I want to go up to London why do I not pack my luggage on to a mule and set out on foot, making a two days of it? Because, with the Green Line buses whizzing past me every ten minutes, such a journey would be intolerably irksome. In order that one may enjoy primitive methods of travel, it is necessary that no other method should be available. No human being ever wants to do anything in a more cumbrous way than is necessary. Hence the absurdity of that picture of Utopians saving their souls with fretwork. In a world where everything could be done by machinery, everything would be done by machinery. Deliberately to revert to primitive methods to use archaic took, to put silly little difficulties in your own way, would be a piece of dilettantism, of pretty-pretty arty and craftiness. It would be like solemnly sitting down to eat your dinner with stone implements. Revert to handwork in a machine age, and you are back in Ye Olde Tea Shoppe or the Tudor villa with the sham beams tacked to the wall.
>The tendency of mechanical progress, then, is to frustrate the human need for effort and creation. It makes unnecessary and even impossible the activities of the eye and the hand. The apostle of ‘progress’ will sometimes declare that this does not matter, but you can usually drive him into a comer by pointing out the horrible lengths to which the process can be carried.
I've been singin' this song for years. We should return to Small Data. Hand picked, locally sourced, data. Data I can buy at a mom and pop shop. Data I can smell, data I can feel, data I can yearn for.
I’ve been struggling with a very similar feeling. I too am a manager now. Back in the day there was something very fulfilling about fully understanding and comprehending your solution. I find now with AI tools I don’t need to understand a lot. I find the job much less fulfilling.
The funny thing is I agree with other comments, it is just kind of like a really good stack overflow. It can’t automate the whole job, not even close, and yet I find the tasks that it cannot automate are so much more boring (the ones I end up doing).
I envy the people who say that AI tools free them up to focus on what they care about. I haven’t been able to achieve this building with ai, if anything it feels like my competence has decreased due to the tools. I’m fairly certain I know how to use the tools well, I just think that I don’t enjoy how the job has evolved.
So long as your experience and skill allows you to produce work of higher quality than average for your industry, then you will always have a job which is to review that average quality work, and surgically correct it when it is wrong.
This has always been true in every craft, and it remains true for programmers in a post LLL world.
Most training data is open source code written by novice to average programmers publishing their first attempts at things and thus LLMS are heavily biased to replicate the naive, slow, insecure code largely uninformed by experience.
Honestly to most programmers early in their career right now, I would suggest spending more time reviewing code, and bugfixes, than writing code. Review is the skillset the industry needs most now.
But you will need to be above average as a software reviewer to be employable. Go out into FOSSland and find a bunch of CVEs, or contribute perf/stability/compat fixes, proving you review and improve things better than existing automated tools.
Trust me, there are bugs -everywhere- if you know how to look for them and proving you can find them is the resume you need now.
The days of anyone that can rub two HTML tags together having a high paying job are over.
> LLMS are heavily biased to replicate the naive, slow, insecure code largely uninformed by experience
The one time i pasted LLM code without reviewing it it belonged on accidentally quadratic.
It was obvious at first read, but probably not for a beginner. The accidental complexity was hidden behind API calls that weren't wrong, just grossly inefficient.
Problem might be, if you lose the "joy" and the "flow" you'll stop caring about things like that. And software is bloated enough already.
When we outsource the parts of programming that used to demand our complete focus and creativity, do we also outsource the opportunity for satisfaction? Can we find the same fulfillment in prompt engineering that we once found in problem-solving through code?
Most of AI-generated programming content I use are comments/explanations for legacy code, closely followed by tailored "getting started" scripts and iterations on visualisation tasks (for shitty school assignments that want my pyplots to look nice). The rest requires an understanding, which AI can help you achieve faster (it's read many a book related to the topic, so it can recall information a lot like an experienced colleague may), but it can't confer capital K Knowledge or understanding upon you. Some of the tasks it performs are grueling, take a lot of time to do manually, and provide little mental stimulation. Some may be described as lobotomizing and (in my opinion) may mentally damage you in the "Jack Torrance typewriter" kinda way.
It makes me able to work on the fun parts of my job which possess the qualities the article applauds.
The post focuses on flow, but depending on what you mean by it, it isn't necessarily a good thing. Trying to solve something almost too difficult usually gets you out of flow. You still need concentration, though.
My main worry about AI is that people just keep using the garbage that exists instead of trying to produce something better, because AI takes away much of the pain of interacting with garbage. But most people are already perfectly fine using garbage, so probably not much will change here.
I think.. based on recent events.. that some of the corporate inefficiencies are very poorly captured. Last year we had an insane project that was thrown at us before end of the year, because, basically, company had a tiff with the vendor and would rather have us spend our time in meetings trying to do what they are doing rather than pay vendor for that thing. From simple money spent perspective, one would think company's simple amoral compass would be a boon.
AI coding is similar. We just had a minor issue with ai generated code that was clearly not vetted as closely as it should have been making output it generated over a couple of months not as accurate as it should be. Obviously, it had to be corrected, then vetted and so on, because there is always time to correct things...
edit: What I am getting at is the old-fashioned, penny smart, but pound foolish.
Funny that I found this article going to hacker news as a pause in my work : I had to chose between using Aider or my brain to code a small algorithmic task, sorting items of a list based on dependences between items written in a YAML file.
Using Aider would probably solve the task in 5 minutes. Coding it in 30 minutes. The former choice would result in more time for other tasks or reading HN or having a hot beverage or walking in the sun. The second would challenge my rusting algorithmic skills and give me a better understanding of what I'm doing for the medium term.
Hard choice. In any case, I have a good salary, even with the latter option I can decide to spend good times.
I've tried getting different AIs to say something meaningful about code, never got anything of value back so far. They can't even manage tab-completion well enough to be worth the validation effort for me.
Yeah I wonder how do the code look after such professional AI development. I tried ChatGPT 1o to ask it about simple C function - what errors are there. It answered only after I directly asked about the aspects I was expecting it to tell about. It means that if I didn't know that the LLM wouldn't tell me...
in the meantime im having lots of fun coding and using AI, reinventing every wheel i can. 0 stress cos i don't do it for money :).
I think a lot of people are having a tantrum because programing is not sexy anymore, its getting easier, the bar is lower now , the quality is awful and nobody cares. its like any other boring soul crushing job.
also if you want to see the real cost (at least part of it) of AI coding or the whole fucked up IT industry, go to any mining town in the global south.
i dont know where you are working, but where I work i cant prompt 90% of my job away using cursor. in fact, I find all of these tools to be more and more useless and our codebase is growing and becoming more complex
based on the current state of AI and the progress im witnessing on a month-by-month basis - my current prediction is there is zero chance AI agents are going to be coding and replacing me in the next few years. if i could short the startups claiming this, I would.
Don't get distracted by claims that AI agents "replace programmers". Those are pure hype.
I'm willing to bet that in a few years most of the developers you know will be using LLMs on a daily basis, and will be more productive because of it (having learned how to use it).
I have the same experience. It‘s basically a better StackOverflow, but just like with SO you have to be very careful about the replies, and also just like SO its utility diminishes as you get more proficient.
As an example, just today I was trying to debug some weird WebSocket behaviour. None of the AI tools could help, not Cursor, not plain old ChatGPT with lots of prompting and careful phrasing of the problem. In fact every LLM I tried (Claude 3.7, GPT o4-mini-high, GPT 4.5) introduced errors into my debugging code.
I’m not saying it will stay this way, just that it’s been my experience.
I still love these tools though. It’s just that I really don’t trust the output, but as inspiration they are phenomenal. Most of the time I just use vanilla ChatGPT though; never had that much luck with Cursor.
Yeah, they're currently horrible at debugging -- there seems to be blind spots they just can't get past so end up running in circles.
A couple days ago I was looking for something to do so gave Claude a paper ("A parsing machine for PEGs") to ask it some questions and instead of answering me it spit out an almost complete implementation. Intrigued, I threw a couple more papers at it ("A Simple Graph-Based Intermediate Representation" && "A Text Pattern-Matching Tool based on Parsing Expression Grammars") where it fleshed out the implementation and, well... color me impressed.
Now, the struggle begins as the thing has to be debugged. With the help of both Claude and Deepseek we got it compiling and passing 2 out of 3 tests which is where they both got stuck. Round and round we go until I, the human who's supposed to be doing no work, figured out that Claude hard coded some values (instead of coding a general solution for all input) which they both missed. In applying ever more and more complicated solutions (to a well solved problem in compiler design) Claude finally broke all debugging output and I don't understand the algorithms enough to go in and debug it myself.
Of course I didn't use any sort of source code management so I could revert to a previous version before it was broken beyond all fixing...
Honestly, I don't even consider this a failure. I learned a lot more on what they are capable of and now know that you have to give them problems in smaller sections where they don't have to figure out the complexities of how a few different algorithms interact with each other. With this new knowledge in hand I started on what I originally intended to do before I got distracted with Claude's code solution to a simple question.
--edit--
Oh, the irony...
After typing this out and making an espresso I figured out the problem Claude and Deepseek couldn't see. So much for the "superior" intelligence.
This has become especially true for me in the past four months. The new long context reasoning models are shockingly good at digging through larger volumes of gnarly code. o3, o4-mini and Claude 3.7 Sonnet "thinking" all have 200,000 token context limits, and Gemini 2.5 Pro and Flash can do 1,000,000. As "reasoning" models they are much better suited to following the chain of a program to figure out the source of an obscure bug.
Makes me wonder how many of the people who continue to argue that LLMs can't help with large existing codebases are missing that you need to selectively copy the right chunks of that code into the model to get good results.
Earlier this year, a hackernews started quizzing me about the size and scope of the projects I worked on professionally, with the implication that I couldn't really be working on anything large or complex -- that I couldn't really be doing serious development, without using a full-fat IDE like IntelliJ. I wasn't going to dox myself or my professional work just so he could reach a conclusion he's already arrived at. The point is, to this person, beyond a certain complexity threshold -- simple command-line tools, say -- an IDE was a must, otherwise you were just leaving productivity on the table.
People are going to be making the same judgements about AI-assisted coding in the near future. Sure, you could code everything yourself for your own personal enrichment, or simply because it's fun. But that will be a pursuit for your own time. In the realm of business, it's a different story: you are either proompting, or you're effectively stealing money from your employer because you're making suboptimal use of the tools available. AI gets you to something working in production so much faster that you'd be remiss not to use it. After all, as Milt and Tim Bryce have shown, the hard work in business software is in requirements analysis and design; programming is just the last translation step.
One of the things people often overlook don't talk about in this arguments is the manager's point of view and how it's contributing to the shakeups in this industry.
As a developer I'm bullish on coding agents and GenAI tools, because they can save you time and can augment your abilities. I've experienced it, and I've seen it enough already. I love them, and want to see them continue to be used.
I'm bearish on the idea that "vibe coding" can produce much of value, and people without any engineering background becoming wildly productive at building great software. I know I'm not alone. If you're a good problem solver who doesn't know how to code, this is your gateway. And you better learn what's happening with the code while you can to avoid creating a huge mess later on.
Developers argue about the quality of "vibe coded" stuff. There are good arguments on both sides. At some point I think we all agree that AI will be able generate high quality software faster than a human, someday. But today is not that day. Many will try to convince you that it is.
Within a few years we'll see massive problems from AI generated code, and it's for one simple reason:
Managers and other Bureaucrats do not care about the quality of the software.
Read it again if you have to. It's an uncomfortable idea, but it's true. They don't care about your flow. They don't care about how much you love to build quality things. They don't care if software is good or bad they care about closing tickets and creating features. Most of them don't care, and have never cared about the "craft".
If you're a master mason crafting amazing brickwork, you're exactly the same as some amateur grabbing some bricks from home depot and slapping a wall together. A wall is a wall. That's how the majority of managers view software development today. By the time that shoddy wall crumbles they'll be at another company anyway so it's someone else's problem.
When I talk about the software industry collapsing now, and in a few years we're mired with garbage software everywhere, this is why. These people in "leadership" are salivating at the idea of finally getting something for nothing. Paying a few interns to "vibe code" piles of software while they high five each other and laugh.
It will crash. The bubble will pop.
Developers: Keep your skills sharp and weather out the storm. In a few years you'll be in high demand once again. When those walls crumble, they will need people who what they're doing to repair it. Ask for fair compensation to do so.
Even if I'm wrong about all of this I'm keeping my skills sharp. You should too.
This isn't meant to be anti-management, but it's based on what I've seen. Thanks for coming to my TED talk.
* And to the original point, In my experience the tools interrupt the "flow" but don't necessarily take the joy out of it. I cannot do suggestion/autocomplete because it breaks my flow. I love having a chat window with AI nearby when I get stuck or want to generate some boilerplate.
I think you are right with the building analogy. Most stuff built in the last 25 years is crap quality! But importantly looks nice. Needs to look nice at first.
> If you're a master mason crafting amazing brickwork, you're exactly the same as some amateur grabbing some bricks from home depot and slapping a wall together.
IDK, there's still a place in society for master masons to work on 100+ year old buildings built by other master masons.
Same with the robots. They can implement solutions but I'm not sure I've heard of any inventing an algorithmic solution to a problem.
So if I'm understanding this, there are two central arguments being made here.
1. AI Coding leads to a lack of flow.
2. A lack of flow leads to a lack of joy.
Personally, I can't find myself agreeing with the first argument. Flow happens for me when I use AI. It wouldn't surprise me if this differed developer to developer. Or maybe it is the size of requests I'm making, as mine tend to be on the smaller size where I already have an idea of what I want to write but think the AI can spit it out faster. I also don't really view myself as prompt engineering; instead it feels more like a natural back and forth with the AI to refine the output I'm looking for. There are times it gets stubborn and resistant to change but that is generally a sign that I might want to reconsider using AI for that particular task.
One trend I've been finding interesting over the past year is that a lot of engineers I know who moved into engineering management are writing code again - because LLMs mean they can get something productive done in a couple of hours where previously it would have taken them a full day.
Managers usually can't carve out a full day - but a couple of hours is manageable.
See also this quote from Gergely Orosz:
Despite being rusty with coding (I don't code every day
these days): since starting to use Windsurf / Cursor with
the recent increasingly capable models: I am SO back to
being as fast in coding as when I was coding every day
"in the zone" [...]
When you are driving with a firm grip on the steering
wheel - because you know exactly where you are going, and
when to steer hard or gently - it is just SUCH a big
boost.
I have a bunch of side projects and APIs that I operate -
but usually don't like to touch it because it's (my)
legacy code.
Not any more.
I'm making large changes, quickly. These tools really
feel like a massive multiplier for experienced devs -
those of us who have it in our head exactly what we want
to do and now the LLM tooling can move nearly as fast as
my thoughts!
Yeah I think flow is more about holding a lot of knowledge about the code and its control flow in your head at a time. I think there's an XKCD or something that illustrates that.
You still need to do that if you're using AI, otherwise how do you know if it's actually done a good job? Or are people really just vibe coding without even reading the code at all? That seems... unlikely to work.
Some people love programming, for the sake of programming itself. They love the CS theory, they love the tooling, they love most everything about it.
Other people see all that as an means to an end - and find no joy from the technical aspect of creating something. They're more interested in the end result / product, rather than the process itself.
I think that if you're in group A, it can be difficult to understand group B. In vice versa.
I'm a musician, so I love everything about creating music. From the theory, to the mastery of the instrument, the tens of thousands of hours I've poured into it...finally being able to play something I never thought I'd be able to, just by sheer willpower and practice. Coming up with melodies that feel something to me, or I can relate to something.
On the other hand, I know people that want to jump straight to the end result. They have some melody or idea in their head, and they just want to generate some song that revolves around that idea.
I don't really look down on those people, even though the snobs might argue that they're not "real musicians". I don't understand them, but that's not really something I have to understand either.
So I think there are a lot of devs these days, that have been honing their skills and love for the craft for years, that don't understand why people just want things to be generated, with no effort.
> Some people love programming
> Other people see all that as an means to an end
I think it's worth pointing out that most people are both these things at different times.
There's things I care about and want a deep understanding of but there's plenty of tasks I want to just "go away". If I had an junior coder - I'd be delegating these. Instead I use AI when I can.
There's also tasks where I want a jump start. I prefer fixing/improving code over writing from scratch so often a bad AI attempt is still valuable to me.
i mean how far are you willing to take that argument? every decade has just been a new abstraction, imagine people flipping switches or in raw assembly talking about how they don't "understand" you now with your no effort. or even those who don't "understand" why you use your autocomplete and fancy IDE, preferring a simple text editor.
i say this as someone who cut my teeth on this stuff growing up and seeing the evolution, it's both. and at some point it's honestly elitism and gatekeeping. i sort of cringe when it's called a "craft" because it's not like woodworking or something. the process is both full of joy but so is the end result, and the nature of our industry is that the process is ALWAYS changing.
you accumulate a depth of knowledge and watch as it washes away in a few years. that kind of change, and the big kind of change that AI brings scares people so they start clinging to it like it's some kind of centuries old trade lol.
I have actually had some really great flow evenings lately, the likes of which I have not enjoyed in many years, precisely because of AI-assisted coding. The trick is to break the task down in to components that are of moderate complexity so that the AI can handle them (Gemini 2.5 Pro one-shots), and keep your mind on the high-level design which today's AI cannot coordinate.
What helps me is to think of it like I'm a kid again, learning to code full of ideas but without any pre-conceived notions. Rather than the Microsoft QuickBasic manual in my hands, I've got Gemini & Claude Code. I would be gleefully coding up a storm of games, websites, dubious webcrawlers, robots, and lord knows what else. Plenty of flow to be had.
Added joy for me as well mostly by giving me the relevant API calls I need straight away, from publically available documentation, instead of having to read docs myself. "How do I do X in Y"
And if something's not obvious I can always fetch the specifics of any particular calls. But at least I didn't have to find the name of that call in the first place.
This is the way. I feel like a kid too again. It's way more fun actually. As a kid I got too frustrated for not being able to install my WAMP stack.
I’m right there with you on this.
Thanks for the comment. You articulated how I feel about this situation very well.
This comment section really shows the stark divide between people who love coding and thus hate AI, and people who hate coding and thus love AI.
Honestly, I suspect the people who would prefer to have someone or something else do their coding, are probably the devs who are already outputting the worst code right now.
I replaced "code" for "singing" to make a point.
> This comment section really shows the stark divide between people who love singing and thus hate AI-assisted singing, and people who hate singing and thus love AI-assisted singing.
> Honestly, I suspect the people who would prefer to have someone or something else do their singing, are probably the singers who are already outputting the worst singing right now.
The point is: just because you love something, doesn't mean you're good at it. It is of course positively correlated with it. I am in fact a better singer because I love to sing compared to if I never practiced. But I am not a good singer, I am mediocre at best (I chose this example for a reason, I love singing as well as coding! :-D)
And while it is easier to become good at coding than at singing - for professional purposes at least - I believe that the effect still holds.
I think the analogy/ substitution falls apart in that singing is generally not very stable or lucrative (for 99.999% of singers), so it is pretty rare to find someone singing who hates it. Much less uncommon to find people working in IT who hate the specific work of their jobs.
And I think we do tend to (rightfully) look down on e.g. singers who lip-sync concerts or use autotune to sing at pitches they otherwise can't, nevermind how we'd react if one used AI singing instead of themselves.
Yes, loving something is no guarantee of skill at it, but hating something is very likely to correspond to not being good at it, since skills take time and dedication to hone. Being bad at something is the default state.
I love coding - but I am not very good at it. I can describe what I want in great detail, with great specificity. But I am not personally very good at turning that detailed specification into the proper syntax and incantations.
AI is like jet fuel for me. It’s the translation layer between specs and code I’ve always wanted. It’s a great advisor for implementation strategies. It’s a way to try new strategies in code quickly.
I don’t need to get anyone else to review my code. Most of this is for personal projects.
I don’t really write professionally, so I don’t have a ton of need for it to manage realities of software engineering (large codebases, peer reviews, black box internal systems, etc). That being said - I do a reasonable amount of embedded Linux work, and AI understands the Linux kernel and device drivers very well.
To extend your metaphor: AI is like a magic microphone that makes all of my singing sound like Tony Rice, my personal favorite singer. I’ve always wanted to sound like him - but I never will. I don’t have the range or the training. But AI allows my coding level to get to that corresponding level with writing software.
I absolutely love it.
1 reply →
Right, just how back in the day, people who loved writing assembly hated high level languages and people who found assembly too tedious loved compilers.
First of all, Lisp, Fortran and COBOL had been around most of the time when assembly was popular. Assembly was used because of resource constraints.
Secondly, you are not writing anything you get from an LLM. You prompt it and it spits out other people's code, stripped of attribution.
This is what children do: Ask someone to fix something for you without understanding the result.
It’s almost like there’s a big range of different comprehension styles among human beings, and a varying set of preferences that go with those.
What if I prefer to have a clone of me doing my coding, and then I throw my clone under the bus and start to (angrily) hyperfocus explore and change every piece to be beautiful? Does this mean I love coding or I hate coding?
It's definitely a personality thing, but that's so much more productive for me, than convincing myself to do all the work from scratch after I had a design.
I guess this means I hate coding, and I only love the dopamine from designing and polishing my work instead of making things work. I'm not sure though, this feels like the opposite of hate coding.
If you create a sufficiently absurd hypothetical, anything is possible.
Or are you calling an LLM a "clone" of you? In that case, it's more, "if you create a flawed enough starting premise, anything is possible".
2 replies →
Cant one enjoy both? After all, coding with AI in practice is still coding, just with a far higher intensity.
It is absolutely possible to enjoy both- I have used LLMs to generate code for ideas about alternate paths to take when I write my code- but prompt generation is not coding, and there are WAY too many people who claim to be coding when they have in fact done nothing of the sort.
> a far higher intensity
I'm not sure what this is supposed to mean. The code that I've gotten is riddled with mistakes and fabrications. If I were to use it directly, it would significantly slow my pace. Likewise, when I use LLMs to offer alternative methods to accomplish something, I have to take the time to sit down and understand what they're proposing, how to actually make it work, and whether that route(s) would be better than my original idea. That is a significant speed reduction.
The only way I can imagine LLMs resulting in "far higher intensity" is if I was just yolo'ing the code into my program, and then doing frantic integration, correction, and bugfix work afterwards.
Sure, that's "higher intensity", but that's just working harder and not smarter.
yeah i definitely enjoy the craft and love of writing boilerplate or manually correcting simple errors or looking up functions /s. i hate how it's even divided into "two camps", it's more like a big venn diagram.
Who write boilerplate this day? I just lift the code from the examples in the docs (especially css frameworks). And I love looking at functions docs, because after doing it a few times, you develop an holistic understanding of the library and your speed increases. Kinda like learning a foreign language. You can use an app to translate everything, or asks for the correct word when the needs arises. The latter is a bit frustrating at the beginning, but that’s the only way to become fluent.
1 reply →
Every PR I have to review with an obviously LLM-generated title stuffed with adjectives, and a useless description containing an inaccurate summary of the code changes pushes me a little bit more into trying to make my side projects profitable in the hope that one takes off. It usually only gets worse from there.
Documentation needs to be by humans for humans, it's not a box that's there to be filled with slop.
> The actual documentation needs to be by humans for humans.
This is true for producing the documentation but if there is an LLM that can take said documentation and answer questions about it is a great tool. I think I get the answer far quicker with LLM than sifting through documentation when looking for existence of a function in a library or a property on an object.
1 reply →
seeing a lot of `const thing = doThing(); // add this line` showing up lately too.
See my reply to another comment - I don't think the divide is as stark as you claim.
(And I don't enjoy the value judgement)
I think that comment is conflating 2 different things: 1) people like you and I who use LLMs for exploring alternative methods to our own, and 2) people who treat LLMs like Stack Overflow answers they don't understand but trust because it's on SO.
Yes, there are tasks or parts of the code that I'm less interested in, and would happily either delegate or negotiate-off to someone else, but I wouldn't give those to a writer who happens to be able to write in a way that approximates program code, I'd give them to another dev on the team. A junior dev gets junior dev tasks, not tasks that they don't have the skills to actually perform, and LLMs aren't even at an actual junior dev level, imhe.
I noted in another comment that I've also used LLMs to get ideas for alternate ways to implement something, or to as you said "jump start" new files or programs. I'm usually not actually pasting that code into my IDE, though- I've tried that, and the work to make LLM-generated code fit into my programs is way more than just writing out the bits I need, where I need. That is clearly not the case for a lot of people using LLMs, though.
I've seen devs submitting PRs with giant blocks of clearly LLM-gen'd code, that they've tried to monkey-wrench into working with the rest of the program (often breaking conventions or secure coding standards). And these aren't junior devs, they're devs that have been working here for years and years.
When you force them to do a code review, they know it's not up to par, but there is a weird attitude that LLM-gen'd code is more acceptable to be submitted with issues than personally-written code. As though it's the LLM's fault or job to fix, even though they prompted and copied and badly-integrated and PR'd it.
And that's where I think there is a stark divide. I think you're on my side of the divide (at least, I didn't get the impression that you hate coding), it just sounds like you haven't really seen the other side.
My personal dime-store psych theory is that it's the same mental mechanism that non-technical computer users fall into of improperly trusting/ believing computers to produce correct information, but now happening to otherwise technical folks too because "AI" is still a black box technology to most of us, like computers in general are to non-techies.
LLMs are really really cool, and really really impressive to me, and I've had 'wow' moments where they did something that makes you forget what they are and how they work, but you can't let that emotional reaction towards it override the part that knows it's just a token chain. When you do, people end up (obviously on the very extreme end) 'dating' them, letting them make consequential "decisions", or just over-trusting their output/code.
I like solving problems but I hate coding. Wasting 20 minutes because you forgot a semicolon or something is not fun. AI let's me focus on the problem and not bother with the tedious coding bit.
That comment makes me deeply suspicious about your debugging skills. And the formatting of your code.
If devs would learn how to document their work properly then there'd be much less use for AI and more people who enjoyed coding.
>Honestly, I suspect the people who would prefer to have someone or something else do their coding
Alright, please stop using SDK's, google, stackoverflow, any system libraries. You prefer to do it for yourself right?
If you're using those things to do *the core function* of the program you're writing, that's an issue.
SDKs and libraries are there to provide common (as in, used repeatedly, by many) functions that serve as BUILDING BLOCKS.
If you import a library and now your program is complete, then you didn't actually make a useful program, you just made a likely less efficient interface for the library.
BUT ALSO-
SDKs and libraries are *vetted* code. The advantage you are getting isn't just about it having been written for you, it's about the hundreds of hours of human code review, iteration, and thought, that goes into those libraries.
LLM code doesn't have that, so it's not about you benefitting from the knowledge and experience of others, it's purely about reducing personally-typed LoC.
And yes, if you're wholesale copy-pasting major portions of your program from stack overflow, I'd say that's about as bad as copy-pasting from ChatGPT.
Do you typically find reductio ad absurdum arguments to be persuasive?
If there’s an SDK that implements exactly the product you’re trying to build, then you’re just selling someone else’s SDK.
1 reply →
> Honestly, I suspect the people who would prefer to have someone or something else do their coding
Have we forgotten that we advanced in software by building on the work of others?
They are not building on the work of others, they are taking the laundered work of others.
2 replies →
No, problem is when others are no longer needed, a machine gets to do everything, and only a few selected humans get to take care of the replicator machine.
This belies the way that LLM code is being used.
People aren't taking LLM code and then thoughtfully refactoring and improving it, they're using it to *avoid* doing that, by treating the generated code as though it's already had that done.
That's why the pro-LLM-code people in this very thread are talking about using it to automate away the parts of the coding they don't like. You really think they're then going to go back and improve on the code past it minimally working?
There will be no advancement from that, just mediocre or bad code going unreviewed and ignored until it breaks.
I spend most of my time fixing that shit.
There's nothing stopping you from coding if you enjoy it. It's not like they have taken away your keyboard. I have found that AI frees me up to focus on the parts of coding I'm actually interested in, which is maybe 5-10% of the project. The rest is boiler plate, cargo-culted, Dockerfile, build system and bash environment variable passing circle of hell that I really could care less about. I care about certain things that I know will make the product better, and achieve its goals in a clever and satisfying way.
Even when I'm stuck in hell, fighting the latest undocumented change in some obscure library or other grey-bearded creation, the LLM, although not always right, is there for me to talk to, when before I'd often have no one. It doesn't judge or sneer at you, or tell you to "RTFM". It's better than any human help, even if its not always right because its at least always more reliable and you don't have to bother some grey beard who probably hates you anyway.
> The rest is boiler plate, cargo-culted, Dockerfile, build system and bash environment variable passing circle of hell that I really could care less about.
Even more so, I remember making a Chrome extension and feeling intimidated. I knew that I'd be comfortable with most of it given that JS is used but I just didn't know how to start.
With an LLM it is way faster to spin up some default config and get going versus reading a tutorial. What I've noticed in that respect is that I just read what it does and then immediately reason why it's there. "Oh, there's a manifest.json file with permissions and a few other things, fair, makes sense. Oh, so you have the HTML/CSS/JS of the extension, you have the HTML/CSS/JS of the page you're injecting some code into and you have the JS of a background worker. Ah yea, I get that."
And then I just get immediately on coding.
> What I've noticed in that respect is that I just read what it does and then immediately reason why it's there ....
How if it hallucinate and gives you wrong code and explanation? It is better to read documentations and tutorials first.
14 replies →
I think the fear for those of us who love coding, stability and security, that we are going to be confronted with apples that are rotten on the inside and our work, our love, is going to turn (even more so) into pain. The challenge in computing is that the powers that decide have little overview over the actual quality and longevity of any endeavour.
I work as a consultant assessing other people's code and it's hard not to lose my religion, sort of speak.
> doesn't judge or sneer at you, or tell you to "RTFM". It's better than any human help, even if its not always right because its at least always more reliable and you don't have to bother some grey beard who probably hates you anyway.
That’s a lot of trauma you’re dealing with.
Like many others writing here, I enjoy coding (well, mostly anyway), especially the when it requires deep thought and patient experimentation to get anywhere. It's also great to preside over finally wiring together the routines (modules, libraries) that bind a project into a coherent whole.
Haven't much used AI to assist. After all, hard enough finding authentic humans capable and willing to voluntarily review/critique one's code. So far AI doesn't consistently provide that kind of help. OTOH seems almost certain over time AI systems will improve in terms of specific and comprehensive "insights" into the particular types of code one is writing.
I think an issue is that human creativity is hard to measure. Likely enough AI is even tougher to assess. Probably AI will increasingly be assigned tasks like constructing project skeletons, assuring parts can be joined together without undue strain, handling "boilerplate" and other routine chores. To be sure the landscape will look different in 50 years, I'm certain we'd be amazed were we able to see what future systems will be doing.
In any case, we shouldn't hesitate to use tools that genuinely boost our creativity. One badly needed role would be enabling development of higher reliability software. Still that's a far cry from the contributions emanating from the best of human originality, talent and motivation.
So much this. The AI takes care of the tedious line by line what’s-the-name-of-that-stdlib-function parts (and most of the tedious test-writing parts) and lets me focus on the interesting bits like what it is I want to build and how the pieces should fit together. And debugging, which I find satisfying.
Sadly, I find it sorely lacking at dealing with build systems and that particular type of boilerplate, mostly because it seems to mix up different versions of things too much and gives you totally broken setups more often than not. I’d just as soon never deal with the he’ll that is front end build/lint/test config again.
> The AI takes care of the tedious line by line what’s-the-name-of-that-stdlib-function parts (and most of the tedious test-writing parts)
AI generated tests are a bad idea.
Aren't stdlib functions the ones you know by heart after a while anyways?
3 replies →
> The rest is boiler plate, cargo-culted, Dockerfile, build system and bash environment variable passing
I keep seeing people saying to use an LLM to write boilerplate, but like... do you not just copy that from another project where you already wrote it?
No, because it's usually a few years old and already obsolete - the frameworks and the language have gone through a gazillion changes and what you did in 2021 suddenly no longer works at all.
3 replies →
I keep seeing that suggestion as well and the only sensible way I see would be to use one off boilerplate, anything else does not make sense.
If you keep re-using boilerplate once in a while copying it from elsewhere is fine. If you re-use it all the time, just get a macro setup in your editor of choice. IMHO that is way more efficient than asking AI to produce somewhat consistent boilerplate
1 reply →
They perhaps haven’t taken away your keyboard but anecdotally, a few friends work at places where their boss is requiring them to use the LLMs. So you may not have to code with them but some people are starting to be chained to them.
And even when that's not the case you are still indirectly working with them because your coworker is and "somehow" their code has gotten worse
Yes, there are bad places to work. There are also places that require detailed time tracking, do not allow any time to write tests, have very long hours, tons of on-call alerts, etc.
1 reply →
I read one characterization which is that LLMs don't give new information (except to the user learning) but they reorganize old information.
Custodians of human knowledge.
That’s only true if you tokenize words rather than characters. Character tokenization generates new content outside the training vocabulary.
2 replies →
This.
Frankly I don't want to spend 2 hours reading documentation just to find out some arcane incantation that gets the computer to do what I want it to do.
The interesting part of programming to me is designing the logic. It's the 'this, then that, except when this' flow that I'm really interested in, not the search for some obscure library that has some function that will parse this csv.
Llms are great for that, and let me get away from the pointless grind and into the things that I enjoy and are actually providing value.
The pair programming is also a super good thing. I work best when I can spitball and throw out random ideas and get quick feedback. Llms let me do that without bothering others who have their own work to do.
I think you're robbing yourself.
Of course, it all depends how you use the LLM. While the same can be true for StackOverflow, the LLMs just scale the issues up.
Except you do care. It's why you're frustrated and annoyed. And good!!! That feeling is because what you're describing requires solving. If something is routine, automate it. But it's really not good to automate in a statistical way, especially when that statistical tool is optimized for human preference. Because remember that also means mistakes are optimized to be missed by humans.[0]
With expertise in anything, I'm sorry, but you also got to do the shit work. To be a great musician you gotta practice boring scales. It's true even if you just want to be a sub par one.
But a little grumpy is good. It drives you to fix things, and frankly, that's our job. The things that are annoying and creating friction don't need be repeated over and over, they need alternative solutions. The scripts you build are valuable. The "useless" knowledge you gain isn't so useless. Those little details add up without you knowing and make you better.
That undocumented code makes you frustrated and reminds you to document your own. You don't want to be a hypocrite. The author of the thing you're using probably thought the same thing: "No one is gonna use this garbage, I'm not going to waste my time documenting it". Yet here we are. Over and over again yet we don't learn the lesson.
I'm not gonna deny there's assholes. There are. But even assholes teach you. At worst, they teach you how not to act.
And some people are you telling you to RTM and not RTFM. Sure, it has lots of extra information in it that you don't need to get your specific job done, but have you also considered that it has lots of extra information in it? The person that wrote it clearly thought the context was important. Maybe it isn't. In that case, you learned a lesson in how not to write documentation!
What I'm getting at is that there's a lot of learning done all over the place. Trying to take out all the work and only have "the fun" is harming yourself and has a large potential to make less time for the fun stuff[0]. I'd be surprised if I'm alone in this, but a lot of stuff I enjoy now was stuff that originally frustrated me. IME this is pretty common! It's true for every person I know. Similarly, it's also true for things I learned that I thought I'd never use again. It always has a way of coming back.
I'm not going to pretend it's all fun and games. I'm explicitly saying it's not. But I'm confident in the long run it's better. Despite the lack of accuracy, I use LLMs (and Google, and even the TFM) like I would a solution guide the homework problems when I was in school. Try first, then consult. The struggle is an investment in your future. It sucks, but if all the best things in life were easy then we'd all have them. I'm just trying to convince you that it pays off.
I'm completely aware this is all context dependent. There's a time and place for everything. But given the percentages you mention (even taken as exaggeration), something sounds wrong. It's hard to suggest specific solutions without details but I'd be surprised if there weren't better and more rewarding solutions than having the LLM do it for you
[0] That's the big danger and what drives distrust in them. Because you need to work extra hard to find mistakes, increasing workload, not decreasing, because debugging is most of the job!
After all, if we lose the joy in our craft, what exactly are we optimizing for?
Solving problems for real people. Isn't the answer here kind of obvious?
Our field has a whole ethos of open-source side projects people do for love and enjoyment. In the same way that you might spend your weekends in a basement woodworking shop without furnishing your entire house by hand, I think the craft of programming will be just fine.
> Solving problems for real people. Isn't the answer here kind of obvious?
No. There are a thousand other ways of solving problems for real people, so that doesn't explain why some choose software development as their preferred method.
Presumably, the reason for choosing software development as the method of solving problems for people is because software development itself brings joy. Different people find joy in different aspects even of that, though.
For my part, the stuff that AI is promising to automate away is much of the stuff that I enjoy about software development. If I don't get to do that, that would turn my career into miserable drudgery.
Perhaps that's the future, though. I hope not, but if it is, then I need to face up to the truth that there is no role for me in the industry anymore. That would pretty much be a life crisis, as I'd have to find and train for something else.
> That would pretty much be a life crisis, as I'd have to find and train for something else.
There's inertia in the industry. It's not like what you're describing could happen in the blink of an eye. You may well be at the end of your career when this prophecy is fulfilled, if it ever comes true. I sure will be at the end of mine and I'll probably work for at least another 20 years.
1 reply →
"There are a thousand other ways of solving problems for real people, so that doesn't explain why some choose software development as their preferred method."
Software development is almost unique in the scale that it operates at. I can write code once and have it solve problems for dozens, hundreds, thousands or even millions of people.
If you want your work to solve problems for large numbers of people I have trouble thinking of any other form of work that's this accessible but allows you to help this many others.
Fields like civil engineering are a lot harder to break into!
> No. There are a thousand other ways of solving problems for real people, so that doesn't explain why some choose software development as their preferred method.
I don't see why we should seek an explanation if there are thousands of ways to be useful to people. Is being a lawyer particularly better than being an accountant?
I'm probably just not as smart or creative as you, but say my problem is I have a ski cabin that I want to rent it to strangers for money. Nevermind a thousand, What are 100 ways without using software that I could do something about that, vs listing it on Airbnb?
Same as when higher-level languages replaced assembly for a lot of use cases. And btw, at least in places I've worked, better traditional tooling would replace a lot more headcount than AI would.
I already see this happening with low code, SaaS and MACH architectures.
What used to be a project doing a CMS backend, now is spent doing configurations on a SaaS product, and if we are lucky, a few containers/serveless for integrations.
There are already AI based products that can automate those integrations if given enough data samples.
Many believe AI will keep using current programming languages as translation step, just like those Assembly developers thought compiling via Assembly text generation and feeding into an Assembly would still be around.
Not even close, those were all deterministic, this is probabilistic.
9 replies →
> Solving problems for real people. Isn't the answer here kind of obvious?
Look at the majority of the tech sector for the last ten years or so and tell me this answer again.
Like I guess this is kind of true, if "problems for real people" equals "compensating for inefficiencies in our system for people with money" and "solutions" equals "making a poor person do it for them and paying them as little as legally possible."
Those of us who write software professionally are literally in a field premised on automating other people's jobs away. There is no profession with less claim to the moral high ground of worker rights than ours.
29 replies →
solving real problems is the core of it, but for a lot of people the joy and meaning come from how they solve them too. the shift to AI tools might feel like outsourcing the interesting part, even if the outcome is still useful. side projects will stick around for sure, but i think it's fair to ask what the day-to-day feels like when more of it becomes reviewing and prompting rather than building.
> After all, if we lose the joy in our craft, what exactly are we optimizing for?
For being one of the few lucky ones that gets to stay around taking care of the software factory robots, or designing them, while everyone else that used to work at the factory is now queueing somewhere else.
To me THIS is the most stressful part of the whole thing.
I like programming but I have other hobbies I find fulfilling, and nothing stops me from programming with a pen and paper.
The bad vibes are not caused by lack of programming, they're caused by headsman sharpening his axe behind me.
A few lucky programmers will be elevated to God status and we're all fighting for those spots now.
For me the most surprising part is the phase of wonder, from those that apparently never read anything in the history of industrial revolution, and think everyone will still have a place when we achieve Star Trek replicator level.
Not everyone gets a seat at the starship.
I love that quote he led with.
In my case, I couldn't agree more, with the premise of the article, but my life today, is centered around writing software the very best that I can; regardless of value or price.
It's not very effective, if I were to be trying to make a profit.
It's really hard to argue for something, if the something doesn't result in value, as perceived by others.
For me, the value is the process. I often walk away from my work, once I have it up and shipping. I do like to take my work all the way through shipping, support, and maintenance, but find that my eye is always drawn towards new shores[0].
[0] https://littlegreenviper.com/miscellany/thats-not-what-ships...
When I coding, most of time was used to search docs over internet. My first language is not english, search over hundrud of pages is quiet slow.
AI help me a lot, you don't need search, just ask AI, and it provide the answer directly. After using AI, I have more time used on coding, more fun.
I am mostly pretty underwhelmed with LLMs' code, but this is a use-case that makes perfect sense to me, and seems like a net-positive: using them as a reference manual/ translator/ training aid.
I just wish I saw more people doing this, rather than asking them to 'draw 80% of the owl'.
The author is already an experienced programmer. Let me toss in an anecdote about the next generation of programmers. Vibe coding: also called playing pinball with the AI, hoping something useful comes out.
I taught a lecture in my first-semester programming course yesterday. This is in a program for older students, mostly working while going back to school. Each time, a few students are selected to present their code for an exercise that I pick randomly from those they were assigned.
This guy had fancy slides showing his code, but he was basically just reading the code off the page. So I ask him: “hey, that method you call, what exactly does it do?”.
Um…
So I ask "Ok, the result from that method is assigned to a variable. What kind of variable is it?" Note that this is Java, the data type is explicitly declared, so the answer is sitting there on his slide.
Um…
So I tear into him. You got this from ChatGPT. That’s fine, if you need the help, but you need to understand what you get. Otherwise you’ll never get a job in IT.
His answer: “I already have a job in IT.”
Fsck. There is your vibe coder. You really do not want them working on anything that you care about.
Does your course not have exams or in-lab assignments? Should sort itself out. Honestly, I'm all for homework fading away as professors can't figure out how to prevent people from using AI. It used to be the case that certain kids could get away with not doing much because they were popular enough to get people to let them copy their assignments (at least for certain subjects). Eventually the system will realize they can't detect AI and everything has to be in-person.
Sure, this guy is likely to fail the course. The point is: he is already working in the field. I don't know his exact job, but if it involves programming, or even scripting, he is faking his way with AI, not understanding what he's doing. That is frightening.
This is one of the biggest dangers imo. While I agree with the OP about the deflation of joy in experienced programmers, the related but more consequential effect seems to be dissuading people from learning. A generational threat to collective competence and a disservice to students and teachers everywhere
I had a lot of joy making an experimental DSL with a web server runtime using primarily LLM tools.
Then I shared it on HN and was subject to literal harassment.
Can't relate at all. I've never had so much fun programming as I have now. All the boring and tedious parts are gone and I can finally focus on the code I love to write.
I don't know man, maybe prompt most of your work, eyeball it and verify it rigorously (which if you cannot do, you should absolutely never touch an LLM!), run a script to commit and push after 3 hours and then... work on whatever code makes you happy without using an LLM?
Let's stop pretending or denying it: most of us would delegate our work code to somebody else or something else if we could.
Still, prompting LLMs well requires eloquence and expressiveness that many programmers don't have. I have started deriving a lot of value from those LLMs I chose to interact with by specifying clear boundaries on what's the priority and what can wait for later and what should be completely ignored due to this or that objective (and a number of other parameters I am giving them). When you do that well, they are extremely useful.
> most of us would delegate our work code to somebody else or something else if we could.
I saw your objections to other comments on the basis of them seemingly not having a disdainful attitude towards coding they do for work, specifically.
I absolutely do have tasks, coding included, that I don't want to do, and find no joy in. If I can have my manager assign the task to someone else, great! But using an LLM isn't that, so I'm still on the hook for ensuring all the most boring parts of that task (bugfixing, reworks, integration, tests, etc) get done.
My experience with LLMs is that they simply shift the division of time away from coding, and towards all the other bits.
And it can't possibly just be about prompting. How many hundreds of lines of prompting would you need to get an LLM to understand your coding conventions, security baselines, documentation reqs, logging, tests, allowed libraries, OSS license restrictions (i.e. disallowed libraries), etc? Or are you just refactoring for all that afterwards?
Maybe you work somewhere that doesn't require that level of rigor, but that doesn't strike me as a good thing to be entrenching in the industry by increasing coders' reliance on LLMs.
A super necessary context here is that I barely use LLM at all still. Maybe I should have said so but I figured that too much nuance would ruin a top-level comment and mostly casually commented on a tradeoff of using or not using LLMs.
Where I use LLMs:
1. Super boring and annoying tasks. Yes, my prompts for those include various coding style instructions, requests for small clarifying comments where the goal of the code is not obvious, tests. So, no OSS license restrictions. Libraries I specify most of the times I used LLMs (and only once did I ask it to suggest a library). Logging and telemetry I add myself. So long story short, I use the LLM to show me a draft of a solution and then mercilessly refactor it to match my practices and guidelines. I don't do 50 exchanges out of laziness, no.
2. Tasks where my expertise is lacking. I recently used an LLM to help me with making a `.clone()`-heavy Rust code to become nearly zero-copy for performance reasons -- it is a code on a hot path. As much as I love Rust and I am fairly good at it (realistically I'm IMO at 7.5 / 10), all the lifetimes and zero-copy semantics I still don't know yet. A long session with an LLM after, I emerged both better educated and with a faster code. IMO a win-win.
>most of us would delegate our work code to somebody else or something else if we could.
Laughably narrow-minded projection of your own perspective on others.
We all delegate. Did you knit your own clothes or is that too boring for you?
Enjoying to code/knit is fine but we can no longer expect to get paid well to do it.
There is context, that you laughably skipped. You do you.
I see this "prompting is an art" stuff a lot. I gave Claude a list of 10 <Route> objects and asked it to make an adjustment to all of them. It gave me 9 back. When I asked it to try again it gave me 10 but one didn't work. What's "prompt engineering" there, telling it to try again until it gets it right? I'd rather just do it right the first time.
Then don't use it? Nobody is making you.
I am also barely using LLMs at the moment. Even 10% of the time would be generous.
What I was saying is that I have tried different ways of interacting with LLMs and was happy to discover that the way I describe stuff to another senior dev actually works quite fine with an LLM. So I stuck to that.
Again, if an LLM is not up to your task, don't waste your time with it. I am not advocating for "forget everything you knew and just go ask Mr. AI". I am advocating for enabling and productivity-boosting. Some tasks I hate, for some I lack the deeper expertise, others are just verbose and require a ton of typing. If you can prompt the LLM well and vet the code yourself after (something many commenters here deliberately omit so they can happily tear down their straw man) then the LLM will be a net positive.
It's one more tool in the box. That's all there is to it really. No idea why people get so polarizing.
We used to make fun of and look down on coders who mindlessly copy paste and mash the compile button until the code runs, for good reasons.
Prompt engineering is just trying that task on a variety of models and prompt variations until you can better understand the syntax needed to get the desired outcome, if the desired outcome can be gotten.
Honestly you’re trying to prove AI is ineffective by telling us it didn’t work with your ineffective protocol. That is not a strong argument.
6 replies →
> Let's stop pretending or denying it: most of us would delegate our work code to somebody else or something else if we could.
Hard disagree, I get to hyperfocus on making magical things that surprise and delight me every day.
Nice. I've got a whole lot of magical things that I need built for my day job. Want to connect so I can hand the work over to you? I'll still collect the paychecks, but you can have the joy. :)
I'm disappointed that several of you so easily skipped over the "work" word. It is doing a lot of work in that sentence.
> Let's stop pretending or denying it: most of us would delegate our work code to somebody else or something else if we could.
I don’t think this is the case, if anything the opposite is true. Most of us would like to do the work code but have realized, at some career point, that you’re paid more to abstract yourself away from that and get others to do it either in technical leadership or management.
> I don’t think this is the case, if anything the opposite is true
I'll be a radical and say that I think it depends and is very subjective.
Author above you seems to enjoy working on code by itself. You seem to have a different motivation. My motivation is solving problems I encounter, code just happen to be one way out of many possible ones. The author of the submission article seems to love the craft of programming in itself, maybe the problem itself doesn't even matter. Some people program just for the money, and so on.
Well, does not help that a lot of work tasks are meaningless drudgery that we collectively should have trivialized and 100% automated at least 20 years. That was kind of the core my point: a lot of work tasks are just plain BS.
I wouldn't, I got into software exactly because I enjoy solving problems and writing code. Verifying shitty, mindless, computer generated code is not something I would consider doing for all the money in the world.
1. I work on enjoyable problems after I let the LLM do some of the tasks I have to do for money. The LLM frees me bandwidth for the stuff I truly love. I adore solving problems with code and that's not going to change ever.
2. Some of the modern LLMs generate very impressive code. Variables caching values that are reused several times, utility functions, even closure helpers scoped to a single function. I agree that when the LLM code's quality falls bellow a certain threshold then it's better in every way to just write it yourself instead.
> most of us would delegate our work code to somebody else or something else if we could
Not me. I code because I love to code, and I get paid to do what I love. If that's not you…find a different profession?
Needlessly polarizing. I love coding since 12 years old (so more than 30 years at this point) but most work tasks I'm given are fairly boring and uninteresting and don't move almost any science or knowledge forward.
Delegating part of that to an LLM so I can code the stuff I love is a big win for my motivation and is making me doing the work tasks with a bit more desire and pleasure.
Please don't forget that most of us out there can't code for money anything that their heart wants. If you can, I'd be happy for you (and envious) but please understand that's also a fairly privileged life you'd be having in that case.
> "verify it rigorously (which if you cannot do, you should absolutely never touch an LLM!)"
100% this.
I like writing code more than reading it, personally.
2 replies →
You have an automation bias. "Surely this thing knows more than me it must be right." and there is no reason to believe that, but you will.
1 reply →
Totally. And yet rigorous proof is very difficult. Having done some mathematics involving nontrivial proofs, I respect even more how difficult rigor is.
1 reply →
The act of coding preserves your skills for that all-important verification step. No coding and the whole system falls apart.
Exactly, how are you supposed to verify anything when you don't have any skills left beyond prompting.
1 reply →
Absolutely. That's why I don't give the LLM the reins for long, nor do I tell it to do the whole thing. I want to keep my mind sharp and my abilities honed.
> Still, prompting LLMs well requires eloquence and expressiveness that many programmers don't have
It requires magical incantations that may or may not work and where a missing comma in a prompt can break the output just as badly as the US waking up and draining compute resources.
Has nothing to do with eloquence
> work on whatever code makes you happy without using an LLM?
This isn't how it works, psychologically. The whole time I'm manual coding, I'm wondering if it'd be "easier" to start prompting. I keep thinking about a passage from The Road To Wigan Pier where Orwell addresses this effect as it related to the industrial revolution:
>Mechanize the world as fully as it might be mechanized, and whichever way you turn there will be some machine cutting you off from the chance of working—that is, of living.
>At a first glance this might not seem to matter. Why should you not get on with your ‘creative work’ and disregard the machines that would do it for you? But it is not so simple as it sounds. Here am I, working eight hours a day in an insurance office; in my spare time I want to do something ‘creative’, so I choose to do a bit of carpentering—to make myself a table, for instance. Notice that from the very start there is a touch of artificiality about the whole business, for the factories can turn me out a far better table than I can make for myself. But even when I get to work on my table, it is not possible for me to feel towards it as the cabinet-maker of a hundred years ago felt towards his table, still less as Robinson Crusoe felt towards his. For before I start, most of the work has already been done for me by machinery. The tools I use demand the minimum of skill. I can get, for instance, planes which will cut out any moulding; the cabinet-maker of a hundred years ago would have had to do the work with chisel and gouge, which demanded real skill of eye and hand. The boards I buy are ready planed and the legs are ready turned by the lathe. I can even go to the wood-shop and buy all the parts of the table ready-made and only needing to be fitted together; my work being reduced to driving in a few pegs and using a piece of sandpaper. And if this is so at present, in the mechanized future it will be enormously more so. With the tools and materials available then, there will be no possibility of mistake, hence no room for skill. Making a table will be easier and duller than peeling a potato. In such circumstances it is nonsense to talk of ‘creative work’. In any case the arts of the hand (which have got to be transmitted by apprenticeship) would long since have disappeared. Some of them have disappeared already, under the competition of the machine. Look round any country churchyard and see whether you can find a decently-cut tombstone later than 1820. The art, or rather the craft, of stonework has died out so completely that it would take centuries to revive it.
>But it may be said, why not retain the machine and retain ‘creative work’? Why not cultivate anachronisms as a spare-time hobby? Many people have played with this idea; it seems to solve with such beautiful ease the problems set by the machine. The citizen of Utopia, we are told, coming home from his daily two hours of turning a handle in the tomato-canning factory, will deliberately revert to a more primitive way of life and solace his creative instincts with a bit of fretwork, pottery-glazing, or handloom-weaving. And why is this picture an absurdity—as it is, of course? Because of a principle that is not always recognized, though always acted upon: that so long as the machine is there, one is under an obligation to use it. No one draws water from the well when he can turn on the tap. One sees a good illustration of this in the matter of travel. Everyone who has travelled by primitive methods in an undeveloped country knows that the difference between that kind of travel and modern travel in trains, cars, etc., is the difference between life and death. The nomad who walks or rides, with his baggage stowed on a camel or an ox-cart, may suffer every kind of discomfort, but at least he is living while he is travelling; whereas for the passenger in an express train or a luxury liner his journey is an interregnum, a kind of temporary death. And yet so long as the railways exist, one has got to travel by train—or by car or aeroplane. Here am I, forty miles from London. When I want to go up to London why do I not pack my luggage on to a mule and set out on foot, making a two days of it? Because, with the Green Line buses whizzing past me every ten minutes, such a journey would be intolerably irksome. In order that one may enjoy primitive methods of travel, it is necessary that no other method should be available. No human being ever wants to do anything in a more cumbrous way than is necessary. Hence the absurdity of that picture of Utopians saving their souls with fretwork. In a world where everything could be done by machinery, everything would be done by machinery. Deliberately to revert to primitive methods to use archaic took, to put silly little difficulties in your own way, would be a piece of dilettantism, of pretty-pretty arty and craftiness. It would be like solemnly sitting down to eat your dinner with stone implements. Revert to handwork in a machine age, and you are back in Ye Olde Tea Shoppe or the Tudor villa with the sham beams tacked to the wall.
>The tendency of mechanical progress, then, is to frustrate the human need for effort and creation. It makes unnecessary and even impossible the activities of the eye and the hand. The apostle of ‘progress’ will sometimes declare that this does not matter, but you can usually drive him into a comer by pointing out the horrible lengths to which the process can be carried.
sorry it's so long
I've been singin' this song for years. We should return to Small Data. Hand picked, locally sourced, data. Data I can buy at a mom and pop shop. Data I can smell, data I can feel, data I can yearn for.
Gone are those days.
I'm guessing you're referencing KRAZAM? https://youtu.be/eDr6_cMtfdA
https://m.youtube.com/watch?v=eDr6_cMtfdA
I’ve been struggling with a very similar feeling. I too am a manager now. Back in the day there was something very fulfilling about fully understanding and comprehending your solution. I find now with AI tools I don’t need to understand a lot. I find the job much less fulfilling.
The funny thing is I agree with other comments, it is just kind of like a really good stack overflow. It can’t automate the whole job, not even close, and yet I find the tasks that it cannot automate are so much more boring (the ones I end up doing).
I envy the people who say that AI tools free them up to focus on what they care about. I haven’t been able to achieve this building with ai, if anything it feels like my competence has decreased due to the tools. I’m fairly certain I know how to use the tools well, I just think that I don’t enjoy how the job has evolved.
I asked chatgpt mini something about godot, and often it gives erroneous answers.
So it causes developers to regularly fix what chatgpt is wrong about.
Not great.
So long as your experience and skill allows you to produce work of higher quality than average for your industry, then you will always have a job which is to review that average quality work, and surgically correct it when it is wrong.
This has always been true in every craft, and it remains true for programmers in a post LLL world.
Most training data is open source code written by novice to average programmers publishing their first attempts at things and thus LLMS are heavily biased to replicate the naive, slow, insecure code largely uninformed by experience.
Honestly to most programmers early in their career right now, I would suggest spending more time reviewing code, and bugfixes, than writing code. Review is the skillset the industry needs most now.
But you will need to be above average as a software reviewer to be employable. Go out into FOSSland and find a bunch of CVEs, or contribute perf/stability/compat fixes, proving you review and improve things better than existing automated tools.
Trust me, there are bugs -everywhere- if you know how to look for them and proving you can find them is the resume you need now.
The days of anyone that can rub two HTML tags together having a high paying job are over.
> LLMS are heavily biased to replicate the naive, slow, insecure code largely uninformed by experience
The one time i pasted LLM code without reviewing it it belonged on accidentally quadratic.
It was obvious at first read, but probably not for a beginner. The accidental complexity was hidden behind API calls that weren't wrong, just grossly inefficient.
Problem might be, if you lose the "joy" and the "flow" you'll stop caring about things like that. And software is bloated enough already.
When we outsource the parts of programming that used to demand our complete focus and creativity, do we also outsource the opportunity for satisfaction? Can we find the same fulfillment in prompt engineering that we once found in problem-solving through code?
Most of AI-generated programming content I use are comments/explanations for legacy code, closely followed by tailored "getting started" scripts and iterations on visualisation tasks (for shitty school assignments that want my pyplots to look nice). The rest requires an understanding, which AI can help you achieve faster (it's read many a book related to the topic, so it can recall information a lot like an experienced colleague may), but it can't confer capital K Knowledge or understanding upon you. Some of the tasks it performs are grueling, take a lot of time to do manually, and provide little mental stimulation. Some may be described as lobotomizing and (in my opinion) may mentally damage you in the "Jack Torrance typewriter" kinda way.
It makes me able to work on the fun parts of my job which possess the qualities the article applauds.
The post focuses on flow, but depending on what you mean by it, it isn't necessarily a good thing. Trying to solve something almost too difficult usually gets you out of flow. You still need concentration, though.
My main worry about AI is that people just keep using the garbage that exists instead of trying to produce something better, because AI takes away much of the pain of interacting with garbage. But most people are already perfectly fine using garbage, so probably not much will change here.
I think.. based on recent events.. that some of the corporate inefficiencies are very poorly captured. Last year we had an insane project that was thrown at us before end of the year, because, basically, company had a tiff with the vendor and would rather have us spend our time in meetings trying to do what they are doing rather than pay vendor for that thing. From simple money spent perspective, one would think company's simple amoral compass would be a boon.
AI coding is similar. We just had a minor issue with ai generated code that was clearly not vetted as closely as it should have been making output it generated over a couple of months not as accurate as it should be. Obviously, it had to be corrected, then vetted and so on, because there is always time to correct things...
edit: What I am getting at is the old-fashioned, penny smart, but pound foolish.
Funny that I found this article going to hacker news as a pause in my work : I had to chose between using Aider or my brain to code a small algorithmic task, sorting items of a list based on dependences between items written in a YAML file.
Using Aider would probably solve the task in 5 minutes. Coding it in 30 minutes. The former choice would result in more time for other tasks or reading HN or having a hot beverage or walking in the sun. The second would challenge my rusting algorithmic skills and give me a better understanding of what I'm doing for the medium term.
Hard choice. In any case, I have a good salary, even with the latter option I can decide to spend good times.
Typing isn't what makes programming fun.
AI coding preserves flow more than legacy coding. You never have to go read documentation for an hour. You can continuously code.
Have you encounter anything regarding tech debt when using AI?
Don't see any mention regarding this in the post, which is the common objection people have regarding vibe coding.
I've tried getting different AIs to say something meaningful about code, never got anything of value back so far. They can't even manage tab-completion well enough to be worth the validation effort for me.
Yeah I wonder how do the code look after such professional AI development. I tried ChatGPT 1o to ask it about simple C function - what errors are there. It answered only after I directly asked about the aspects I was expecting it to tell about. It means that if I didn't know that the LLM wouldn't tell me...
“ Fast forward to today, and that joy of coding is decreasing rapidly. Well, I’m a manager these days, so there’s that…”
This sounds a more likely reason for losing your joy if your passion is coding.
in the meantime im having lots of fun coding and using AI, reinventing every wheel i can. 0 stress cos i don't do it for money :). I think a lot of people are having a tantrum because programing is not sexy anymore, its getting easier, the bar is lower now , the quality is awful and nobody cares. its like any other boring soul crushing job.
also if you want to see the real cost (at least part of it) of AI coding or the whole fucked up IT industry, go to any mining town in the global south.
i dont know where you are working, but where I work i cant prompt 90% of my job away using cursor. in fact, I find all of these tools to be more and more useless and our codebase is growing and becoming more complex
based on the current state of AI and the progress im witnessing on a month-by-month basis - my current prediction is there is zero chance AI agents are going to be coding and replacing me in the next few years. if i could short the startups claiming this, I would.
Don't get distracted by claims that AI agents "replace programmers". Those are pure hype.
I'm willing to bet that in a few years most of the developers you know will be using LLMs on a daily basis, and will be more productive because of it (having learned how to use it).
this is already the case.
I have the same experience. It‘s basically a better StackOverflow, but just like with SO you have to be very careful about the replies, and also just like SO its utility diminishes as you get more proficient.
As an example, just today I was trying to debug some weird WebSocket behaviour. None of the AI tools could help, not Cursor, not plain old ChatGPT with lots of prompting and careful phrasing of the problem. In fact every LLM I tried (Claude 3.7, GPT o4-mini-high, GPT 4.5) introduced errors into my debugging code.
I’m not saying it will stay this way, just that it’s been my experience.
I still love these tools though. It’s just that I really don’t trust the output, but as inspiration they are phenomenal. Most of the time I just use vanilla ChatGPT though; never had that much luck with Cursor.
No one was forcing you to use SO, in fact we made fun of people who did copy-paste/compile-coding.
Yeah, they're currently horrible at debugging -- there seems to be blind spots they just can't get past so end up running in circles.
A couple days ago I was looking for something to do so gave Claude a paper ("A parsing machine for PEGs") to ask it some questions and instead of answering me it spit out an almost complete implementation. Intrigued, I threw a couple more papers at it ("A Simple Graph-Based Intermediate Representation" && "A Text Pattern-Matching Tool based on Parsing Expression Grammars") where it fleshed out the implementation and, well... color me impressed.
Now, the struggle begins as the thing has to be debugged. With the help of both Claude and Deepseek we got it compiling and passing 2 out of 3 tests which is where they both got stuck. Round and round we go until I, the human who's supposed to be doing no work, figured out that Claude hard coded some values (instead of coding a general solution for all input) which they both missed. In applying ever more and more complicated solutions (to a well solved problem in compiler design) Claude finally broke all debugging output and I don't understand the algorithms enough to go in and debug it myself.
Of course I didn't use any sort of source code management so I could revert to a previous version before it was broken beyond all fixing...
Honestly, I don't even consider this a failure. I learned a lot more on what they are capable of and now know that you have to give them problems in smaller sections where they don't have to figure out the complexities of how a few different algorithms interact with each other. With this new knowledge in hand I started on what I originally intended to do before I got distracted with Claude's code solution to a simple question.
--edit--
Oh, the irony...
After typing this out and making an espresso I figured out the problem Claude and Deepseek couldn't see. So much for the "superior" intelligence.
One of the ways these tools are most useful for me is in extremely complex codebases.
This has become especially true for me in the past four months. The new long context reasoning models are shockingly good at digging through larger volumes of gnarly code. o3, o4-mini and Claude 3.7 Sonnet "thinking" all have 200,000 token context limits, and Gemini 2.5 Pro and Flash can do 1,000,000. As "reasoning" models they are much better suited to following the chain of a program to figure out the source of an obscure bug.
Makes me wonder how many of the people who continue to argue that LLMs can't help with large existing codebases are missing that you need to selectively copy the right chunks of that code into the model to get good results.
3 replies →
The old joy may be gone. But the new joy is there, if you're receptive to it
And which joy is that? Short sighted profits?
Injecting malware via flaws in the shitty programs, maybe
Earlier this year, a hackernews started quizzing me about the size and scope of the projects I worked on professionally, with the implication that I couldn't really be working on anything large or complex -- that I couldn't really be doing serious development, without using a full-fat IDE like IntelliJ. I wasn't going to dox myself or my professional work just so he could reach a conclusion he's already arrived at. The point is, to this person, beyond a certain complexity threshold -- simple command-line tools, say -- an IDE was a must, otherwise you were just leaving productivity on the table.
https://news.ycombinator.com/item?id=42511441
People are going to be making the same judgements about AI-assisted coding in the near future. Sure, you could code everything yourself for your own personal enrichment, or simply because it's fun. But that will be a pursuit for your own time. In the realm of business, it's a different story: you are either proompting, or you're effectively stealing money from your employer because you're making suboptimal use of the tools available. AI gets you to something working in production so much faster that you'd be remiss not to use it. After all, as Milt and Tim Bryce have shown, the hard work in business software is in requirements analysis and design; programming is just the last translation step.
One of the things people often overlook don't talk about in this arguments is the manager's point of view and how it's contributing to the shakeups in this industry.
As a developer I'm bullish on coding agents and GenAI tools, because they can save you time and can augment your abilities. I've experienced it, and I've seen it enough already. I love them, and want to see them continue to be used.
I'm bearish on the idea that "vibe coding" can produce much of value, and people without any engineering background becoming wildly productive at building great software. I know I'm not alone. If you're a good problem solver who doesn't know how to code, this is your gateway. And you better learn what's happening with the code while you can to avoid creating a huge mess later on.
Developers argue about the quality of "vibe coded" stuff. There are good arguments on both sides. At some point I think we all agree that AI will be able generate high quality software faster than a human, someday. But today is not that day. Many will try to convince you that it is.
Within a few years we'll see massive problems from AI generated code, and it's for one simple reason:
Managers and other Bureaucrats do not care about the quality of the software.
Read it again if you have to. It's an uncomfortable idea, but it's true. They don't care about your flow. They don't care about how much you love to build quality things. They don't care if software is good or bad they care about closing tickets and creating features. Most of them don't care, and have never cared about the "craft".
If you're a master mason crafting amazing brickwork, you're exactly the same as some amateur grabbing some bricks from home depot and slapping a wall together. A wall is a wall. That's how the majority of managers view software development today. By the time that shoddy wall crumbles they'll be at another company anyway so it's someone else's problem.
When I talk about the software industry collapsing now, and in a few years we're mired with garbage software everywhere, this is why. These people in "leadership" are salivating at the idea of finally getting something for nothing. Paying a few interns to "vibe code" piles of software while they high five each other and laugh.
It will crash. The bubble will pop.
Developers: Keep your skills sharp and weather out the storm. In a few years you'll be in high demand once again. When those walls crumble, they will need people who what they're doing to repair it. Ask for fair compensation to do so.
Even if I'm wrong about all of this I'm keeping my skills sharp. You should too.
This isn't meant to be anti-management, but it's based on what I've seen. Thanks for coming to my TED talk.
* And to the original point, In my experience the tools interrupt the "flow" but don't necessarily take the joy out of it. I cannot do suggestion/autocomplete because it breaks my flow. I love having a chat window with AI nearby when I get stuck or want to generate some boilerplate.
I think you are right with the building analogy. Most stuff built in the last 25 years is crap quality! But importantly looks nice. Needs to look nice at first.
> If you're a master mason crafting amazing brickwork, you're exactly the same as some amateur grabbing some bricks from home depot and slapping a wall together.
IDK, there's still a place in society for master masons to work on 100+ year old buildings built by other master masons.
Same with the robots. They can implement solutions but I'm not sure I've heard of any inventing an algorithmic solution to a problem.
So if I'm understanding this, there are two central arguments being made here.
1. AI Coding leads to a lack of flow.
2. A lack of flow leads to a lack of joy.
Personally, I can't find myself agreeing with the first argument. Flow happens for me when I use AI. It wouldn't surprise me if this differed developer to developer. Or maybe it is the size of requests I'm making, as mine tend to be on the smaller size where I already have an idea of what I want to write but think the AI can spit it out faster. I also don't really view myself as prompt engineering; instead it feels more like a natural back and forth with the AI to refine the output I'm looking for. There are times it gets stubborn and resistant to change but that is generally a sign that I might want to reconsider using AI for that particular task.
One trend I've been finding interesting over the past year is that a lot of engineers I know who moved into engineering management are writing code again - because LLMs mean they can get something productive done in a couple of hours where previously it would have taken them a full day.
Managers usually can't carve out a full day - but a couple of hours is manageable.
See also this quote from Gergely Orosz:
From https://x.com/GergelyOrosz/status/1914863335457034422
This is also true of (technical) product managers from an engineering background.
It's been amazing to spin up quick React prototypes during a lunch break of concepts and ideas for quick feedback and reactions.
Yeah I think flow is more about holding a lot of knowledge about the code and its control flow in your head at a time. I think there's an XKCD or something that illustrates that.
You still need to do that if you're using AI, otherwise how do you know if it's actually done a good job? Or are people really just vibe coding without even reading the code at all? That seems... unlikely to work.
The catch is that when AI handles 95% or 99% of a task, people say great, don't need humans. 99% is great.
But when that last 1% breaks and AI can’t fix it. That’s where you need the humans.
By then the price will have increased quite a bit; if you want me to fix your AI crap, you're going to pay until it hurts.