Sounds about right, but consider also that music, painting, sculpture, theatre are all simultaneously (1) hobbies requiring great skill to master and which people dervive much joy from, and (2) are experiences that can be bought for a pittance as a download, a "print your own {thing}" shop, 3D printing etc., or YouTube.
The bathwater of economics will surely dirty, but you don't need to throw out the baby of hobbies with it.
I can really relate to the feeling described after modifying save files to get more resources in a game, but I wonder if it's the same kind of 'cheating'.
Doing better in a game has its own associsted feeling of achievement, and cheating definitely robs you of that, which to me explains why playing will be less fun.
Moving faster on a side project or at work doesn't feel like the same kind of shortcut/cheat. Most of us no longer program in assembly language, and we still maintain a sense of achievement using elite languages, which naturally abstract away a lot of the details.
Isn't using AI to hide away implementation details just a natural next step, where instead of lengthy error prone machine level code, you have a few modern language instructions?
I see your point, and tend to agree. However, at least for the time being, I see the AI tools not inherently different than refactoring tools which were available over a decade ago. It helps me move faster, and I feel like it's one more tool I need to master, so it will be useful in my toolbox.
Some existential objections occur; how sure are we that there isn't an infinite regress of ever deeper games to explore? Can we claim that every game has an enjoyment-nullifying hack yet to discover with no exceptions? If pampered pet animals don't appear to experience the boredom we anticipate is coming for us, is the expectation completely wrong?
I don't really see it. At least the article should address why we would not assume massive price drops, market adjusted pricing and free offerings, as with all other innovation before, that all lead to wider access to better technology.
I feel the same with a lot of points made here, but hadn't yet thought about the financial one.
When I started out with web development that was one of the things I really loved. Anyone can just read about html, css and Javascript and get started with any kind of free to use code editor.
Though you can still do just that, it seems like you would always drag behind the 'cool guys' using AI.
You still don’t need AI to write software, but investing in it will make you more productive. More money enables you to buy better tools, that was always true for any trade. My friend is a woodworker and his tools are 5-10x more expensive than what I have in my shack, but are also more precise, more reliable and easier to use. AI is the same, I would even argue it gives you a bigger productivity boost with less money (especially given that local models are getting better literally every week).
Incredible take considering using AI robs new learners of off real learning. There is a reason lots of experienced devs are dropping it from their editors. Using AI will not make you a better dev, it simply accelerates you building a failing product faster, because ultimately you wont understand your own product. Most devs that use AI blindly trust it instead of questioning what it produces.
> Most devs that use AI blindly trust it instead of questioning what it produces.
Without the punctuation, I first read it tautologically as "Most devs that use AI blindly, trust it instead of questioning what it produces". But even assuming you meant "Most devs that use AI, blindly trust it instead of questioning what it produces", there's still a negative feedback loop. We're still at the early experimentation phase, but if/when AI capabilities eventually settle down, people will adapt, learning when and when not they can trust the AI coder and when to take the reins - that would be the skill that people are hired for.
Alternatively, we could be headed towards an intelligence explosion, with AI growing in capabilities until it surpasses human coders at almost all types of coding work, except perhaps for particular tasks which the AI dev could then delegate to a human.
Because I dont want to work with AI agents? I like my work to be fun, as in "I could bear working 8 hours a day with this."
I like thinking about the problems and solutions and how that translates to code. I like implementing it with my own hands. Substitute that with writing prompts and I'll look for a different career thats actually fun.
Because it already is a thing? Some companies already force AI upon their devs. And weird, I still need to pay my bills so yea, I need a career to do so.
These platforms all feel like they are being massively subsidized right now. I'm hoping that continues and they just burn investor cash in a race to the bottom.
All articles of this class, whether positive or negative, begin "I was working on a hobby project" or some variation thereof.
The purpose of hobbies is to be a hobby, archetypical tech projects are about self-mastery. You cannot improve your mastery with a "tool" that robs you of most of the minor and major creative and technical decisions of the task. Building IKEA furniture will not make you a better carpenter.
Why be a better carpenter? Because software engineering is not about hobby projects. It's about research and development at the fringes of a business (, orgs, projects...) requirements -- to evolve their software towards solving them.
Carpentry ("programming craft") will always (modulo 100+ years) be essential here. Powertools do not reduce the essential craft, they increase the "time to craft being required" -- they mean we run into walls of required expertise faster.
AI as applied to non-hobby projects -- R&D programming in the large -- where requirements aren't specified already as prior art programs (of func & non-func variety, etc.) ---- just accelerates the time to hitting the wall where you're going to shoot yourself in the foot if you're not an expert.
I have not seen a single take by an experienced software engineer have a "sky is falling" take, ie., those operating at typical "in the large" programming scales, in typical R&D projects (revision to legacy, or greenfield -- just reqs are new).
I think it also misses the way you can automate non-trivial tasks. For example, I am working on a project where there is tens of thousands of different data sets each with their own meta data and structure but the underlying data is mostly the same. But because the meta data and structure are all different, it’s really impossible to combine all this data into one big data set without a team of engineers going through each data set and meticulously restructuring and conforming said metadata to a new monolithic schema. However I don’t have any money to hire that team of engineers. But I can massage LLMs to do that work for me. These are ideal tasks for AI type algorithms to solve. It makes me quite excited for the future as many of these kind of tasks could be given to ai agents that would otherwise be impossible to do yourself.
I agree, but only for situations where the probabilistic nature is acceptable. It would be the same if you had a large team of humans doing the same work. Inevitably misclassifications would occur on an ongoing basis.
Compare this to the situation where you have a team develop schemas for your datasets which can be tested and verified, and fixed in the event of errors. You can't really "fix" an LLM or human agent in that way.
So I feel like traditionally computing excelled at many tasks that humans couldn't do - computers are crazy fast and don't make mistakes, as a rule. LLMs remove this speed and accuracy, becoming something more like scalable humans (their "intelligence" is debateable, but possibly a moving target - I've yet to see an LLM that I would trust more than a very junior developer). LLMs (and ML generally) will always have higher error margins, it's how they can do what they do.
Yes but i see it as multiple steps. Like perhaps the llm solution has some probabilistic issues that only get you 80% of the way there. But that probably already has given you some ideas how to better solve the problem. And this case the problem is somewhat intractable because of the size and complexity of the way the data is stored. So like in my example the first step is LLMs but the second step would be to use what they do as structure for building a deterministic pipeline. This is because the problem isn’t that there are ten thousand different meta data, but that the structure of those metadata are diffuse. The llm solution will first help identify the main points of what needs to be conformed to the monolithic schema. Then I will build more production ready and deterministic pipelines. At least that is the plan. I’ll write a substack about it eventually if this plan works haha.
I'm reminded of the game Factorio: Essentially the entire game loop is "Do a thing manually, then automate it, then do the higher-level thing the automation enables you to do manually, then automate that, etc etc"
So if you want to translate that, there is value in doing a processing step manually to learn how it works - but when you understood that, automation can actually benefit you, because only then are you even able to do larger, higher-level processing steps "manually", that would take an infeasible amount of time and energy otherwise.
Where I'd agree though is that you should never lose the basic understanding and transparency of the lower-level steps if you can avoid that in any way.
> I have not seen a single take by an experienced software engineer have a "sky is falling" take,
Let me save everybody some time:
1. They're not saying it because they don't want to think of themselves as obsolete.
2. You're not using AI right, programmers who do will take your job.
3. What model/version/prompt did you use? Works For Me.
But seriously: It does not matter _that_ much what experienced engineers think. If the end result looks good enough for laymen and there's no short term negative outcomes, the most idiotic things can build up steam for a long time. There is usually an inevitable correction, but it can take decades. I personally accept that, the world is a bit mad sometimes, but we deal with it.
My personal opinion is pretty chill: I don't know if what I can do will still be needed n years from now. It might be that I need to change my approach, learn something new, or whatever. But I don't spend all that much time worrying about what was, or what will be. I have problems to solve right now, and I solve them with the best options available to me right now.
People spending their days solving problems probably generally don't have much time to create science fiction.
The part before "But seriously" was sarcasm. I find it very odd to assume that a professional developer (even if it's not what they would describe as their field) is using it wrong. But it's a pretty standard reply to measured comments about LLMs.
> I find it very odd to assume that a professional developer (even if it's not what they would describe as their field) is using it wrong.
They're encountering a type of tool they haven't met before and haven't been trained to use. The default assumption is they are probably using it wrong. There isn't any reason to assume they're using it right - doing things wrong is the default state of humans.
I've used Claude-Code & Roo-Code plenty of times with my hobby projects.
I understand what the article means, but sometimes I've got the broad scopes of a feature in my head, and I just want it to work. Sometimes programming isn't like "solving a puzzle", sometimes it's just a huge grind. And if I can let an LLM do it 10 times faster, I'm quite happy with that.
I've always had to fix up the code one way or another though. And most of the times, the code is quite bad (even from Claude Sonnet 3.7 or Gemini Pro 2.5), but it _did_ point me in the right direction.
About the cost: I'm only using Gemini Pro 2.5 Experimental the past few weeks. I get to retry things so many times for free, it's great. But if I had to actually pay for all the millions upon millions of used tokens, it would have cost me *a lot* of money, and I don't want to pay that. (Though I think token usage can be improved a lot, tools like Roo-Code seem very wasteful on that front)
>Why bother playing when I knew there was an easier way to win? This is the exact same feeling I’m left with after a few days of using Claude Code. I don’t enjoy using the tool as much as I enjoy writing code.
My experience has been the opposite. I've enjoyed working on hobby projects more than ever, because so many of the boring and often blocking aspects of programming are sped up. You get to focus more on higher level choices and overall design and code quality, rather than searching specific usages of libraries or applying other minutiae. Learning is accelerated and the loop of making choices and seeing code generated for them, is a bit addictive.
I'm mostly worried that it might not take long for me to be a hindrance in the loop more than anything. For now I still have better overall design sense than AI, but it's already much better than I am at producing code for many common tasks. If AI develops more overall insight and sense, and the ability to handle larger code bases, it's not hard to imagine a world where I no longer even look at or know what code is written.
Everyone has different objective and subjective experiences, and I suspect some form of selection will promote those who more often feel excited and relieved by using AI than those who feel it more often a negative, like it challenges some core aspect of self.
It might challenge us, and maybe those of us who feel challenged in that way need to rise to it, for there are always harder problems to solve
If this new tool seems to make things so easy it's like "cheating", then make the game harder. Can't cheat reality.
Without AI, I have been in a company where the general mentality was to "ship bad software but quickly". Without going into the debate of whether it was profitable in the long term or not (spoiler: it was not), my problem was the following:
I would try to build something "good" (not "perfect", just "good", like modular or future-proof or just not downright malpractice). But while I was doing this, others would build crap. They would do it so fast I couldn't keep up. So they would "solve" the problems much faster. Except that over the years, they just accumulated legacy and had to redo stuff over and over again (at some point you can't throw crap on top of crap, so you just rebuild from scratch and start with new crap, right?).
All that to say, I don't think that AIs will help with that. If anything, AIs will help more people behave like this and produce a lot of crap very quickly.
I can't see why it's a bitter prediction. It's an observation from all my life that boring, mind-numbing but high impact work makes the best money. Now smart people go into coding because it's a thrill, they enjoy doing it for the sake of it. Once this is no longer the case, these people will be out, and competition will become lower and there will be easier bucks to make.
To me it’s the exact opposite. I was writing code for the past 20+ years and I recently realized it’s not the act of writing code I love, but the act of creating something from nothing. Over the past few months I wrote two non-trivial utility apps that otherwise I would most probably not write because I didn’t have enough time to do that, but Cursor + Claude gave me the 5x productivity boost that enabled me to do so, and I really enjoyed doing that.
My only gripe is that the models are still pretty slow, and that discourages iteration and experimentation. I can’t wait for the day a Claude 3.5 grade model with 1000 tok/s speed releases, this will be a total game changer for me. Gemini 2.5 recently came closer, but it’s still not there.
I've kinda hit the same place. I thought I loved writing code, but I so often start projects and don't finish once the excitement of writing all the code wears off. I'm realizing it is designing and architecting that I love, and seeing that get built, not writing every line of code. I also am enjoying AI as my velocity has solidly improved.
Another area I find very helpful is when I need to use the same technique in my code as someone from another language. No longer do I need to spend hours figuring out how they did it. I just ask an AI and have them explain it to me and then often simply translate the code.
For me it's a bit of both. I'm working on exciting energy software with people who have deep knowledge of the sector but only semi-decent software knowledge. Nearly every day I'm reviewing some shitty PR comprised of awful, ugly code that somehow mostly works.
The product itself is exciting and solves a very real problem, and we have many customers who want to use it and pay for it. But damn, it hurts my soul knowing what goes on under the hood.
The challenge I often face is having an entire _mental model_ of what I want to build already crystallized in my head, but then the realization that it will take hours of coding to actually convert that to code... That can be incredibly demotivating.
I'm not following the logic here. There are tons of free tier AI products available. That makes the world more fair for people in very poor countries not less.
Lots of models are free, and useful even, but the best ones are not.
I'm not sure how much RAM is on the average smartphone owned by someone earning $5/day*, but it's absolutely not going to be the half a terabyte needed for the larger models whose weights you can just download.
It will change, but I don't know how fast.
* I kinda expect that to be around the threshold where they will actually have a smartphone, even though the number of smartphones in the world is greater than the number of people
I'm possibly doing it wrong, but that hasn't quite been my experience. While with vibe coding I do still get to express my creativity, my biggest role in this creative partnership still seems to be copy and pasting console error messages and screenshots back to the LLM.
A relative known youtuber called the primeagen has recently done a challenge sponsored by Cursor themselves where he and some friends would "vibe code" a game in a week. The results were pretty underwhelming. They would have been much faster not using generative Ai.
Compared what you see from game jams where sometimes solo devs create whole games in just a few days it was pretty trash.
It also tracks with my own experience. Yes, cursor quickly helps me get the first 80% done but then I spent so much time cleaning after it that I have barely saved any time in total.
For personal projects where you don't care about code quality I can see it as a great tool. If you actual have professional standards, no. (Except maybe for unit tests, I hate writing those by hand.)
Most of the current limitation CAN be solved by throwing even more compute at it. Absolutely. The question is will it economically make sense? Maybe if fusion becomes viable some day but currently with the end of fossil fuels and climate change? Is generative Ai worth destroying our planet for?
At some point the energy consumption of generative AI might get so high and expensive that you might be better off just letting humans do the work.
I used it as an example because the event was sponsored by Cursor so I figured they had an interest in making the product look good. And they really failed at this.
The again primeagen is pretty critical of vibe coding so it was super weird match up anyway. I guess they decided to just have some fun. Maybe advertise the vibe coding "lifestyle" more so than the technical merit of the product.
Oh, it isn't the usual content for primeagen. He mostly reacts to other technical videos and articles and rants about his love for neovim and ziglang. He has ok takes most of the time and is actually critical of the overuse of generative Ai. But yeah, he is not a technical deep dive youtuber but more for entertainment.
I feel most people drastically underestimate game dev. The programming aspect is only one tiny part of it and even there it goes so wide (from in-game logic to rendering to physics) that it's near impossible for people who are not really deep into it to have a clue what is happening. And even if you manage to vibe-code your way through it, your game will still suck unless you have good assets - which means textures, models, animations, sounds, FX... you get it. Developing a high quality game is sort of the ultimate test for AI and if it achieves it on a scale beyond game jams we might as well accept that we have reached artificial superintelligence.
To be fair, the whole "vibe coding" thing is really really new stuff. It will undoubtedly take some time to optimize how to actually effectively do it.
Recently, we've seen a lot of a shift in insight into not just diving straight into implementation, but actually spending time on careful specification, discussion and documentation either with or without an AI assistant before setting it loose to implement stuff.
For large, existing codebases, I sincerely believe that the biggest improvements lie in using MCP and proper instructions to connect the AI assistants to spec and documentation. For new projects I would put pretty much all of that directly into the repos.
> A relative known youtuber called the primeagen has recently done a challenge sponsored by Cursor themselves where he and some friends would "vibe code" a game in a week. The results were pretty underwhelming. They would have been much faster not using generative Ai.
I ended up watching maybe 10 minutes of these streams on two separate occasions, and he was writing code manually 90% of the time on both occasions, or yelling at LLM output.
I'm more and more confident I must be doing something wrong. I (re)tried using Claude about a month ago and I simply stopped using it after about two weeks because on one hand productivity did not increase(perhaps even decreased), but on the other hand it made me angry because of the time wasted on its mistakes. I was also mostly using it on Rust code, so I'm even more surprised about the article. What am I doing wrong? I've been mostly using the chat functionality and auto-complete, is there some kind of secret feature I'm missing?
I'd love to watch a video of someone using these tools well, because I am not getting much out of it. They save some time, sometimes, but they're nowhere near the 5x boost that some people claim.
The author tell his experience regarding his joy programming things and figuring stuff out. In the end he says that AI made him lose this joy, and he compares it to cheating in a game. He does not say one word about societal impact and or the amount of engineers in the future, it's what you interpreted yourself.
“ In some countries, more than 90% of the population lives on less than $5 per day. If agentic AI code generation becomes the most effective way to write high-quality code, this will create a massive barrier to entry”
> The author is essentially arguing that fewer people will be able to build software in the future.
You comment is talking about ability to build software, vs. the article (in only a single sentence that references this topic, while the other 99% circles around something else) talks about the job market situation. If what you wanted so say "The author is arguing that people will probably have a harder time getting a job in software development", that would have been correct.
> That's the opposite of what's happened over the past year or two. Now many more non-technical people can (and are) building software.
You're (based on the new comment) explicitly saying that people without technical knowledge are getting jobs in software development sector. Where did you get that info from? Would be an interesting read for sure, if it's actually true.
> The author is essentially arguing that fewer people will be able to build software in the future.
Setting aside the fact that the author nowhere says this, it may in fact be plausible.
> That's the opposite of what's happened over the past year or two. Now many more non-technical people can (and are) building software.
Meanwhile half[0] the students supposed to be learning to build software in university will fail to learn something important because they asked Claude instead of thinking about it. (Or all the students using llms will fail to learn something half the time, etc.)
> Not only that, the generated code was high-quality, efficient, and conformed to my coding guidelines. It routinely "checked its work" by running unit tests to eliminate hallucinations and bugs.
This seems completely out of whack with my experience of AI coding. I'm definitely in the "it's extremely useful" camp but there's no way I would describe its code as high quality and efficient. It can do simple tasks but it often gets things just completely wrong, or takes a noob-level approach (e.g. O(N) instead of O(1)).
Is there some trick to this that I don't know? Because personally I would love it if AI could do some of the grunt work for me. I do enjoy programming but not all programming.
I use the same with a sprinkling of Gemini 2.5 and Grok3.
I find it they all make errors, but 95% of them I spot immediately by eye and either correct manually or reroll through prompting.
The error rate has gone down in the last 6 months, though, and the efficiency of the C# code I mostly generate has gone up by an order of magnitude. I would rarely produce code that is more efficient than what AI produces now.
(I have a prompt though that tells it to use all the latest platform advances and to search the web first for the latest updates that will increase the efficiency and size of the code)
The hardware for AI is getting cheaper and more efficient, and the models are getting less wasteful too.
Just a few years ago GPT-3.5 used to be a secret sauce running on the most expensive GPU racks, and now models beating it are available with open weights and run on high end consumer hardware. Few iterations down the line good-enough models will run on average hardware.
When that Xcom game came out, filmmaking, 3D graphics, and machine learning required super expensive hardware out of reach of most people. Now you can find objectively better hardware literally in the trash.
Moore's law is withering away due to physical limitations. Energy prices go up because of the end of fossil fuels and rising climate change costs. Furthermore the global supply chain is under attack by rising geopolitical tension.
Depending on US tariffs and how the Taiwan situation plays out and many other risks, it might be that compute will get MORE expensive in the future.
While there is room for optimization on the generative AI front we are still have not even reached the point were generative AI is actually good at programming. We have promising toys but for real productivity we need orders of magnitude bigger models. Just look how ChatGPT 4.5 is barely economically viable already with its price per token.
Sure if humanity survives long enough to widely employ fusion energy, it might become practical and cheap again but that will be a long and rocky road.
LLMs on GPUs have a lot of computational inefficiencies and untapped parallelism. GPUs have been designed for more diverse workloads with much smaller working sets. LLM inference is ridiculously DRAM-bound. We currently have 10×-200× too much compute available compared to the DRAM bandwidth required. Even without improvements in transistors we can get more efficient hardware for LLMs.
The way we use LLMs is also primitive and inefficient. RAG is a hack, and in most LLM architectures the RAM cost grows quadratically with the context length, in a workload that is already DRAM-bound, on a hardware that already doesn't have enough RAM.
> Depending on US tariffs […] end of fossil fuels […] global supply chain
It does look pretty bleak for the US.
OTOH China is rolling out more than a gigawatt of renewables a day, has the largest and fastest growing HVDC grid, a dominant position in battery and solar production, and all the supply chains. With the US going back to mercantilism and isolationism, China is going to have Taiwan too.
I think there’s a huge amount of inefficiency all the way through the software stack due to decades of cheap energy and rapidly improving hardware. I would expect with hardware and energy constraints that we will need to look for deeper optimisations in software.
Costs for a given amount of intelligence as measured by various benchmarks etc has been falling by 4-8x per year for a couple years, largely from smarter models from better training at a given size. I think there's still a decent amount of headroom there, and as others have mentioned dedicated inference chips are likely to be significantly cheaper than running inference on GPUs. I would expect to see Gemini Pro 2.5 levels of capability in models that cost <$1/Mtok by late next year or plausibly sooner.
I may be old, but I had the same feeling for low-level code. I enjoyed doing things like optimizing a low-level loop in C or assembly, bootstrapping a microcontroller, or writing code for a processor which didn't have a compiler yet. Even in BASIC, I enjoyed PEEKing and POKE'ing. I enjoyed opening up a file system in a binary editor. I enjoyed optimizing how my computer draws a line.
All this went away. I felt a loss of joy and nostalgia for it. It was bitter.
Still think amazement of ai tools as harsh as it sounds signals incompetence of the user. They are useful don’t get me wrong but just today Claude wrote code that literally wouldnt run.
Thought it’s ok to use new for object literal in JS.
It's not true that coding would no longer be fun because of AI. Arithmetic did not stop being fun because of calculators. Travel did not stop being fun because of cars and planes. Life did not stop being fun because of lack of old challenges.
New challenges would come up. If calculators made the arithmetic easy, math challenges move to next higher level. If AI does all the thinking and creativity, human would move to next level. That level could be some menial work which AI can't touch. For example, navigating the complexities of legacy systems and workflows and human interactions needed to keep things working.
I find legacy systems fun because you're looking at an artefact built over the years by people. I can get a lot of insight into how a system's design and requirements changed over time, by studying legacy code. All of that will be lost, drowned in machine-generated slop, if next decade's legacy code comes out the backside of a language model.
thanks to git repositories stored away in arctic tunnels our common legacy code heritage might outlast most other human artifacts.. (unless ASI choses to erase that of course)
Legacy archaeology in a 60MiB codebase far easier than digging through email archives, requirements docs, and old PowerPoint files that Microsoft Office won't even open properly any more (though LibreOffice can, if you're lucky). Handwritten code actually expresses something about the requirements and design decisions, whereas AI slop buries that signal in so much noise and makes "archaeology" almost impossible.
When insight from a long-departed dev is needed right now to explain why these rules work in this precise order, but fail when the order is changed, do you have time to git bisect to get an approximate date, then start trawling through chat logs in the hopes you'll happen to find an explanation?
Code is code, yes it can be more or less spaghetti but if it compiles at all, it can be refactored.
Having to dig through all that other crap is unfortunate. Ideally you have tests that encapsulate the specs, which are then also code. And help with said refactors.
We had enough tests to know that no other rule configuration worked. Heck, we had mathematical proof (and a small pile of other documentation too obsolete or cryptic to be of use), and still, the only thing that saved the project was noticing different stylistic conventions in different parts of the source, allowing the minor monolith to be broken down into "this is the core logic" and "these are the parts of a separate feature that had to be weaved into the core logic to avoid a circular dependency somewhere else", and finally letting us see enough of the design to make some sense out of the cryptic documentation. (Turns out the XML held metadata auxiliary to the core logic, but vital to the higher-level interactive system, the proprietary binary encoding was largely a compression scheme to avoid slowing down the core logic, and the system was actually 8-bit-clean from the start – but used its own character encoding instead of UTF-8, because it used to talk to systems that weren't.)
Test-driven development doesn't actually work. No paradigm does. Fundamentally, it all boils down to communication: and generative AI systems essentially strip away all the "non-verbal" communication channels, replacing them with the subtext equivalent of line noise. I have yet to work with anyone good enough at communicating that I can do without the side-channels.
> generative AI systems essentially strip away all the "non-verbal" communication channels
This is a human problem, not a technological one.
You can still have all your aforementioned broken powerpoints etc and use AI to help write code you would’ve previously written simply by hand.
If your processes are broken enough to create unmaintainable software, they will do so regardless of how code pops into existence. AI just speeds it up either way.
The software wasn't unmaintainable. The PowerPoints etc were artefacts of a time when everyone involved understood some implicit context, within which the documentation was clear (not cryptic) and current (not obsolete). The only traces of that context we had, outside the documentation, were minor decisions made while writing the program: "what mindset makes this choice more likely?", "in what directions was this originally designed to extend?", etc.
Personally, I'm in the "you shouldn't leave vital context implicit" camp; but in this case, the software was originally written by "if I don't already have a doctorate, I need only request one" domain experts, and you would need an entire book to provide that context. We actually had a half-finished attempt – 12 names on the title page, a little over 200 pages long – and it helped, but chapter 3 was an introduction-for-people-who-already-know-the-topic (somehow more obscure than the context-free PowerPoints, though at least it helped us decode those), chapter 4 just had "TODO" on every chapter heading, and chapter 5 got almost to the bits we needed before trailing off with "TODO: this is hard to explain because" notes. (We're pretty sure they discussed this in more detail over email, but we didn't find it. Frankly, it's lucky we have the half-finished book at all.)
AI slop lacks this context. If the software had been written using genAI, there wouldn't have been the stylistic consistency to tell us we were on the right track. There wouldn't have been the conspicuous gap in naming, elevating "the current system didn't need that helper function, so they never wrote it" to a favoured hypothesis, allowing us to identify the only possible meaning of one of the words in chapter 3, and thereby learn why one of those rules we were investigating was chosen. (The helper function would've been meaningless at the time, although it does mean something in the context of a newer abstraction.) We wouldn't have been able to used a piece of debugging code from chapter 6 (modified to take advantage of the newer debug interface) to walk through the various data structures, guessing at which parts meant what using the abductive heuristic "we know it's designed deliberately, so any bits that appear redundant probably encode a meaning we don't yet understand".
I am very glad this system was written by humans. Sure, maybe the software would've been written faster (though I doubt it), but we wouldn't have been able to understand it after-the-fact. So we'd have had to throw it away, rediscover the basic principles, and then rewrite more-or-less the same software again – probably with errors. I would bet a large portion of my savings that that monstrosity is correct – that if it doesn't crash, it will produce the correct output – and I wouldn't be willing to bet that on anything we threw together as a replacement. (Yes, I want to rewrite the thing, but that's not a reasoned decision based on the software: it's a character trait.)
I guess I just categorically disagree that a codebase is impossible to understand without “sufficient” additional context. And I think you ascribe too much order to software written by humans that can exist in quite varied groups wrt ability, experience, style, and care.
It was easy to understand what the code was instructing the computer to do. It was harder to understand what that meant, why it was happening, and how to change it.
A program to calculate payroll might be easy to understand, but unless you understand enough about finance and tax law, you can't successfully modify it. Same with an audio processing pipeline: you know it's doing something with Fourier transforms, because that's what the variable names say, but try to tweak those numbers and you'll probably destroy the sound quality. Or a pseudo-random number generator: modify that without understanding how it works, and even if your change feels better, you might completely break it. (See https://roadrunnerwmc.github.io/blog/2020/05/08/nsmb-rng.htm..., or https://redirect.invidious.io/watch?v=NUPpvoFdiUQ if you want a few more clips.)
I've worked with codebases written by people with varying skillsets, and the only occasions where I've been confused by the subtext have been when the code was plagiarised.
> [The] problem is that the sole medium of transport here for the intent of what the user wanted the language model to write and what we see is the output of the language model. And that in itself is a bit of a problem: had we hand-written code, we could look at what it tries to do; it would have suggestive names, maybe even comments, stemming from the user's original intent, and not from an LLM's interpretation of what the user told it was their intent. Basically, LLMs are intent-obfuscating machines for engineering problems :)
Makes me think that the actual horrific solution here is that every single prompt and output ever made while developing must be logged and stored. As that might be only documentation that exist for what was made.
Actually really thinking, if I was running company allowing or promoting AI use that would be first priority. Whatever is prompted, must be stored forever.
> "All of that will be lost, drowned in machine-generated slop, if next decade's legacy code comes out the backside of a language model."
The fun part though is that future coding LLMs will eventually be poisoned by ingesting past LLM generated slop code if unrestricted. The most valuable code bases to improve LLM quality in the future will be the ones written by humans with high quality coding skills that are not reliant or minimally reliant on LLMs, making the humans who write them more valuable.
Think about it: A new, even better programming language is created like Sapphire on Skates or whatever. How does a LLM know how to output high quality idiomatically correct code for that hot new language? The answer is that _it doesn't_. Not until 1) somebody writes good code for that language for the LLM to absorb and 2) in a large enough quantity for patterns to emerge that the LLM can reliably identify as idiomatic.
> New challenges would come up. If calculators made the arithmetic easy, math challenges move to next higher level. If AI does all the thinking and creativity, human would move to next level. That level could be some menial work which AI can't touch. For example, navigating the complexities of legacy systems and workflows and human interactions needed to keep things working.
You’re gonna work on captcha puzzles and you’re gonna like it.
The idea of "breaking the game" here is similar to that expressed in this other recent post: https://news.ycombinator.com/item?id=43650656 . The focus here is a bit different though.
> It makes economic sense, and capitalism is not sentimental.
I find this kind of fatalism irritating. If capitalism isn't doing what we as humans want it to do, we can change it.
The thing is: the industry does not need people who are good at (or enjoy) programming, it needs people who are good at (and enjoy) generating value for customers through code.
So the OP was in a bad place without Claude anyways (in industry at least).
This realization is the true bitter one for many engineers.
I think the lifelong dream of many businesspeople is to create the perfect "cog in the machine" or ideally run a business without workers at all. (Tony Stark, Elon Musk's role model, is a good example of that. As far as the movies are concerned, he builds all his most important inventions himself, or with the help of AI, no workers involved)
Independent of what AI can do today, I suspect this was a reason why so many resources were poured into its development in the first place. Because this was the ultimate vision behind it.
I do believe it's a bad thing, for a number of general reasons. But as far as the US specifically is concerned, I think a society can pick one out of the following two:
(1) Define people's worth through labour.
(2) See labour as a cost center that should be eliminated wherever possible.
US politicians and technologists are trying to have it both ways: Oppose a social safety net out of principle as to "not encourage leechers", forcing people to work, but at the same time seek to reduce the opportunities for work as much as possible. AI is the latest and potentially most far-reaching implementation of that.
>so the industry better look for people who enjoy programming
Why? Both AI and outsourcing provide a much cheaper way to get programming done. Why would you pay someone 100k because he likes doing what an AI or an Indian dev Team can do for much cheaper?
Writing software will never again be a skill worth 100k a year.
I am sure Software developers are here to stay, but nobody who just writes software is worth anywhere close to 100k a year. Either AI or outsourcing is making sure of that.
Which is not true, writing software will continue to be a skill worth millions, even billions. But yeah, as we will soon have hundreds of millions of programmers, on avg 100k will be a thing of the past :)
The author is doing the math the wrong way. For an extra $5/day, a 3rd world country can now pay an engineer $20/day to do the job of a junior engineer in a 1st world one.
The bitter lesson is going to be for junior engineers who see less job offers and don’t see consulting power houses eat their lunch.
Yes, my thoughts at the end of the article. If the AI coding is really good (or will be really, really good) you could give 6 figures salary + $5/d in OpenAI credits to a Bay Area developer, OR you give $5/d salary + $5/d in OpenAI credits to someone else from another country.
Thing is, manufacturing physical goods mean you have to physically move them around. Digital goods don't have that problem. Timezones are what's proving to be challenging though.
100%. You can offshore "please write code doing X for me" but it's much harder to offshore "please generate value for my customers with this codebase" which is a lot closer to what software engineers actually do.
Therefore, I do not anticipate a massive offshoring of software like what happened in manufacturing. Yet, a lot of software work can be fully specified and will be outsourced.
150 dollars/month as salary won't get you no one from no country and if it happens to, the person will have so many things to figure out (war, hunger, political instability) that they would obviously not be productive.
188 comments
[ 4.4 ms ] story [ 260 ms ] threadThe bathwater of economics will surely dirty, but you don't need to throw out the baby of hobbies with it.
Depends whether you're in it for the endgame or the journey.
For some the latter is a means to the former, and for others it's the other way around.
https://www.fictionpress.com/s/3353977/1/The-End-of-Creative...
Some existential objections occur; how sure are we that there isn't an infinite regress of ever deeper games to explore? Can we claim that every game has an enjoyment-nullifying hack yet to discover with no exceptions? If pampered pet animals don't appear to experience the boredom we anticipate is coming for us, is the expectation completely wrong?
Why would this be the exception?
I feel the same with a lot of points made here, but hadn't yet thought about the financial one.
When I started out with web development that was one of the things I really loved. Anyone can just read about html, css and Javascript and get started with any kind of free to use code editor.
Though you can still do just that, it seems like you would always drag behind the 'cool guys' using AI.
Without the punctuation, I first read it tautologically as "Most devs that use AI blindly, trust it instead of questioning what it produces". But even assuming you meant "Most devs that use AI, blindly trust it instead of questioning what it produces", there's still a negative feedback loop. We're still at the early experimentation phase, but if/when AI capabilities eventually settle down, people will adapt, learning when and when not they can trust the AI coder and when to take the reins - that would be the skill that people are hired for.
Alternatively, we could be headed towards an intelligence explosion, with AI growing in capabilities until it surpasses human coders at almost all types of coding work, except perhaps for particular tasks which the AI dev could then delegate to a human.
What makes you think that will be necessary?
The purpose of hobbies is to be a hobby, archetypical tech projects are about self-mastery. You cannot improve your mastery with a "tool" that robs you of most of the minor and major creative and technical decisions of the task. Building IKEA furniture will not make you a better carpenter.
Why be a better carpenter? Because software engineering is not about hobby projects. It's about research and development at the fringes of a business (, orgs, projects...) requirements -- to evolve their software towards solving them.
Carpentry ("programming craft") will always (modulo 100+ years) be essential here. Powertools do not reduce the essential craft, they increase the "time to craft being required" -- they mean we run into walls of required expertise faster.
AI as applied to non-hobby projects -- R&D programming in the large -- where requirements aren't specified already as prior art programs (of func & non-func variety, etc.) ---- just accelerates the time to hitting the wall where you're going to shoot yourself in the foot if you're not an expert.
I have not seen a single take by an experienced software engineer have a "sky is falling" take, ie., those operating at typical "in the large" programming scales, in typical R&D projects (revision to legacy, or greenfield -- just reqs are new).
Compare this to the situation where you have a team develop schemas for your datasets which can be tested and verified, and fixed in the event of errors. You can't really "fix" an LLM or human agent in that way.
So I feel like traditionally computing excelled at many tasks that humans couldn't do - computers are crazy fast and don't make mistakes, as a rule. LLMs remove this speed and accuracy, becoming something more like scalable humans (their "intelligence" is debateable, but possibly a moving target - I've yet to see an LLM that I would trust more than a very junior developer). LLMs (and ML generally) will always have higher error margins, it's how they can do what they do.
So if you want to translate that, there is value in doing a processing step manually to learn how it works - but when you understood that, automation can actually benefit you, because only then are you even able to do larger, higher-level processing steps "manually", that would take an infeasible amount of time and energy otherwise.
Where I'd agree though is that you should never lose the basic understanding and transparency of the lower-level steps if you can avoid that in any way.
Let me save everybody some time:
1. They're not saying it because they don't want to think of themselves as obsolete.
2. You're not using AI right, programmers who do will take your job.
3. What model/version/prompt did you use? Works For Me.
But seriously: It does not matter _that_ much what experienced engineers think. If the end result looks good enough for laymen and there's no short term negative outcomes, the most idiotic things can build up steam for a long time. There is usually an inevitable correction, but it can take decades. I personally accept that, the world is a bit mad sometimes, but we deal with it.
My personal opinion is pretty chill: I don't know if what I can do will still be needed n years from now. It might be that I need to change my approach, learn something new, or whatever. But I don't spend all that much time worrying about what was, or what will be. I have problems to solve right now, and I solve them with the best options available to me right now.
People spending their days solving problems probably generally don't have much time to create science fiction.
I use AI heavily, it's my field.
They're encountering a type of tool they haven't met before and haven't been trained to use. The default assumption is they are probably using it wrong. There isn't any reason to assume they're using it right - doing things wrong is the default state of humans.
I understand what the article means, but sometimes I've got the broad scopes of a feature in my head, and I just want it to work. Sometimes programming isn't like "solving a puzzle", sometimes it's just a huge grind. And if I can let an LLM do it 10 times faster, I'm quite happy with that.
I've always had to fix up the code one way or another though. And most of the times, the code is quite bad (even from Claude Sonnet 3.7 or Gemini Pro 2.5), but it _did_ point me in the right direction.
About the cost: I'm only using Gemini Pro 2.5 Experimental the past few weeks. I get to retry things so many times for free, it's great. But if I had to actually pay for all the millions upon millions of used tokens, it would have cost me *a lot* of money, and I don't want to pay that. (Though I think token usage can be improved a lot, tools like Roo-Code seem very wasteful on that front)
My experience has been the opposite. I've enjoyed working on hobby projects more than ever, because so many of the boring and often blocking aspects of programming are sped up. You get to focus more on higher level choices and overall design and code quality, rather than searching specific usages of libraries or applying other minutiae. Learning is accelerated and the loop of making choices and seeing code generated for them, is a bit addictive.
I'm mostly worried that it might not take long for me to be a hindrance in the loop more than anything. For now I still have better overall design sense than AI, but it's already much better than I am at producing code for many common tasks. If AI develops more overall insight and sense, and the ability to handle larger code bases, it's not hard to imagine a world where I no longer even look at or know what code is written.
It might challenge us, and maybe those of us who feel challenged in that way need to rise to it, for there are always harder problems to solve
If this new tool seems to make things so easy it's like "cheating", then make the game harder. Can't cheat reality.
I would try to build something "good" (not "perfect", just "good", like modular or future-proof or just not downright malpractice). But while I was doing this, others would build crap. They would do it so fast I couldn't keep up. So they would "solve" the problems much faster. Except that over the years, they just accumulated legacy and had to redo stuff over and over again (at some point you can't throw crap on top of crap, so you just rebuild from scratch and start with new crap, right?).
All that to say, I don't think that AIs will help with that. If anything, AIs will help more people behave like this and produce a lot of crap very quickly.
My only gripe is that the models are still pretty slow, and that discourages iteration and experimentation. I can’t wait for the day a Claude 3.5 grade model with 1000 tok/s speed releases, this will be a total game changer for me. Gemini 2.5 recently came closer, but it’s still not there.
Another area I find very helpful is when I need to use the same technique in my code as someone from another language. No longer do I need to spend hours figuring out how they did it. I just ask an AI and have them explain it to me and then often simply translate the code.
The product itself is exciting and solves a very real problem, and we have many customers who want to use it and pay for it. But damn, it hurts my soul knowing what goes on under the hood.
AI coding has removed the drudgery for me. It made coding 10X more enjoyable.
I'm not sure how much RAM is on the average smartphone owned by someone earning $5/day*, but it's absolutely not going to be the half a terabyte needed for the larger models whose weights you can just download.
It will change, but I don't know how fast.
* I kinda expect that to be around the threshold where they will actually have a smartphone, even though the number of smartphones in the world is greater than the number of people
Compared what you see from game jams where sometimes solo devs create whole games in just a few days it was pretty trash.
It also tracks with my own experience. Yes, cursor quickly helps me get the first 80% done but then I spent so much time cleaning after it that I have barely saved any time in total.
For personal projects where you don't care about code quality I can see it as a great tool. If you actual have professional standards, no. (Except maybe for unit tests, I hate writing those by hand.)
Most of the current limitation CAN be solved by throwing even more compute at it. Absolutely. The question is will it economically make sense? Maybe if fusion becomes viable some day but currently with the end of fossil fuels and climate change? Is generative Ai worth destroying our planet for?
At some point the energy consumption of generative AI might get so high and expensive that you might be better off just letting humans do the work.
The again primeagen is pretty critical of vibe coding so it was super weird match up anyway. I guess they decided to just have some fun. Maybe advertise the vibe coding "lifestyle" more so than the technical merit of the product.
Oh, it isn't the usual content for primeagen. He mostly reacts to other technical videos and articles and rants about his love for neovim and ziglang. He has ok takes most of the time and is actually critical of the overuse of generative Ai. But yeah, he is not a technical deep dive youtuber but more for entertainment.
Recently, we've seen a lot of a shift in insight into not just diving straight into implementation, but actually spending time on careful specification, discussion and documentation either with or without an AI assistant before setting it loose to implement stuff.
For large, existing codebases, I sincerely believe that the biggest improvements lie in using MCP and proper instructions to connect the AI assistants to spec and documentation. For new projects I would put pretty much all of that directly into the repos.
I ended up watching maybe 10 minutes of these streams on two separate occasions, and he was writing code manually 90% of the time on both occasions, or yelling at LLM output.
And I might not be the best coder, by far, but I've got over 40 years experience at this crap in practically every language going.
We can quibble about the exact number; 1.2x vs 5x vs 10x, but there's clearly something there.
That's the opposite of what's happened over the past year or two. Now many more non-technical people can (and are) building software.
The author tell his experience regarding his joy programming things and figuring stuff out. In the end he says that AI made him lose this joy, and he compares it to cheating in a game. He does not say one word about societal impact and or the amount of engineers in the future, it's what you interpreted yourself.
You comment is talking about ability to build software, vs. the article (in only a single sentence that references this topic, while the other 99% circles around something else) talks about the job market situation. If what you wanted so say "The author is arguing that people will probably have a harder time getting a job in software development", that would have been correct.
> That's the opposite of what's happened over the past year or two. Now many more non-technical people can (and are) building software.
You're (based on the new comment) explicitly saying that people without technical knowledge are getting jobs in software development sector. Where did you get that info from? Would be an interesting read for sure, if it's actually true.
Setting aside the fact that the author nowhere says this, it may in fact be plausible.
> That's the opposite of what's happened over the past year or two. Now many more non-technical people can (and are) building software.
Meanwhile half[0] the students supposed to be learning to build software in university will fail to learn something important because they asked Claude instead of thinking about it. (Or all the students using llms will fail to learn something half the time, etc.)
[0]: https://www.anthropic.com/news/anthropic-education-report-ho...
> That said, nearly half (~47%) of student-AI conversations were Direct—that is, seeking answers or content with minimal engagement.
This seems completely out of whack with my experience of AI coding. I'm definitely in the "it's extremely useful" camp but there's no way I would describe its code as high quality and efficient. It can do simple tasks but it often gets things just completely wrong, or takes a noob-level approach (e.g. O(N) instead of O(1)).
Is there some trick to this that I don't know? Because personally I would love it if AI could do some of the grunt work for me. I do enjoy programming but not all programming.
I find it they all make errors, but 95% of them I spot immediately by eye and either correct manually or reroll through prompting.
The error rate has gone down in the last 6 months, though, and the efficiency of the C# code I mostly generate has gone up by an order of magnitude. I would rarely produce code that is more efficient than what AI produces now. (I have a prompt though that tells it to use all the latest platform advances and to search the web first for the latest updates that will increase the efficiency and size of the code)
The hardware for AI is getting cheaper and more efficient, and the models are getting less wasteful too.
Just a few years ago GPT-3.5 used to be a secret sauce running on the most expensive GPU racks, and now models beating it are available with open weights and run on high end consumer hardware. Few iterations down the line good-enough models will run on average hardware.
When that Xcom game came out, filmmaking, 3D graphics, and machine learning required super expensive hardware out of reach of most people. Now you can find objectively better hardware literally in the trash.
Moore's law is withering away due to physical limitations. Energy prices go up because of the end of fossil fuels and rising climate change costs. Furthermore the global supply chain is under attack by rising geopolitical tension.
Depending on US tariffs and how the Taiwan situation plays out and many other risks, it might be that compute will get MORE expensive in the future.
While there is room for optimization on the generative AI front we are still have not even reached the point were generative AI is actually good at programming. We have promising toys but for real productivity we need orders of magnitude bigger models. Just look how ChatGPT 4.5 is barely economically viable already with its price per token.
Sure if humanity survives long enough to widely employ fusion energy, it might become practical and cheap again but that will be a long and rocky road.
The way we use LLMs is also primitive and inefficient. RAG is a hack, and in most LLM architectures the RAM cost grows quadratically with the context length, in a workload that is already DRAM-bound, on a hardware that already doesn't have enough RAM.
> Depending on US tariffs […] end of fossil fuels […] global supply chain
It does look pretty bleak for the US.
OTOH China is rolling out more than a gigawatt of renewables a day, has the largest and fastest growing HVDC grid, a dominant position in battery and solar production, and all the supply chains. With the US going back to mercantilism and isolationism, China is going to have Taiwan too.
All this went away. I felt a loss of joy and nostalgia for it. It was bitter.
Not bad, but bitter.
Thought it’s ok to use new for object literal in JS.
New challenges would come up. If calculators made the arithmetic easy, math challenges move to next higher level. If AI does all the thinking and creativity, human would move to next level. That level could be some menial work which AI can't touch. For example, navigating the complexities of legacy systems and workflows and human interactions needed to keep things working.
Well this sounds delightful! Glad to be free of the thinking and creativity!
Everyone wanted to be an architect. Well, here’s our chance!
When insight from a long-departed dev is needed right now to explain why these rules work in this precise order, but fail when the order is changed, do you have time to git bisect to get an approximate date, then start trawling through chat logs in the hopes you'll happen to find an explanation?
Having to dig through all that other crap is unfortunate. Ideally you have tests that encapsulate the specs, which are then also code. And help with said refactors.
Test-driven development doesn't actually work. No paradigm does. Fundamentally, it all boils down to communication: and generative AI systems essentially strip away all the "non-verbal" communication channels, replacing them with the subtext equivalent of line noise. I have yet to work with anyone good enough at communicating that I can do without the side-channels.
This is a human problem, not a technological one.
You can still have all your aforementioned broken powerpoints etc and use AI to help write code you would’ve previously written simply by hand.
If your processes are broken enough to create unmaintainable software, they will do so regardless of how code pops into existence. AI just speeds it up either way.
Personally, I'm in the "you shouldn't leave vital context implicit" camp; but in this case, the software was originally written by "if I don't already have a doctorate, I need only request one" domain experts, and you would need an entire book to provide that context. We actually had a half-finished attempt – 12 names on the title page, a little over 200 pages long – and it helped, but chapter 3 was an introduction-for-people-who-already-know-the-topic (somehow more obscure than the context-free PowerPoints, though at least it helped us decode those), chapter 4 just had "TODO" on every chapter heading, and chapter 5 got almost to the bits we needed before trailing off with "TODO: this is hard to explain because" notes. (We're pretty sure they discussed this in more detail over email, but we didn't find it. Frankly, it's lucky we have the half-finished book at all.)
AI slop lacks this context. If the software had been written using genAI, there wouldn't have been the stylistic consistency to tell us we were on the right track. There wouldn't have been the conspicuous gap in naming, elevating "the current system didn't need that helper function, so they never wrote it" to a favoured hypothesis, allowing us to identify the only possible meaning of one of the words in chapter 3, and thereby learn why one of those rules we were investigating was chosen. (The helper function would've been meaningless at the time, although it does mean something in the context of a newer abstraction.) We wouldn't have been able to used a piece of debugging code from chapter 6 (modified to take advantage of the newer debug interface) to walk through the various data structures, guessing at which parts meant what using the abductive heuristic "we know it's designed deliberately, so any bits that appear redundant probably encode a meaning we don't yet understand".
I am very glad this system was written by humans. Sure, maybe the software would've been written faster (though I doubt it), but we wouldn't have been able to understand it after-the-fact. So we'd have had to throw it away, rediscover the basic principles, and then rewrite more-or-less the same software again – probably with errors. I would bet a large portion of my savings that that monstrosity is correct – that if it doesn't crash, it will produce the correct output – and I wouldn't be willing to bet that on anything we threw together as a replacement. (Yes, I want to rewrite the thing, but that's not a reasoned decision based on the software: it's a character trait.)
A program to calculate payroll might be easy to understand, but unless you understand enough about finance and tax law, you can't successfully modify it. Same with an audio processing pipeline: you know it's doing something with Fourier transforms, because that's what the variable names say, but try to tweak those numbers and you'll probably destroy the sound quality. Or a pseudo-random number generator: modify that without understanding how it works, and even if your change feels better, you might completely break it. (See https://roadrunnerwmc.github.io/blog/2020/05/08/nsmb-rng.htm..., or https://redirect.invidious.io/watch?v=NUPpvoFdiUQ if you want a few more clips.)
I've worked with codebases written by people with varying skillsets, and the only occasions where I've been confused by the subtext have been when the code was plagiarised.
> [The] problem is that the sole medium of transport here for the intent of what the user wanted the language model to write and what we see is the output of the language model. And that in itself is a bit of a problem: had we hand-written code, we could look at what it tries to do; it would have suggestive names, maybe even comments, stemming from the user's original intent, and not from an LLM's interpretation of what the user told it was their intent. Basically, LLMs are intent-obfuscating machines for engineering problems :)
Actually really thinking, if I was running company allowing or promoting AI use that would be first priority. Whatever is prompted, must be stored forever.
The fun part though is that future coding LLMs will eventually be poisoned by ingesting past LLM generated slop code if unrestricted. The most valuable code bases to improve LLM quality in the future will be the ones written by humans with high quality coding skills that are not reliant or minimally reliant on LLMs, making the humans who write them more valuable.
Think about it: A new, even better programming language is created like Sapphire on Skates or whatever. How does a LLM know how to output high quality idiomatically correct code for that hot new language? The answer is that _it doesn't_. Not until 1) somebody writes good code for that language for the LLM to absorb and 2) in a large enough quantity for patterns to emerge that the LLM can reliably identify as idiomatic.
It'll be pretty much like the end of Asimov's "Feeling of Power" (https://en.wikipedia.org/wiki/The_Feeling_of_Power) or his almost exactly LLM relevant novella "Profession" ( https://en.wikipedia.org/wiki/Profession_(novella) ).
You’re gonna work on captcha puzzles and you’re gonna like it.
> It makes economic sense, and capitalism is not sentimental.
I find this kind of fatalism irritating. If capitalism isn't doing what we as humans want it to do, we can change it.
So the OP was in a bad place without Claude anyways (in industry at least).
This realization is the true bitter one for many engineers.
Generating value for the shareholders and/or investors, not the customers. I suspect this is the next bitter lesson for developers.
The bitter lesson is that making profit is the only directive.
The realization that productive workers aren't just replaceable cogs in the machine is also a bitter lesson for businessmen.
Independent of what AI can do today, I suspect this was a reason why so many resources were poured into its development in the first place. Because this was the ultimate vision behind it.
(1) Define people's worth through labour.
(2) See labour as a cost center that should be eliminated wherever possible.
US politicians and technologists are trying to have it both ways: Oppose a social safety net out of principle as to "not encourage leechers", forcing people to work, but at the same time seek to reduce the opportunities for work as much as possible. AI is the latest and potentially most far-reaching implementation of that.
This is asking for trouble.
Why? Both AI and outsourcing provide a much cheaper way to get programming done. Why would you pay someone 100k because he likes doing what an AI or an Indian dev Team can do for much cheaper?
I am sure Software developers are here to stay, but nobody who just writes software is worth anywhere close to 100k a year. Either AI or outsourcing is making sure of that.
And the amount of code these people write is only going to decrease.
First sentence of my OP. I thought it was obvious.
The bitter lesson is going to be for junior engineers who see less job offers and don’t see consulting power houses eat their lunch.
That's what happened to manufacturing after all.
Therefore, I do not anticipate a massive offshoring of software like what happened in manufacturing. Yet, a lot of software work can be fully specified and will be outsourced.