The AI Elephant in the Room
joshwcomeau.com70 points by moebrowne an hour ago
70 points by moebrowne an hour ago
I had an Iron Man moment last week where I was “vibe coding” a UI design with component tests live on the other screen. Iterating by asking it to move things, reduce emphasis of an element, exploring layout options, etc. The loop was near realtime and felt amazing.
The code it generated was awful. The kind of garbage that people who don’t know any better would ship: it looked right and it worked. But it was instantly a maintenance dead end. But I had an effortless time converging on a design that I wouldn’t have been able to do on my own (I’m not a designer). And then I had a reference design and I manually implemented it with better code (the part I am good at).
That's the model I've arrived to as well:
- first I've created a skill how the architecture of the system should look like
- I'll tell the LLM to follow the guidelines; it will not do that 100%, but it will be good enough
- I'll go through what it produced, align to the template; if I like something (either I've not thought about the problem in that way, or simply forgot) I add that to the skill template
- rinse and repeat
This is not only for architecture of the system, but also when (and how to) write backend, frontend, e2e tests, docs. I know what I want to achieve = I know how the code should be organized and how it should work, I know how tests should be written. LLMs allow me to eliminate the tediousness of following the same template every time.
Bear in mind - the output requires constant supervision = LLM will touch something I told it not to touch, or not follow what I told it to do. The amount of the output can also sometimes be overwhelming (so, peer review is still needed), but at this point I can iterate over what LLM produces with it, with another LLM, then give to a human if it together makes sense
> The code it generated was awful. The kind of garbage that people who don’t know any better would ship: it looked right and it worked. But it was instantly a maintenance dead end.
In the Tailwind thread the other day I was explicitly told that the intended experience of many frameworks is "write-only code" so maybe this is just the way of the future that we have to learn to embrace. Don't worry how it's all hooked up, if it works it works and if it stops working tell the AI to fix it.
It's kind of liberating I guess. I'm not sure if I've reached AI nirvana on accepting this yet, but I do think that moment is close.
Easy, have Claude review the code, tell it to be critical and that it needs to be easier to understand, follow Clean Code, SOLID principles and best practices. Lie to it, say you got this from a Junior developer, or "review it as if you were a Staff Level Engineer reviewing Junior code" the models can write better code, just nobody tells them to.
This is it. I've had a similar experience in just playing around I asked it to clean up some code it wrote to increase maintainability and readability by humans. After a few iterations it had generated quite solid code. It also broke the code a couple of times along the way. But it does get me thinking that these pipelines with agents doing specific tasks makes a lot of sense. One to design and architect, one to implement, one to clean, one to review, one to test (actually there's probably a bunch of different agents for testing -- testing perf/power, that it matches the requirements/spec, matches the design, is readable/maintainable, etc...).
Code review is the main thing I use LLMs for. I have found it to be remarkably candid when you tell it the code came from another LLM (even name it). I was running Kimi K2.6 Q4 locally, seeing if it could SIMD a bit-matrix transpose function, and it was slow enough that I would paste its thinking into Gemini every few minutes. Gemini was savage.
The problem is it’s impossibly hard to test all the edge cases
Which is probably why so many random buttons in microsoft/apple/spotify just stop working once you get off the beaten path or load the app in some state which is slightly off base
Yeah, the biggest thing I've noticed from LLMs is that large tech products now have even more bugs. Turns out the humans weren't so bad after all...
I'm wondering if companies are 'diverting' engineering resources from core products to AI products with the view that the former are legacy. Kind of two sides of the same coin though.
> Turns out the humans weren't so bad after all...
The people pushing AI _over_ humans never thought they were. They just don't care about 'good' or 'bad', only 'time-to-market'. A bad app making money is better than a good one that isn't deployed yet. And who cares about anything past the end of the quarter? That's the next guy's problem.
I wonder how much of this is momentum.
At the moment, we understand the basic tech, could reasonably DIY, but choose not to knowing full well there's a mess of understandable code somewhere we could go clean up but dont want to. We accept fast iterations because we know roughly the shape of how it "should be" and can guide an automated framework towards that. This is especially true on our own projects or something we built originally! Stark/Iron man knew/moved, the suit assisted by adding momentum.
We're riding our "knowledge momentum".
If companies can hold out long enough, that knowledge completely fades, and the tool is all you have. At that point, they are locked in. Then it's not Iron man, it's an Iron lung (couldn't resist!)
Yeah that’s my main concern. It feels so so easy to be lazy and do a bad job now. And then my skills weaken and what makes me valuable fades.
I love the Iron lung reference. Perfect.
> But I had an effortless time converging on a design that I wouldn’t have been able to do on my own (I’m not a designer).
I'm not a designer either, but I've been around designers long enough to recognize when something is bad but just not know what is needed to make it better/good. I've taken time to find sites that are designed well and then recreated them by hand coding the html/css to the point that I consider myself pretty decent at css now. I don't need libraries or frameworks. My css/html is so much lighter than what's found in those frameworks as well. I still would not call myself a designer, but pages look like they were designed by a mediocre designer rather than an engineer :shrug:
Tangent: I never learned how to make the sorts of websites people find "professional" or "pretty" I could make functional and easy-to-use webapps, but not something people would think looks good or like something they would want to use. LLMs crushed this, without performance overhead; can still be HTML/CSS/targetted JS.
I feel the same but the question I struggle most with is this: "Does it matter when the people who are going to come along and maintain this are just going to use AI to fix or adjust this maintenance nightmare?"
At that point the code becomes a compile target, and then you need a new source of truth.
Which I think is perfectly worthy of exploration. Some people want to check in the prompts. Or even better, check in a plan.md or evenest betterest: some set of very well-defined specifications.
I'm not sure what the answer will be. Probably some mix of things. But today it is absolutely imperative that the code I write for the case I wrote it in is good quality and can be maintained by more than just me.
I don't see the benefit of checking in either prompts or specs.
I never tried spec driven development for myself, but if I review other's MRs I am typically exhausted after the first 10 lines.
And there are hundreds of lines, nearly always with major inaccuracies.
For myself I always found the plan mode to work well. Once the implementation is done, the code is the source of truth. If it works, it works.
When I want to add more functionality or change it, I just tell the agent what I want changed.
I doubt walls of semi-accurate existing specs are going to be beneficial there, but maybe my work differs from yours.
Same. Messy code makes it harder for us to understand and thus maintain the code (which is why people often refer to code as a liability), but is that the case for AI tools as well? If not, it seems like clean code may not matter as much anymore.
The problem with crappy frontend code is not only the maintenance. It's that stuff such as responsive design, accessibility or cross-browser compatibility that work nearly for free with elegant code won't work at all.
The problem is that technical debt is compounding. Bad LLM architectural and implementation decisions just blend in to the background and you build layer upon layer of a mess. At some point it becomes difficult and expensive (token wise) to maintain this code, even for an agent.
I mitigate this by few things: 1. Checkpoints every few days to thoroughly review and flag issues. Asking the LLM to impersonate (Linus Torvalds is my favorite) yields different results. 2. Frequent refactors. LLMs don't get discouraged from throwing things out like humans do. So I ask for a refactor when enough stuff accumulates. 3. Use verbose, typed languages. C# on the backend, TypeScript on the frontend.
Does it produce quality code? Locally yes, architecturally I don't know - it works so far, I guess. Anyway, my alternative is not to make this software I'm writing better but not making it at all for the lack of time, so even if it's subpar it still brings business value.
> The code it generated was awful.
I suppose you could solve that in two ways. Manually rewrite it as you did. Or formalize an architecture and let the AI rewrite it with that in mind. I suspect that either works.
If you are just blindly vibe coding without any parameters, guardrails, architecture, or broad guidance; you're going to have a mess of slop.
the power comes from creating the machine you can steer. Treat AI like an over eager college intern who you need to hand hold, but do tasks.
> So, on the one hand, I’m seeing the most talented developers I know amplify what they can do with AI, and on the other, I’m seeing people with less domain knowledge struggle to get past the “MVP” stage.
Those are people who weren't making it to the MVP stage before LLMs.
There is no doubt that highly technical people are getting A LOT more out of LLMs than people without dev experience, in an absolute sense. I think it's less clear in a relative sense.
A question I also ask myself a lot: What are the skills I'm leveraging, exactly, as a highly experienced developer that's now doing a lot of vibe coding?
1) I'm choosing good technology for the task, and thinking about what LLM-agents are good at and choosing technology that they can work well with.
2) I'm choosing good workflows for the LLM-agent, starting a new context at the right time, having it test things, making sure it has logging that it can inspect, making sure it can operate the application in a way that it can debug and inspect it.
3) I'm thinking about the code even though I'm not looking at it, I'm telling it how I want things implemented, I'm telling it how to debug things.
I think these are all hard things for non-developers to do, but I also think non-developers will be able to replicate a large chunk of #1 and #2 relatively quickly. I only have to figure out that it's valuable to tell the LLM-agent to use playwright when working on web page visuals once, and then I can tell you to do that too. Or the coding agents will come with that knowledge built-in (to the model or as a builtin skill or whatever). Knowledge around this will accumulate and become easier for non-developers to access, and in many cases be builtin to the models or harnesses.
I agree with more or less everything in the article. "Agentic coding" is great, but you still need to have a good grasp of the overall architecture of your application, and actually check what the agent does, to get the best results.
The problem is just that the question is not whether "human developers will be necessary in the near future", it's "how many human developers will be needed in the near future" - managers wanting to exploit the efficiency gains by deciding that fewer developers can now do more work "thanks" to AI.
An "elephant in the room" is a big topic that no one is talking about. Everyone is talking about AI.
Better headline: "Why AI Multiplies Developer Skills Rather Than Replacing Them"
> I think AI tools are more like Iron Man's suit.
There's an interesting repository with 63600 stars on GitHub (1). The developer of the repository is No 1 at the GitHub's trending contributors list (2). However, it seems like the application isn't what it's described to be (3), and the developers, on their end, are unable to clearly answer whether this is real or not, as it's just messy LLM output.
Proof that the suit alone doesn't make anyone Iron Man.
1. https://github.com/ruvnet/RuView
the whole thing is creepy. The ruvnet, has multiple projects.. its just AI. A lot of AI. It floods GH infra.. Kind of easy to understand why GH struggles.
On the other hand, there are 8,400 forks, and it looks very real, so developers seem to have confidence in it.
Many or even most software engineers are experts in their own codebases though, which means a large proportion of engineers are getting high value out of AI.
What’s not clear to me is: if writing more code per engineer is possible, does that result in fewer engineers or just more software, especially in areas that traditionally got squeezed: UX, testing, DevEx, documentation, etc. Perhaps the bar just gets raised?
Humans have hard skills and abilities the ais can’t reproduce yet like real time learning, spatial reasoning, cheap parallelism, Qualia so we can identity QWAN (quality without a name) because we feel in real time what the code is.
AIs have skills humans aren’t good at like nerding out on technical details.
That’s not a perfect map because I’m spitballing. However there is a symbiosis.
I am not sure I am productive anymore with AI as I am up to 125 repos and agents most of which are tools for managing AIs and things break frequently that it feels like spinning plates.
I spent two months in November and December last year writing by hand a fundamental library to constrain how the AIs build clis. That did make things move a lot faster but for those two months I felt the slowness.
I think it will always be like this. It’s the nature of paradigm shift to shift.
> "I think AI tools are more like Iron Man’s suit. It can do incredible things, but not on its own."
Someone needs to watch iron man 3...
> AI models have become shockingly good at completing a wide variety of programming tasks. They’re certainly not perfect, but in many cases, they’re good enough. I’m not happy about this, for a wide variety of ethical/environmental/safety reasons
You cannot hold a computer liable for any of those reasons. You can, however, sue the human that built or used the AI. So those concerns shoudn't be any different with or without AI. The same problems will be here either way. If you really care about those problems, you would demand your representatives in government actually enshrine those things in law, with some teeth, to ensure companies prevent problems with them. If you don't do something about those problems (with or without AI), then it's clear by your actions that ethical/environmental/safety concerns aren't actually that important to you.
I agree with the author that -- right now -- we're still in the part of the AI adoption / product development curve that it's an extreme force multiplier.
I like to think of it as a normal distribution, the further away a programmer is to the right of the mean, the more their benefit. It's almost like it's their standard deviation squared (σ²). So someone like Matt Perry (as OP mentioned), who is a >99.99% programmer for argument's sake and is therefore four standard deviations away from the mean... Matt gets a (4×4) 16x multiplying effect on their productivity.
Someone who is a slightly above average programmer might see a 2 or 3x boost on their productivity, which is huge(!) and might also make them fear for their job. Which tracks with the level of moral panic we are seeing and experiencing. This math kinda still holds up for "bad programmers" too (i.e. left of the mean), as in they still see a boost to their productivity (negative squared is a positive number)... but there's something iffy about their results. The technical debt is unmaintainable and because they don't _understand_ the systems that they're operating in, they end up in the "3 hour" prompt loops that the OP refers to.
> Similarly, if Matt Perry handed me the keys to the Motion repository and told me to take over, I wouldn’t have the same results even though I have access to the same set of LLM tools.
The question is -- how long is this multiplier going to exist for? Some people would wager "for the foreseeable long-term future"; some people think it will widen further; and some people think it will diminish or god forbid even collapse. It feels like most arguments at the moment (like this article's) are that the humans who "know what they are doing" will be able to baton the hatches and avoid being usurped by ever-capable models. I saw it in a café yesterday: someone was using a coding agent to build a marketing website for their project, getting more and more frustrated by not getting the outcome they wanted. Their friend typed a couple of sentences on their keyboard and got a "Dude! How did you do that? That was sick!" a minute or so later. "I used to build websites" the friend said. -- The friend 'knew what they were doing'.
How much longer is knowing what you're doing going to be a moat?
> How much longer is knowing what you're doing going to be a moat?
To me, I don't see how this will ever not be an advantage. All software requires constraints. Some of those constraints might be objective (scale, performance, etc.) but a lot of them are subjective and require active decision making (architecture, UI, readability).
So if there was only one way to do something or only one desired output, then yes I think models would surpass humans. But like art, I don't think there is a objective truth to software and because of that, humans get the opportunity to play an important role.
Now whether that is valued from a business/industry perspective is a question that I think we all know the answer to unfortunately.
> How much longer is knowing what you're doing going to be a moat?
For a looooonnnnngggg time, unless there's massive progress in AI research.
Fundamentally, next token prediction is limited. Granted, I'm pretty amazed at how well it's done, but if you can't activate the right parts of the models (with your prompts), then you're not going to get good results.
And to be fair, for lots of things this doesn't matter. Steve in Finance or Mindy in Marketing can create dashboards that actually help them, and the code quality mostly doesn't matter.
For stuff that needs to be shipped, monitored and maintained you still need to know what you're doing.
100% agree with this. I think takes like OP's would be much more interesting if they staked out a position in the future. I think it's pretty uncontroversial to say that someone with a great deal of technical expertise is going to be a hugely more effective LLM user today.
The question that really matters is whether that will continue to be the case. My guess is that technical expertise matters less over time, and the ability to specify the desired outcome is eventually the only thing that becomes important. But I could be wrong! The direction this all goes is pretty fuzzy in my mind.
I mostly share Josh's opinion, but I think a lot of these posts that talk about Senior vs. Junior experience when working with AIs is kind of rubbish. Sure, you get better results as a Senior working with AI tooling and struggle more as a Junior. Nothing has changed in that equation except the amplification.
What folks seem to avoid is that a Junior (in ANY subject) has the ability to LEARN so much faster with an AI research assistant, and that becoming an expert has accelerated for those with the personal stamina to dig deep (this as a requirement hasn't changed). I spend just as much time with my AI tooling asking questions as I do asking it to "build" or "fix" things. "How does this work?". "Can you suggest other tools?".
I think some people always think about AI as an input / output relationship, when a lot of the time, the fiddling in between, with or without AI was always the important part. Yes people will suck in the beginning, against they always did. I think the good folks though will suck for a MUCH shorter time than I did getting into things.
A lot of people will drop out and get discouraged. That happened before too. Learning things requires persistence. I think the only real case to be made is that AI's sense of immediate pleasure can neuter people away from running into friction. AI natives likely won't understand friction and question it.
> a Junior (in ANY subject) has the ability to LEARN so much faster with an AI research assistant
I’m not seeing this. And based on what we’re seeing at the university level, I’m not expecting to.
Yes, I agree, the skills are orthogonal. Digital typesetting is vastly quicker than manually putting down metal type, and since you’re exposed to more type you have the opportunity to learn faster. But getting good at typography with digital tools will help you very little if you need to lay out type manually.
> getting good at typography with digital tools will help you very little if you need to lay out type manually
The analogy is unlimited typing in Gmail won’t make you a better writer or typesetter on its own.
> a Junior (in ANY subject) has the ability to LEARN so much faster with an AI research assistant
This is a testable hypotheses with severe lack of citations. Intuition would argue the opposite. We learn by using our brains, if we offload the thinking to a machine and copy their output we don‘t learn. A child does not learn multiplication by using a calculator, and a language learner will not learn a new language by machine translating every sentence. In both cases all they’ve learnt is using a tool to do what they skipped learning.
It is of course a multiplier. The worries are:
- Lesser overall engineers needed -> lesser demand of human engineers -> lower compensations
- insufficient training at junior levels.
- longer time to productive human engineering skill.
These are playing out right now, and a concern for all engineers in the industry. IronMan amplification don't address the above
> Without guidance, LLMs tend to paint themselves into a corner, because they’re generating code to solve individual prompts, not thinking holistically about an application’s architecture.
I've found I can prevent the LLM, in many cases, from thrashing on a bug/feature for long periods of time by switching into plan mode and, even in the middle of a conversation, having it reassess the structure around the problem, first. If you keep prompting about the same bug, it may keep producing variations of the problem code. But forcing it to stop and 'think' for a bit, has yielded much better results.
I think the problem with this logic is it's based on the capabilities of LLMs today and really fails to address the prospect that they will continue to improve.
I used to be a PM and am technically literate enough but can only very minimally write code. I have been using LLMs to build (or try to, at least) internal tools for my business since GPT-4.
In the early days, I'd get a little ways, then the LLM would start breaking things, and I'd try but fail to get it to fix things. But over successive generations, I was increasingly able to get it unstuck by offering suggestions on where it may have gone wrong. With Opus 4.7, I don't even really have to do that - if something isn't working it's usually sufficient to just tell it what's broken. It can figure out how to fix it without my input. And of course fewer things are broken in the first place.
So I think I'm very well positioned to understand how these things are improving - better able to get the LLM to do what I want than the post OP quoted from /vibecoding (though I am 99% sure that post is actually AI slop), but less so than most of the people posting in this thread. As they've improved, whatever ability I have to guess at the causes of problems based on my experience having seen things go wrong with products I've PMed has become less necessary to getting the right outcome.
I expect that trend to continue - increasingly the LLM won't need the guidance of people with a great deal of technical expertise. I basically no longer have to attempt to diagnose problems in order to get them fixed, though with the caveat that I am building internal tools for which I am the only user, so certainly much simpler in scope than the stuff OP is talking about.
> Without guidance, LLMs tend to paint themselves into a corner, because they’re generating code to solve individual prompts, not thinking holistically about an application’s architecture.
The crux of what I'm trying to say here is that I absolutely believe that this line is 100% true today, but I would be deeply cautious about assuming that it will continue to be true given the improvements in LLMs over the past few years.
The fact that AI currently requires some human supervision to produce valuable results is not a good predictor that it will stay this way sadly. LLMs were basically unable to reason two years ago. They are now better at many reasoning tasks than most people. If there is even a remote chance that LLMs will make your job obsolete I would pivot as fast as I could. This includes first and foremost software engineering.
I agree with you. A lot of "AI code is not clean" is hopeful thinking. In two years it might be able to design and architect better than most humans too.
The people you see in the TV are not actually in the TV box. It looks real until you try to shake one’s hand. It’s kind of the same thing with AI (reasoning and whatnot).
I don't think it matters if the reasoning is philosophically "real" if it can solve real problems.
If you read my analogy in the context of the article, it should be clearer what I meant.
>AI is a powerful multiplier for people who already have deep technical expertise. The people seeing the biggest wins with AI are already highly skilled.
This sentiment will stray further from the truth as time goes on.
Sure, it's a multiplier for those who are already skilled, but for those who are unskilled, it is capable of taking you from 0 -> 1+.
The ones currently benefiting from AI are the ones who (i) have a general understanding of how an AI works and experience with using it and (ii) have a very generic understanding of what it is they're trying to do (programming, most likely) and know the limits of their tools, but don't know how to actually do anything meaningful.
The whole point of AI is to open the door of complexity to normies; they are the ones benefiting most from it. For a skilled developer, it may make a 1hr task -> 5 mins; for a normie, it makes something which was utterly impossible into -> now within his reality to achieve. the difference for normies is just more life-changing.
If you think of skilled developers as the ceiling and normies as the floor, AI raises the floor higher by giving normies more capability, which makes the ceiling seem less impressive. But eventually the floor will surpass the ceiling, and then it'll be a matter of who can operate AI better/how good AI is.
I know someone who got AI to make a full minecraft bot gui that will put down waypoints for people to see and dig at and then do an in-game dig search (bot uses jsmacros) and they know zero coding.
I see two points:
1. AIs aren't yet good at architecture.
2. AIs aren't yet good at imagining technically exciting stuff to build.
And I agree that there's still space there to build a career in the short to medium term (plus Jevons Paradox). When both those points are no longer true we are certainly much closer to, dear I say it, agi. I suspect that (1) will be solved for somewhat limited domains in the near future using harnesses. And it could snowball from there.
Nearly every argument that hinges on the word "yet" is just an example of over-extrapolation[0] at play.
Is this just an ad for whimsical animations? Seemed like an abrupt change.
> the most talented developers I know amplify what they can do with AI
Not the most talented developer, but this has been pretty much my experience as well. Just keep it under control, know what and why its doing at every step, read the code, and then it will boost your productivity.
I just hope my employer comes to the same conclusion before I get laid off.
We are quickly reaching a point though that programmers will become so reliant on llm for coding so much so as people have become soul reliant on their phones to remember phone numbers, the younger generations dont have a single phone number they can call to memory and soon the same will be true of code.
Hmm. I think extrapolating from the reddit people who say "I tried vibe coding an entire app from scratch and all I said was fix this and make no mistakes and it didn't work" is a bad data source and will give you the wrong intuition. Of course it won't work when you hold it like that. But put just a tiny bit of knowledge and guidance into the prompt and AI will nail it.
I didn't think this 6 months ago but today after what I've seen these models debug and accomplish in established, messy production monoliths, I'm fully convinced even the worst vibe coders are only a year or two away from being able to actually create something from scratch and have it not blow up 50 files in.
So I guess I take the totally opposite stance, today's AI is the worst AI will ever be at coding, and I believe the vested interests behind AI do not plan on making it any worse at this task, so...
I see this as a much more solid and mature take than those who "boo" about AI taking their jobs.
I don't agree, LLMs/AI does definitely have agency.
Maybe not the same agency you would expect from a human being, but if you put them in a ralph loop they can go far, far away, and mostly because on how we build our world in the pre-llm era: do you need to order something (or you want to hire a hitman)? -> you can go do it on a web site or via whatsapp or by calling some API.
> you put them in a ralph loop they can go far, far away
The point is they mostly wind up somewhere stupid, and it takes expertise to spot and correct that. (Maybe that changes with further development.)
With enough time (and tokens), they'll eventually recover.
It's essentially a "brute force" approach, but in most cases, they only need to succeed once.
> With enough time (and tokens), they'll eventually recover
The article’s point is this is not true. They wind up in bullshit attractors where they hit a wall and then get lost within their muddled context window.
> they only need to succeed once
Yet they don’t. Not on their own. Like, you haven’t had an LLM get stuck in a stupid loop where you point out the flaw and then it gets unstuck?
AI just further increases inequality.. this is fine for the author for now, but might not be fine anymore when we end up with the eventual result - winner-take-all, where one will boast 2500000x productivity increase, while others have no job.
When you see rising inequality, don't just cheer because you happen to win for now.. maybe think about the future and also others..
Back in the late 90's when the internet was really just becoming a thing with most people, a friend said something that's stuck with me all these years. "We're losing our moderate speech."
Everything these days is either the greatest thing ever or the worst thing ever. All the stuff in the middle has vanished. Very few it seems acknowledge AI as being a useful tool. It's either "We're all being replaced" or "The technology is all slop" and everyone talks over each other like it's the Super Bowl and their teams are battling it out.
It would be nice if we could just look to the opportunities this tech offers and focus on that.
>I think AI tools are more like Iron Man’s suit. It can do incredible things, but not on its own.
Seemingly every AI pilled programmer who writes a blog post on AI's impact on software engineering has the same philosophical argument, and it's wording changes slightly every 6-12 months to reflect the newest models capabilities.
In 2023 it was: "AI is just autocomplete. It can't code whole blocks on it's own."
In 2024 it was: "AI is only good for scaffolding new projects, or boiler plate code. It can't write the application whole sale."
Since November 2025 it's been: "AI is only writing the code for us. It can't manage architecture, or do the long term planning required for real world applications."
In 6-12 months when the AI is doing an increasing amount of the architecture and high level planning, what will AI pilled programmers fall back on then?
I think they're jumping to the right conclusions - because the impetus to get as rid of as many people as possible isn't generally based on understanding, analysis, results, or lessons learned but a FOMO-like mania spread primarily through executive-class groupchats. This is, IMO, what mitchelh referred to last week as entire companies being in the grip of AI psychosis.
So while the author's points are completely true and valid, an executive will say "True, but Claude will get smarter faster than these problems and in 3 years it'll fix everything" and there's absolutely nothing you can say or do in response to this.
The "it is just a tool" talking point is very fashionable right now to pretend that plagiarizing material is still a meritocracy.
Except that what is true today might not be true 1-5 years from now.
There's been a massive shift since the release of opus 4.5 just 6 months ago - it's wild to make big claims on what AI can or can't do.
We just don't know.
[dead]
[dead]
[dead]