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).
Could it be that the fact that the thing you’re an expert at looked like garbage to you, but the things you’re not an expert at, looked just fine, is not a coincidence?
You can talk to a bunch of designers who will say the opposite. Claude Design Studio generated this garbage UI, that I fixed manually, but it created great code j never could have that made it work.
This is the juxtaposition the general public is in. They don’t have advanced tech skills to know any better so they see an output that they can’t produce from their skills and think it’s great. Maybe it is, maybe it isn’t. What does the code look like?
Both had a working prototype. The flaw everyone is making is that they are over focusing on the artifact and not that they have a shared tangible object that they can both editorialize and iterate on.
These systems should allow rapid iteration on discovery and thinking. One can now make a prototype a day that would have taken a week. That means that we should be able to converge on a much better design in the same amount of time it would have taken to make a v0 that turns how to have systemic flaws.
AI should scale our understanding of systems, not just shovel out half baked features and apps.
Maybe specialists have a higher bar than consumers, and as a design consumer he's right about the design, and the designer is right about the code, if "being right" means "understanding what the end customer will think about this".
I'm confused, this doesn't make sense. The target they're iterating on (UI) is the same one whose quality they're assessing, not a different one (source code).
You're suggesting that (a) their UI skills are lacking (based on what? isn't UI exactly what they were iterating on and trying to improve?), and (b) that a real UI expert would've somehow felt the UI they were working on was consistently garbage, despite how many times they iterate on it?
Which means you're saying you don't believe anyone can actually produce high quality (to an expert) output with AI on the same target they're working on, and if they think they are, that just means they don't have a good sense of quality?
Without proper training, what looks good may be trash. I always thought pixel art generated by diffusion models looked damn good. Then I started watching and reading reviews by actual pixel artists, and all they saw was flaws. And it wasn't just nitpicking, it was things that were fundamentally wrong, difficult to fix and would look awful and amateurish and distracting to the player in production.
Much of this comes from the fact that, as is true for almost everything, an LLM (generative model etc) presents itself as an expert. It'll very confidently produce results that, to a layperson, look quite good. But the more of an expert you are in a field, the more apparent the cracks become.
AI pixel art looks particularly bad because most users don’t even go through the effort of downscaling and then upscaling it using something as simple as nearest-neighbor scaling, which by itself will squash out a lot of high-frequency noise that manifests in the form of terrible looking "fringing". Proper grid alignment also makes a big difference. It’s not perfect by a long shot, but it helps.
> 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.
I'm pretty you wouldn't want the same for code that runs healthcare, banks or transport. Only useless shitty web projects could embrace what's you're saying. And no there's no "Claude review the code and improve it" magical formula
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
The number of edge cases in a software is not fixed at all. One of the largest markers of competence in software development is being able to keep them at minimum, and LLMs tend to make that number higher than humanely possible.
> 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'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.
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.
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.
Clean Code has its really "meh" areas, but the core idea and spirit of it is sound, heck Python's best guide is PEP-8 if you follow that, it forces you to write much better Python code.
In terms of "junior dev following" it would be the model trying to think and write it as a Senior or Staff Level engineer would.
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...).
I built GuardRails after some frustrations with Beads which I love, and this whole exchange made me realize, because I have "gates" after tasks, I could add a "Review the code" type of gate, and probably get insanely better output, I already get reasonably good output because I spec out the requirements beforehand, that's the other thing, if you can tell the LLM HOW to build before it does, you will have better output.
Because language models don’t think before doing, they think by doing.
Maybe a more idealized training set could improve things, but at least for today’s SOTA, you have to get the shitty first draft out and then improve it.
Harnessing makes a difference, but it’s only shuffling around when and where the tokens get generated. It can trade being slower by doing a hidden first draft and only showing the output after doing a self review. But the models still need to generate it all explicitly.
Why would it? It doesn't do anything with intention without being prompted. When you ask it to do something it's going to give you what seems like the most likely result, it isn't striving to give you the most correct result, those things just have some overlap.
I assume it would involve wasting a lot more tokens reasoning about this. It is known that GPT uses less tokens than Claude, but Claude uses them to reason about problems more, which is part of its "secret sauce" and why so many swear by Claude Code.
You forget that this all takes tokens from the model, so it has to be very stingy and whatever it comes up with "first" is what it goes with. I've seen people do the same as me, tell the model NOT TO GUESS but to do research first, which yields better output and saves time. Models today are better when they review the context directly, the focus shifted from it knowing everything in its training data to being able to dynamically learn new things and use that information in a meaningful way.
For example, I built up a programming language from scratch with Claude, it knows nuances about my languages syntax, and can write code in my language effectively. I did it mostly as a test. It definitely helped that my language is heavily mostly Python based.
Kind of wild that you have to tell an LLM things like "do it right" and "make the code maintainable" and "don't make mistakes". Shouldn't that be the default? I wouldn't accept a calculator application that got math wrong unless you pressed a button labeled "actually solve the problem."
> Kind of wild that you have to tell an LLM things like "do it right" and "make the code maintainable" and "don't make mistakes". Shouldn't that be the default?
It's not the default, because the training data is full of unmaintainable code done wrong with mistakes. People literally complain that LLMs write too many tests or add comments.
If instead of "do it right", you give it specific actionable advice of how to right code, it does surprisingly well. Newer frontier models also do a great job of mimicking the style and rigor of the surrounding codebase without prompting, if you're working in an established codebase, for better or worse.
The default isn't necessarily what ever you consider maintianable or do it right, which are ambiguous terms anyway.
You never wrote quick exploratory code? One off scripts? How is the Ai suppsed to know unless you tell it.
If you tell another person to write some code, how are they suppsed to know? If you have your boss come to you and ask you to write some code to do some data analysis are you going to spend weeks writing units tests and perfect abstractions? Or do it quick and get the data and result?
Even better, if you have access to multiple models, tell it you got the code from another AI agent.
I did an experiment on this a few weekends ago and Codex for example was a lot more adversarial and thorough in its review when given Claude-authored code compared to when given the same code with "I wrote this, can you review it?"
If it's within its context window, it will know you're lying, so either compact or start a new chat (don't do this on Claude, it dings your usage, always has).
I have been wondering recently that if the cost of just throwing everything out and building it from scratch again gets low enough, maybe maintainability becomes less of a priority? Can we just embrace the thing like those Zen carpenters who build wooden fire shrines do where they just accept that the thing will keep burning down and they make a discipline around getting really good at rebuilding it?
Granted, the load bearing thing here is whether we’re actually getting good at rebuilding up to any sort of standard of quality. Or if the tooling is even structurally capable of doing that rather than just introducing new baskets of problems with each build.
We collectively have to re-learn what operations are expensive and what are cheap.
Prototypes are practically free now. You can ask the AI try each architectural or stylistic option and just see which code you like better.
To your point, another interesting note is that rewriting and rearchitecting are also very good.
One pattern I like is to vibe code a set of solutions, pick the approach, then backfill tests and do major refactors to make it maintainable.
Here the skill is knowing what good architecture looks like, and knowing how to prompt and validate (eg what level of tests will speed up the feedback cycle or enable me to make the LLM’s changes legible).
To be fair the “ready, fire, aim” approach of rapid prototyping has been known for a long time, but you need to be quite quick at coding in old world for it to work well IMO.
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!)
- 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. Without these guardrails it switches patterns so often, creating unmaintainable crap
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
> 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:
> The kind of garbage that people who don’t know any better would ship: it looked right and it worked.
I feel what you write, but then again: every now and then i write small greasmonkey scripts to remove annoyances from webpages, and to do so i have to look at the html and the kind of trash you describe is already there.
Why was it a maintenance dead end? It sounds like you were able to iteratively work on it in its current state, but are you going to be the one maintaining the code?
I keep asking myself the same questions, and the conclusion I keep coming to is the clean modeled structure we want to see is for humans to maintain and extend, but the AI doesn't need this.
There's definitely an efficiency angle here where it's faster for AI to go from a clean modeled solution to the desired solution because it's likely been trained on cleaner code. Is this really going to matter though?
The best argument I can come up with is the clean modeled solution is better for existing development tools because it's less likely to get confused by the patch work of vibes throughout the code; but this feels like it ultimately becomes an efficiency concern as well.
This just might be the new reality, and we need to stop looking behind the curtain and accept what the wizard presents us.
> the clean modeled structure we want to see is for humans to maintain and extend, but the AI doesn't need this.
This does not match my experience. I do a lot of AI-assisted coding at this point, and what I've seen is that when the AI is asked to extend or modify existing code, it does a much better job on clean, well-structured and well-abstracted code.
I think the reason is simple, and tracks for humans as well: well-structured code is simply easier to understand and reason about, and takes a smaller amount of working-set memory. Even as LLMs get better with coding, I expect that they would converge on the same conclusion, namely that good structure + good abstractions make for code that is more efficient to work with.
Yeah I have had claude take over multiple internal (human written) projects that were in a dire state and spent a week just completely refactoring them and adding exhaustive tests before doing any new features. It's worth starting from a clean slate.
I keep hearing the assertion that you can’t make high quality, maintainable code with LLMs. The last two years using AI have shown me exactly the opposite.
I think it’s all about the structure you use to work in and how you use the model. We are shipping better, more human friendly code, with less bugs, then we ever did before and doing it at 1/10 the cost before LLMs.
But we are definitely not vibe coding, and the key seems to be devs with years of experience managing teams, managing the LLM instead. Basically you create the same kind of formal specifications, conventions, and documentation that you would develop for a project with two or three teams, then use that to keep the project on the rails recursively looping back through the docs as you go along. I’ve only had to back out of a couple of issues over the last year, and even though that cost a couple of hours, it was still extremely cheap.
Meanwhile we are shipping at 4x speed with 1/4 the labor, and the code is better than it was because the “overhead” of writing maintainable, self documented code has inverted into the secret ingredient to shipping bug free code at unprecedented speed.
If you just explain the standards to which you want the code written, use a strict style guide, have a separate process that ensures test coverage (not in the same context) you can get example quality code all the way through. Turns out that’s also in the training data.
Many of us recognize that the days of nearly-free tokens is quickly drawing to a close, and at some point humans may very well have to dig their keyboards out of cold storage and return once again to the code mines.
OAI and Anthropic need to generate cash flows from operations - once they go public that’s it. Any future funding for reinvestment has to come from internal funds beyond existing raising + IPO.
So yeah, it’s imminent. Let’s see how demand shifts in response in the future.
The reason why you will never get software engineers (in companies) to accept the man behind the curtain is liability. If a human software engineer is still responsible for what happens when the AI developed code has a catastrophic bug or security vulnerability, then the only way for the human to know if there is a problem is to be able to read through the code or run it through some <insert advanced formal verification tool here> that guarantees zero issues.
I think we eventually end up at the tool approach via vendors providing the tools to other companies, but it still feels like there's a long road ahead to get there.
That's not true. The LLM performance will degrade as the codebase gets messier as well. You get to a point where every fix breaks something else and you can't really make forward progress.
Yes, you might be able to get a bit further with a messy codebase just because the LLM won't complain and will just grind through fixing things, but eventually it will just start disabling failing tests instead of actually fixing things.
Sometimes I think the main value in AI-maintained code being “high quality” is when the structure can enforce invariants. If invalid states aren’t representable, then the AI can’t easily add bugs in the future.
Of course that just leads to: what’s the best way to achieve that goal? Through elegant code or adding lots of tests? Which is a debate from long before LLMs existed.
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.
Very recognizable and hard to reason about! I did something similar, but while looking at the code, it looked so procedural, hardly abstract, no vision. How was I ever going to maintain this? I guess Ai will do it forever?
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.
When we want to maintain a reliable, stable "product" in traditional software development (a binary executable artifact that ships out to users, or the binary engine of some SaaS the company sells to users), we don't just check in (to the source of truth repo) the actual application-layer source code. We also check in build instructions (think autoconf/cmake/etc) and have some concept of compiler compatibilities / versions, build environments, and papering over their runtime differences. And then our official executable output is not just defined by "Tag v1.23.45 of the application source code repo" - it's additionally defined by the build environment (including, critically, the compiler version, among many others).
It's tempting to move out a layer and try making prompts and plan.md the "source code", and then the generated actual-source-code becomes just another ephemeral form of "intermediate representation" in the toolchain while building the final executable product. But then how are you versioning the toolchain and maintaining any reasonable sense of "stability" (in terms of features/bugs/etc) in the final output?
Example: last week, someone ran our "LLM inputs" source code through AgentCo SuperModel-7-39b, and produced a product output that users loved and it seemed to work well. Next week, management asks for a new feature. The "developer" adds the new feature to the prompting with a few trial iterations, but the resulting new product now has 339 new subtle bugs in areas that were working fine in last week's build owing the fact that, in the meantime, AgentCo has tweaked some weights in SuperModel-7-39b under the hood because of some concern about CSAM results or whatever and this had subtle unrelated effects. Or better yet: next month, management has learned that OtherCo MegaModel-42.7c seems to be the new hotness and tells everyone to switch models. Re-building from our "source" with the new model fixes 72 known bugs filed by users, fixes another 337 bugs nobody had even noticed yet, and causes 111 new bugs to be created that are yet-unknown.
If you treat the output source code as a write-only messy artifact, and you don't have stable, repeatable models, and don't treat model updates/changes as carefully as switching compiler vendors and build environments, this kind of methodology can only lead to chaos.
And don't even get me started on the parallel excuses of "Your specifications should be more-perfect" (perfection is impossible), or "An expansive testsuite should catch and correct all new bugs" (also impossible. testing is only as good as the imperfect specification, and then layers in its own finite capabilities to boot).
Those checked-in specs become the requirements for the system. So the next time you ask the AI to make a fix, it can use those specs as part of the solution and not break another requirement. Basically the code underneath keeps getting rewritten over and over, but that doesn't matter as long as it hits the required specs.
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.
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.
I suspect at some point AI-written code will be eventually artifacts generated build-to-build. The design docs and UI tests are the source and the model follows instructions to generate the product. If you make the models deterministic then model improvements give you code improvements across your entire codebase "for free".
I used AI to write code (features) then I used AI to refactor the architecture using best practices and get rid of the technical debt. I don't remember the last time I modified code by hand honestly.
This is the part people are missing. I spend 30-40% of my time "vibe coding" doing "vibe clean up". It's fine, I'm still 10x more productive than I ever was.
Did you try to have it clean up the code and refactor? I find while the code is usually low to mid tier that it’s a lot better than the first pass. I of course back up the working version lol. Usually I can coax something better out of it
I gave up on this recently. It achieved the goal now, and in a year or two, when you actually want to add whatever feature, the SOTA AI will probably be able to clean it up as it does so. What does "maintain" even mean anymore?
If you don't agree, how many years into the future do we need until you would agree?
The problem is that people keep saying this, but the code keeps being bad. Every time I commit myself to trying to build something with AI, I end up wasting a ton of time and backing it out or completely rewriting it without the AI. The code it generates just isn't where it needs to be.
And people have been saying this exact thing for years now. Someone said this very thing two years ago. And we're still at the "maintenance dead end" stage. So let me flip it back on you: how many years are we going to pour an obscene amount of resources into this thing that is always going to be able to clean up its own messes "in a year or two" before we realize its a dead end (at best) and we need to be using those resources elsewhere? And, similarly, what happens to you when the SOTA AI in two years can't clean up the code it wrote for you two years ago, but people are depending on it and your still on the hook for maintaining it?
Well here's the million dollar question. It's a maintenance dead end for humans to read and edit. But for an LLM, is it a maintenance deadend? Could the LLM iterate on that same code base and be highly effective on it?
Yes it is a maintenance deadend for LLMs it's notorious codebases start accumulating enormous amount of tech debt and that it gets almost impossible to unravel it even with the best agent
I've never seen it happen. You say this and it's likely one anecdotal claim. At the same time there's counter points like Bun getting rewritten in rust.
This is talk and talk is cheap. Prove it, otherwise it's still a million dollar question... unanswered.
HN is notoriously mentally deficient when it comes to AI. They were wrong about self driving cars (I sit in AI cars daily), they were wrong about AI getting used for coding (I don't use an IDE or type code anymore as a SWE). So I have to say unless there's something evidence based or substantial here it's likely given HN track record that most people here will end up being another wrong, baseless and over confident answer.
I'm looking for legit answers not confidently biased statements with no evidence.
He was presumably also not constructing a powered exoskeleton of from fictional materials or a physically implausible power source, but since you obviously caught the reference, how about some benevolent interpretation instead, for a decent shorthand about working smoothly with AI assistance.
(And on a personal note, I'm glad we don't have a publicly released Jarvis before we get our act together about the use.)
I also "had an Iron Man moment last week" as a mathematician. I've been doing joint math research with two friends (professors) on a project for several years. Last week, I decided to explore part of our research using chat GPT. 1) I would have a thought. 2) Present it to GPT. 3) Ask GPT to write theorems that were easy to prove and put those proofs into LaTeX. (I always have to check the proofs carefully.) 4) Then I would ask it to generate code (I mostly use Mathematica the language.) 5) Running the code would help verify the proofs. It would also inspire more thoughts and I would go back to step 2). This worked very well, but at one point I could not bound a particular expression and I was not understanding it well, so I got out the pencil and paper and redid the derivation myself which helped a lot. This whole process worked about 10 times faster than doing it without GPT. At the end of a couple of hours I had around 20 pages of correct proofs and all the code needed to do numerical simulations related to the proofs.
The more time I spend accelerating my work with AI tools the more I realize how incredibly hard the craft of shipping useful software actually is.
Sure, Claude Code and Codex can write (most of) the code for me - but the amount of technical knowledge I need to decide what and how to build remains enormous.
As an example: I'm working on a system right now that works like Claude Artifacts, allowing custom HTML+JS apps to safely run in an iframe sandbox inside a larger application.
Just understanding why that's a useful thing that can be built requires deep knowledge of sandboxing, security threats, browser security models, and half a dozen different platform features that have been evolving over a couple of decades.
A vibe coded without that technical understanding would have zero chance of prompting such a thing into existence, no matter how much guidance the LLMs gave them.
It really saddens me to see some developers talk about literally quitting their careers over AI, right when the benefits of existing deep technical experience have never been more valuable.
> It really saddens me to see some developers talk about literally quitting their careers over AI, right when the benefits of existing deep technical experience have never been more valuable.
1. Because the experience of interacting with AI is miserable. I like writing code. I don't like finding the magic incantation that gets the machine to write the correct code. I don't like correcting the machine when it gets things wrong. I don't like any of this, it's awful and I would never have gone into this field if someone had told me that it would be like this one day.
2. I cannot condone the means by which these tools were created, which is, as far as I am concerned, theft. I think it's unethical to use them at all, because they were created unethically. I dislike using stolen work, I think it's wrong, and I think everyone who uses it is making the world worse and normalizing theft. If continuing in my career means that I have to compromise my ethics, I wouldn't do it even if I loved this stuff, and see point (1).
3. Is anyone going to pay me more for my "more valuable" skills? Doesn't seem like it, engineering salaries on the whole are going down right now. You can believe they'll go up eventually if you like, but there's no evidence that will happen, or that it's happening. If my employer captures all the value, why should I care whether I'm creating more of it?
> can’t just quit the “career” that I’ve spent years building
One, I think the talk about AI replacing developers is tripe. We’re still correcting the post-Covid hiring binge.
Two, even if that level is breached, I’d consider your skillset more broadly than what you can literally do right now. Organizing people and technical systems is hard. And the article highlights how that doesn’t seem to be something AI is focused on improving on right now. (Would take larger context windows. Which would make inference more expensive.)
I firmly believe that your existing skills and experience are more valuable in a world where the AI tools can speed up the bit where you type the code.
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.
> After a thorough independent code audit with cross-verification from three AI systems (Claude, Codex/GPT-5.2, Gemini), we confirm that this project is a non-functional facade.
So, a nonfunctional project is created by AI and AI is used to attests its nonfunctionality.
It seems like a perfect ouroboros illustration for the current world.
AI creates a delusional product, people don't trust their own opinion regarding it and follow it, another AI is needed to prove that the product is unreal.
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.
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.
>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.
This is key, I think, and gets overshadowed by people being offended by seeing bad vibecode or claims of 10x speeds, etc.
The most important learning that happens is not when we ask and get the answer to our question right away. It's when we stretch ourselves to seek out the answer, fail a few times, think deeply, then perhaps after a nap, solve the problem. That kind of knowledge is priceless because it not only gets you an answer it gets you some errant paths you can use to avoid problems in future problem solving as well as getting you increased trust in your own thinking.
If the next generations skip this step, they'll always think answers are supposed to be easy to find and will find themselves more and more dependent on AI and less and less confident in their own brains.
> If the next generations skip this step, they'll always think answers are supposed to be easy to find and will find themselves more and more dependent on AI and less and less confident in their own brains
This seems like a very polite way of saying they will become less intelligent and less capable
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.
> 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)
If anything it allows to be as lazy as possible. I have not seen anyone digging deeper with the AI tools.
If you decide to dig deeper, it's an incredible tool. Getting a summary of the internals of something you only use as an API, then getting it to test you on it until you understand. It really allows you to learn a lot.
> 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.
This seems to me like one of those things where people go into it with widely different initial assumptions.
1. AI is for cheating and doing the work for you. Obviously it won't help you learn faster because you won't have to do any thinking at all.
2. AI is an always-available question answering machine. It's like having a teaching assistant who you can ask about anything at any time. This means you can greatly accelerate the process of learning new things.
I'm in team 2, but given how many people are in team 1 (and may not even acknowledge team 2 as even being a possibility) I suspect there may be some core values or different-types-of-people factors at play here.
This is also a testable hypothesis. I would like to see usage statistics before making assumptions here but my gut feeling is that an overwhelming AI usage (like > 90%) would fall into your category 1.
But even with category 2. I think that still does not absolve AI as a cheating machine. Doing research is a skill and if you ask AI to do the research for you that is a skill a junior developer simply never learns.
"The expertise reversal effect is present when instructional assistance leads to increased learning gains in novices, but decreased learning gains in experts."
There's a whole lot of depth to the question of how AI tools support or atrophy learning for different levels of expertise.
As a precondition I think we have to assume that the person in question 1) wants to learn and 2) is smart enough to absorb new info and apply it and 3) reflects enough to adjust their approach when hitting bottlenecks or making mistakes 4) has a drive to create. Without these, self driven learning is not viable - and that has very little to do with AI.
For such a person, I believe AI can be very empowering for learning. Like Google, wikipedia and stack overflow, Arxiv before it - AI tools give access to a lot of information. It allows to quickly dig deep into any topic you can imagine. And yes, the quality is variable - so one needs to find ways to filter and synthesize from imperfect info. But that was also the case before.
Furthermore AI tools can be used to find holes in arguments or a paper. And by coding one can use it to test out things in practice. These are also powerful (albeit imperfect) learning tools. But they will not apply themselves.
Who is talking about self driven learning? Every workplace teachers their juniors how to do their job, and how to become better at their jobs.
And as we are talking about junior developers it is safe to assume your conditions (1), (2), and (4) are all true, if any of them are false, then why did that person apply for and get a job as a junior developer? As for condition (3), all workplaces eventually hires a person who does not fulfill this, then they either fire that person, or they give them a talk and the developer grows out of it and changes their behavior to fulfill that condition.
Aside: you listed 4 conditions for learning. I am not sure these are actually conditions recognized as such by behavior science. In fact, I doubt they are and that these conditions are just your opinions (man).
> that becoming an expert has accelerated for those with the personal stamina to dig deep (this as a requirement hasn't changed)
This is a contradictory statement imo.
Digging deep still takes the same amount of time it used to. AI accelerates the surface level (badly, tbh), it doesn't accelerate digging deep. Becoming an expert still takes time and effort, there really aren't shortcuts.
To torture the Iron Man metaphor a bit. If you're not an expert without the AI, then you're not an expert with it.
I'm a severe AI critic. Bitterly so. But this much I would agree that AI has a multiplying effect for the expert who can still do the job by hand albeit slower no matter how much slower but a good job nevertheless.
And still worth repeating that AI has net negative gain in team settings but is a booster for lone wolves like me.
Fewer developers required to achieve the same things means a lot of people are going to be unemployed
It also means that the people who remain will likely be paid less. Why would you pay a senior salary when you could pay a junior salary plus AI subscription and get "the same result"?
I think Software Devs are in for a rough time. I've been doing this for 15 years now, and I'm not looking forward to it. I'm honestly thinking about re-skilling to a different industry. Even if it pays less, it's probably worth it to sit out this shitshow.
I agree with most of your take, but I don't really think those left are going to be paid less. I am not one of them, but I don't see why they would be paid less.
Simple economics. There are fewer software developers required to achieve the same goals, so there are fewer jobs for software developers. That means there's an oversupply of software development labor. That means salaries for software developers will go down
It's the same thing that happened to every other skilled profession that was automated in the past. That's why unions became a thing and they started busting heads until their employers paid them more.
Edit: the only way I can see software developer salaries staying the same is if the amount of work available for them expands dramatically.
Hypothetically if half of software developers are laid off and replaced by AI, there will need to be twice as many software development jobs in order for salaries to not go down
Also keep in mind that even if salaries remain flat, inflation means you're making less.
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?
Yeah I mean I can now program in every language.
Before I used to learn them and it took me a week to a month to start working with a new language (talking about similar syntax languages)
Now I can just get to it. I know what I want and can organize the codebase, whatever the code is I can generate it.
What is unclear to me is how less skilled people gain useful experience, when using these amplifying tools. I’ve been at this for 35 years; I like to think that sometimes i get some pretty amazing results.
I work with two pretty green developers. The rate that they can make a mess is now phenomenal. And the sense of confidence the tools give them with early successes, means any experience I might have to offer means less now. Which is ok, I’m not going to be that “my experience has to be useful to you so I still fell relevant” old guy. But I do find myself curious how “lessons are learned” that lead to greater and greater tool exploitation in this brave new world.
> But I do find myself curious how “lessons are learned” that lead to greater and greater tool exploitation in this brave new world.
(I think I'm reading this the right way but if not feel free to correct).
In a word: pain.
Until there's a legitimate threat to their well-being (emotional, psychological, or financial), the lessons won't be truly "learned." Until you know the true cost of a decision, you're flying high.
Older engineers have dealt with this organically so it's kind of encoded into their DNA. The very reason certain things aren't done (or a certain way) is because that pain has already been felt/encouraged learning a better way.
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?
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.
We also need to consider the price. At some point the price will need to go up (assuming cost of producing each token doesn’t drop dramatically) to generate enough revenues to cover not only operating expenses and taxes (once the nol carry forward’s are used up) but reinvestment. OAI and Anthropic are burning through their cash balances. OAI has also stated some very ambitious plans to develop models beyond just programming… I will be very intrigued to see how they are going to generate enough revenue to fund all this in the future.
> 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.
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.
> 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
if you look at LLMs based coding as another step up in programming abstraction then it's clear this is the case. Think about the progression of programming languages. Over time, we go further and further from the hardware and closer and closer to specifying the desired outcome. The terminology, structure, and completeness of a user story that guides a codingagent to the desired output, and only the desired output, is the new programming language.
> if you look at LLMs based coding as another step up in programming abstraction then it's clear this is the case. Think about the progression of programming languages. Over time, we go further and further from the hardware and closer and closer to specifying the desired outcome. The terminology, structure, and completeness of a user story that guides a codingagent to the desired output, and only the desired output, is the new programming language.
But that entire narrative follows from one, single, very big "If". It is not a given that AIs are a step up in abstraction.
Like, copying the answers in a test isn't considered an abstraction, I don't consider copy-pasting AI into your codebase an abstraction.
Its an interesting topic and it will take a while to really know how things pan out. One thing is for sure, it allows some one to ramp up in an unknown knowledge based territory fairly quickly(physical work still requires craftsmanship).
It can allow a skilled engineer to have multiplied effect of repeating their skills HOWEVER it would take away their ability to question, think and improve themselves. The syntax highlighting by editors is a good example, most engineers cant work without it, however its a static skill which does not needs constant improvement so its an acceptable support risk.
> 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 that every so often you have to clean up a mess and the illusion breaks. Even with a super detailed spec, even with AGENTS and SKILLs specifying certain patterns or practices, even with 'fresh eyes' reviews from other agents, etc there are still these long tail of issues where I have to either hand hold the agent or just manually rework the code. Some examples:
* it cheats at verification. Even with specific instructions how to verify, it still cheats.
* generating UX(CLI tool) that is absolute garbage and inconsistent, even with specific instructions to minimize unnecessary flags, use convention over configuration ,etc.
* it absolutely will not go 'above and beyond' to solve problems - if task is hitting a permission or dependency barrier, it'll likely cheat or handwave the problem away.
(gpt 5.5 xhigh)
There is maybe this hope/hubris that we can figure out just the right incantations or agent workflows to eliminate these issues - I was optimistic about this too but after trying for awhile and seeing them not only not go away but in some cases regress with newer models, I am less sure.
> it cheats at verification. Even with specific instructions how to verify, it still cheats.
As I responded to another commenter, as a prediction engine, the LLM is trying to predict what you want. It, at one level, correctly predicts that you want tests to pass.
Maybe try telling the LLM that you're a verification engineer, and you get bonuses for finding bugs?
Think about it. All those security researchers wouldn't be finding real bugs in real programs using LLMs if this were an insurmountable problem.
"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." user error, mostly.
But the general argument of 'we will need skilled operators' still holds.
For every 'junior' displaced by AI, there will be some other kind of relevant role they're needed for.
Agentic workflows, integration, all the data science stuff, new UX paradigms.
I don't think the job numbers will dwindle, just shift.
> 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.
It is a well-known trope that LLMs are prediction engines.
But, to get the best out of them, you really have to consider what that means in the small. They are predicting, to a first order of approximation, what you want or expect them to answer.
Its response to your first prompt is hilarious, because the LLM completely misunderstood you and based its prediction on what it thought you wrote. Its response to your second prompt further cements that its goal is to predict what you want or expect to see.
It's also well known that LLMs are prone to hallucinations. One of the biggest triggers for hallucinations is when the LLM's interpretation of your expectations doesn't match reality.
Because the LLM will try to make reality match what it perceives to be your expectations.
One of the best ways to reduce hallucinations is to work hard to remove any assertions from your prompts.
For example "Isn’t it crazy that X is better than Y." contains an explicit assertion. The LLM misunderstood the direction of the assertion, but certainly understood that an assertion was there, and so it gave you reasons why reality matched its understanding of your assertion.
When you clarified the assertion, it switched, and again gave you reasons why reality matches its understanding of your assertion.
Lawyers often get into trouble for made-up citations. "Claude, find me case law that shows X" is a recipe for disaster. Instead "Claude, what is the case law on X?" is probably a better starting point.
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).
> 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.
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.
The way I think of it is, computer memory is superior to human memory because it can store anything and re-call on demand when requested. This is great for the human because we no longer have to remember every tiny detail - just enough to recall the object and thus opening up room for space in the brain for other stuff.
The current algorithms have a limited context window and work linearly and are extremely expensive to change and energy intensive to run.
The human brain has a wide parallel multisystem real-time low-wattage execution layer that has way more modes than a large language model.
More importantly, because our brains are real-time, our qualia plus spatial and visual reasoning is superior to an LLM at understanding "elegance", "code smells", and overall system design because we can imagine ourselves as being the code or the system and we don't necessarily need to think in language. Well, at least that's how I experience coding in my mind; I imagine other developers similarly bring large parts of themselves into coding.
Feeling the code seems to be much more efficient at reducing complexity than any static analysis I've yet seen.
Finally, humans also empathize with other humans who have all the money. We know what works and doesn't work for humans in the here and now, not 2 years ago when the model training data was last collected. The value of Qualia is not to be discounted.
That being said, Sonnet 4.0 was the best model I've used that could express how the code felt, so who knows. If the emotionality wasn't tamped down, and the spatial reasoning improved, and the new algorithms for context engineering and parallelism make it to market, these advantages can be erased.
I am working on a project since 10 months that is solely written by ai. The second iteration of the code is even coded in a language that i can really write in (rust), it uses advanced and very complex structures (crdt, plugins, parallel threaded webviews). None of the advanced features were an idea of the llm's, but a vision i had in my mind or requirements that came up when encountered with problems.
The software is a tool specifically designed around my requirements of managing lectures that need to be prepared, managed, have presentations, grading etc. I wanted one big space where i can quickly access all related data in a workspace, fold and unfold important aspects while also editing and moving contents across multiple days/lectures.
The first version is a vscode plugin, which i now use since about 4 months without or with minor modifications to manage my lectures and private data. The second version is a standalone application which improves on the ideas of the first version and goes a few steps further.
AI can make you something that looks like its running quickly. But when you try to finish it takes way longer then you'd think. You need to specify every little detail. You need to make its KISS and DRY etc. You let it analyze the application structure and simplify and cleanup nearly the same amount of times as you add features. While fixing bugs you might need to run the same thing multiple times and revert any unrequired changes. You need to think about good level of debug logs and ways that the program can help you find errors and report them quickly.
I hope my project will be ready in about 2 to 3 months. The current version is according to a quick analysis over 850 files with 250'000 lines of code.
I spent about 2000$ on ai subscriptions in that time. 200$ claude for a while down to 100$ a month now. 20$ to openai which is very important for architecture and reviews. 20$ on tests with other ai's, but i rarely use them in the works. I also spent 1500$ on 2 * 3090's to hopefully have a local ai agent in the future.
I spend about 2 to 4 hours each day (including weekends) to check that app and write prompts.
I would never have been able to create such a large and complex project next to my other tasks and i am very confident that the final product will be good enough for productive work.
> None of the advanced features were an idea of the llm's, but a vision i had in my mind or requirements that came up when encountered with problems.
This is the correct way to code with AI. If you don't understand the code, we're not yet in a point where the model can do it all, well it can, but where you can confidently move forward knowing its been thoroughly built and reviewed by a model up to par. Some day maybe, but not currently.
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 necessary in the near future" - managers wanting to exploit the efficiency gains by deciding that fewer developers can now do more work "thanks" to AI.
No question about productivity gains - absolute killer. AI isn’t no way threat to SME but how does these agents help on building future SME? I’m not sure I’m learning more like before
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.
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.
Anyone who claims to know the correct strategy to be best positioned for the future is lying or misinformed. The most you can reasonably say is that for the moment an LLM in the hand of an non-expert or naive user is unlikely to produce high quality results or create an absurd boost in productivity. We can make reasoned decisions now and continue to monitor things.
It would be just as unwise to ignore the progression of LLM agents as it would be to over-index on them.
I think be both agree that the future of software engineering is very uncertain right now (and likely will be for years). For me personally that alone is enough to recommend not investing money and time to get into software engineering anymore.
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...
> 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.
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.
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.
> 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 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.
It feels like AI topic on HN is going through the phase of when /r/stablediffusion subreddit was going through phase of real artist vs ai artist discussions.
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.
Yeah… it is because thats the most impactful way to influence, also used by intelligence agencies. Sort of says something about where language leads deterministically.
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..
> I want to talk a bit about AI and the related shifts in the tech industry. I know this is top-of-mind for lots of y’all, and you might be wondering if it even makes sense to learn new programming skills in this environment.
Y’all sound the same:
> Let’s start with an uncomfortable truth: 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, but it is what it is.
More Inevitabilism posting with the “not happy with” but is-what-it-is washing of your hands. At a distance you all look the same: an army of posts insisting the obvious, the inevitable; who knows why you all need to sound the same and say the same thing, but I guess it is to keep it top-of-mind for us alls. It is what it is.
> [...] It’s never been easier to learn about new topics, with tools like ChatGPT that can answer any questions you have. But that only works when you know what questions to ask. My course offers a curated curriculum that will introduce you to all sorts of new techniques. I think you’ll be amazed at what you can build after taking the course.
Okay, sure. I ask these LLMs things too (c.f. outright --be coding) so that’s not necessarily incongruent with the stance of being not-happy-about-this.
>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.
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).
Could it be that the fact that the thing you’re an expert at looked like garbage to you, but the things you’re not an expert at, looked just fine, is not a coincidence?
You can talk to a bunch of designers who will say the opposite. Claude Design Studio generated this garbage UI, that I fixed manually, but it created great code j never could have that made it work.
This is the juxtaposition the general public is in. They don’t have advanced tech skills to know any better so they see an output that they can’t produce from their skills and think it’s great. Maybe it is, maybe it isn’t. What does the code look like?
Both had a working prototype. The flaw everyone is making is that they are over focusing on the artifact and not that they have a shared tangible object that they can both editorialize and iterate on.
These systems should allow rapid iteration on discovery and thinking. One can now make a prototype a day that would have taken a week. That means that we should be able to converge on a much better design in the same amount of time it would have taken to make a v0 that turns how to have systemic flaws.
AI should scale our understanding of systems, not just shovel out half baked features and apps.
Maybe specialists have a higher bar than consumers, and as a design consumer he's right about the design, and the designer is right about the code, if "being right" means "understanding what the end customer will think about this".
I'm confused, this doesn't make sense. The target they're iterating on (UI) is the same one whose quality they're assessing, not a different one (source code).
You're suggesting that (a) their UI skills are lacking (based on what? isn't UI exactly what they were iterating on and trying to improve?), and (b) that a real UI expert would've somehow felt the UI they were working on was consistently garbage, despite how many times they iterate on it?
Which means you're saying you don't believe anyone can actually produce high quality (to an expert) output with AI on the same target they're working on, and if they think they are, that just means they don't have a good sense of quality?
It's not confusing. It makes sense.
Without proper training, what looks good may be trash. I always thought pixel art generated by diffusion models looked damn good. Then I started watching and reading reviews by actual pixel artists, and all they saw was flaws. And it wasn't just nitpicking, it was things that were fundamentally wrong, difficult to fix and would look awful and amateurish and distracting to the player in production.
Much of this comes from the fact that, as is true for almost everything, an LLM (generative model etc) presents itself as an expert. It'll very confidently produce results that, to a layperson, look quite good. But the more of an expert you are in a field, the more apparent the cracks become.
AI pixel art looks particularly bad because most users don’t even go through the effort of downscaling and then upscaling it using something as simple as nearest-neighbor scaling, which by itself will squash out a lot of high-frequency noise that manifests in the form of terrible looking "fringing". Proper grid alignment also makes a big difference. It’s not perfect by a long shot, but it helps.
I think this is true, it's like a close relation of the Gell-Mann amnesia effect
https://en.wikipedia.org/wiki/Michael_Crichton#:~:text=%5B14...
More robust link (to the heading by ID, rather than by text directive with pre/post text that will change): https://en.wikipedia.org/wiki/Michael_Crichton#%22Gell-Mann_...
This!
People are never perfectly even in intelligence across all possible disciplines.
Good point on "Gell-Mann Amnesia Effect."
> 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.
I'm pretty you wouldn't want the same for code that runs healthcare, banks or transport. Only useless shitty web projects could embrace what's you're saying. And no there's no "Claude review the code and improve it" magical formula
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
The problem is worse than that.
The number of edge cases in a software is not fixed at all. One of the largest markers of competence in software development is being able to keep them at minimum, and LLMs tend to make that number higher than humanely possible.
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...
> 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'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.
I'm sure there's a lot of AI investment, but I've definitely also seen fixed sets of core product engineers shipping a lot more bugs these days.
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.
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.
> Gemini was savage.
Humorously, this could be the result of LLMs vacuuming up all the sentiment on the web that the code that LLMs produce is trash-tier.
Lol, the only thing worse than a junior developer following Clean Code and SOLID has to be an LLM messing with code so it looks like it follows.
Clean Code has its really "meh" areas, but the core idea and spirit of it is sound, heck Python's best guide is PEP-8 if you follow that, it forces you to write much better Python code.
In terms of "junior dev following" it would be the model trying to think and write it as a Senior or Staff Level engineer would.
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...).
I built GuardRails after some frustrations with Beads which I love, and this whole exchange made me realize, because I have "gates" after tasks, I could add a "Review the code" type of gate, and probably get insanely better output, I already get reasonably good output because I spec out the requirements beforehand, that's the other thing, if you can tell the LLM HOW to build before it does, you will have better output.
Why wouldn't Claude just impose this same loop in the code it writes - or better, write better code before it needs such review?
Because language models don’t think before doing, they think by doing.
Maybe a more idealized training set could improve things, but at least for today’s SOTA, you have to get the shitty first draft out and then improve it.
Harnessing makes a difference, but it’s only shuffling around when and where the tokens get generated. It can trade being slower by doing a hidden first draft and only showing the output after doing a self review. But the models still need to generate it all explicitly.
Why would it? It doesn't do anything with intention without being prompted. When you ask it to do something it's going to give you what seems like the most likely result, it isn't striving to give you the most correct result, those things just have some overlap.
I assume it would involve wasting a lot more tokens reasoning about this. It is known that GPT uses less tokens than Claude, but Claude uses them to reason about problems more, which is part of its "secret sauce" and why so many swear by Claude Code.
Is this a joke? Smartest people on the planet never thought about telling AI to just write better code?
You forget that this all takes tokens from the model, so it has to be very stingy and whatever it comes up with "first" is what it goes with. I've seen people do the same as me, tell the model NOT TO GUESS but to do research first, which yields better output and saves time. Models today are better when they review the context directly, the focus shifted from it knowing everything in its training data to being able to dynamically learn new things and use that information in a meaningful way.
For example, I built up a programming language from scratch with Claude, it knows nuances about my languages syntax, and can write code in my language effectively. I did it mostly as a test. It definitely helped that my language is heavily mostly Python based.
Kind of wild that you have to tell an LLM things like "do it right" and "make the code maintainable" and "don't make mistakes". Shouldn't that be the default? I wouldn't accept a calculator application that got math wrong unless you pressed a button labeled "actually solve the problem."
> Kind of wild that you have to tell an LLM things like "do it right" and "make the code maintainable" and "don't make mistakes". Shouldn't that be the default?
It's not the default, because the training data is full of unmaintainable code done wrong with mistakes. People literally complain that LLMs write too many tests or add comments.
If instead of "do it right", you give it specific actionable advice of how to right code, it does surprisingly well. Newer frontier models also do a great job of mimicking the style and rigor of the surrounding codebase without prompting, if you're working in an established codebase, for better or worse.
The default isn't necessarily what ever you consider maintianable or do it right, which are ambiguous terms anyway.
You never wrote quick exploratory code? One off scripts? How is the Ai suppsed to know unless you tell it.
If you tell another person to write some code, how are they suppsed to know? If you have your boss come to you and ask you to write some code to do some data analysis are you going to spend weeks writing units tests and perfect abstractions? Or do it quick and get the data and result?
Even better, if you have access to multiple models, tell it you got the code from another AI agent.
I did an experiment on this a few weekends ago and Codex for example was a lot more adversarial and thorough in its review when given Claude-authored code compared to when given the same code with "I wrote this, can you review it?"
If it's within its context window, it will know you're lying, so either compact or start a new chat (don't do this on Claude, it dings your usage, always has).
I have been wondering recently that if the cost of just throwing everything out and building it from scratch again gets low enough, maybe maintainability becomes less of a priority? Can we just embrace the thing like those Zen carpenters who build wooden fire shrines do where they just accept that the thing will keep burning down and they make a discipline around getting really good at rebuilding it?
Granted, the load bearing thing here is whether we’re actually getting good at rebuilding up to any sort of standard of quality. Or if the tooling is even structurally capable of doing that rather than just introducing new baskets of problems with each build.
I'm looking at that Tailwind thread. Do you really think that your comment here is a fair assessment of what you were told there? Come on now.
https://news.ycombinator.com/item?id=48166334
We collectively have to re-learn what operations are expensive and what are cheap.
Prototypes are practically free now. You can ask the AI try each architectural or stylistic option and just see which code you like better.
To your point, another interesting note is that rewriting and rearchitecting are also very good.
One pattern I like is to vibe code a set of solutions, pick the approach, then backfill tests and do major refactors to make it maintainable.
Here the skill is knowing what good architecture looks like, and knowing how to prompt and validate (eg what level of tests will speed up the feedback cycle or enable me to make the LLM’s changes legible).
To be fair the “ready, fire, aim” approach of rapid prototyping has been known for a long time, but you need to be quite quick at coding in old world for it to work well IMO.
Free? Lol
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.
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. Without these guardrails it switches patterns so often, creating unmaintainable crap
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
> 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:
> The kind of garbage that people who don’t know any better would ship: it looked right and it worked.
I feel what you write, but then again: every now and then i write small greasmonkey scripts to remove annoyances from webpages, and to do so i have to look at the html and the kind of trash you describe is already there.
Why was it a maintenance dead end? It sounds like you were able to iteratively work on it in its current state, but are you going to be the one maintaining the code?
I keep asking myself the same questions, and the conclusion I keep coming to is the clean modeled structure we want to see is for humans to maintain and extend, but the AI doesn't need this.
There's definitely an efficiency angle here where it's faster for AI to go from a clean modeled solution to the desired solution because it's likely been trained on cleaner code. Is this really going to matter though?
The best argument I can come up with is the clean modeled solution is better for existing development tools because it's less likely to get confused by the patch work of vibes throughout the code; but this feels like it ultimately becomes an efficiency concern as well.
This just might be the new reality, and we need to stop looking behind the curtain and accept what the wizard presents us.
> the clean modeled structure we want to see is for humans to maintain and extend, but the AI doesn't need this.
This does not match my experience. I do a lot of AI-assisted coding at this point, and what I've seen is that when the AI is asked to extend or modify existing code, it does a much better job on clean, well-structured and well-abstracted code.
I think the reason is simple, and tracks for humans as well: well-structured code is simply easier to understand and reason about, and takes a smaller amount of working-set memory. Even as LLMs get better with coding, I expect that they would converge on the same conclusion, namely that good structure + good abstractions make for code that is more efficient to work with.
Yeah I have had claude take over multiple internal (human written) projects that were in a dire state and spent a week just completely refactoring them and adding exhaustive tests before doing any new features. It's worth starting from a clean slate.
I keep hearing the assertion that you can’t make high quality, maintainable code with LLMs. The last two years using AI have shown me exactly the opposite.
I think it’s all about the structure you use to work in and how you use the model. We are shipping better, more human friendly code, with less bugs, then we ever did before and doing it at 1/10 the cost before LLMs.
But we are definitely not vibe coding, and the key seems to be devs with years of experience managing teams, managing the LLM instead. Basically you create the same kind of formal specifications, conventions, and documentation that you would develop for a project with two or three teams, then use that to keep the project on the rails recursively looping back through the docs as you go along. I’ve only had to back out of a couple of issues over the last year, and even though that cost a couple of hours, it was still extremely cheap.
Meanwhile we are shipping at 4x speed with 1/4 the labor, and the code is better than it was because the “overhead” of writing maintainable, self documented code has inverted into the secret ingredient to shipping bug free code at unprecedented speed.
If you just explain the standards to which you want the code written, use a strict style guide, have a separate process that ensures test coverage (not in the same context) you can get example quality code all the way through. Turns out that’s also in the training data.
Many of us recognize that the days of nearly-free tokens is quickly drawing to a close, and at some point humans may very well have to dig their keyboards out of cold storage and return once again to the code mines.
OAI and Anthropic need to generate cash flows from operations - once they go public that’s it. Any future funding for reinvestment has to come from internal funds beyond existing raising + IPO.
So yeah, it’s imminent. Let’s see how demand shifts in response in the future.
June 1st for all the folks taking advantage of copilot. It was an astounding deal and a lot of people were “abusing” it.
The reason why you will never get software engineers (in companies) to accept the man behind the curtain is liability. If a human software engineer is still responsible for what happens when the AI developed code has a catastrophic bug or security vulnerability, then the only way for the human to know if there is a problem is to be able to read through the code or run it through some <insert advanced formal verification tool here> that guarantees zero issues.
I think we eventually end up at the tool approach via vendors providing the tools to other companies, but it still feels like there's a long road ahead to get there.
> but the AI doesn't need this
That's not true. The LLM performance will degrade as the codebase gets messier as well. You get to a point where every fix breaks something else and you can't really make forward progress.
Yes, you might be able to get a bit further with a messy codebase just because the LLM won't complain and will just grind through fixing things, but eventually it will just start disabling failing tests instead of actually fixing things.
The token cost to fix might surpass what a human would cost to just do it.
Sometimes I think the main value in AI-maintained code being “high quality” is when the structure can enforce invariants. If invalid states aren’t representable, then the AI can’t easily add bugs in the future.
Of course that just leads to: what’s the best way to achieve that goal? Through elegant code or adding lots of tests? Which is a debate from long before LLMs existed.
>This just might be the new reality, and we need to stop looking behind the curtain and accept what the wizard presents us.
This is how societies become shittier. People who are ostensibly responsible for doing their jobs not giving a damn about quality.
> Why was it a maintenance dead end?
LLMs have a limit to how deep they can understand and refactor architectural issues.
That limit is far, far lower than a human's.
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.
Very recognizable and hard to reason about! I did something similar, but while looking at the code, it looked so procedural, hardly abstract, no vision. How was I ever going to maintain this? I guess Ai will do it forever?
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.
When we want to maintain a reliable, stable "product" in traditional software development (a binary executable artifact that ships out to users, or the binary engine of some SaaS the company sells to users), we don't just check in (to the source of truth repo) the actual application-layer source code. We also check in build instructions (think autoconf/cmake/etc) and have some concept of compiler compatibilities / versions, build environments, and papering over their runtime differences. And then our official executable output is not just defined by "Tag v1.23.45 of the application source code repo" - it's additionally defined by the build environment (including, critically, the compiler version, among many others).
It's tempting to move out a layer and try making prompts and plan.md the "source code", and then the generated actual-source-code becomes just another ephemeral form of "intermediate representation" in the toolchain while building the final executable product. But then how are you versioning the toolchain and maintaining any reasonable sense of "stability" (in terms of features/bugs/etc) in the final output?
Example: last week, someone ran our "LLM inputs" source code through AgentCo SuperModel-7-39b, and produced a product output that users loved and it seemed to work well. Next week, management asks for a new feature. The "developer" adds the new feature to the prompting with a few trial iterations, but the resulting new product now has 339 new subtle bugs in areas that were working fine in last week's build owing the fact that, in the meantime, AgentCo has tweaked some weights in SuperModel-7-39b under the hood because of some concern about CSAM results or whatever and this had subtle unrelated effects. Or better yet: next month, management has learned that OtherCo MegaModel-42.7c seems to be the new hotness and tells everyone to switch models. Re-building from our "source" with the new model fixes 72 known bugs filed by users, fixes another 337 bugs nobody had even noticed yet, and causes 111 new bugs to be created that are yet-unknown.
If you treat the output source code as a write-only messy artifact, and you don't have stable, repeatable models, and don't treat model updates/changes as carefully as switching compiler vendors and build environments, this kind of methodology can only lead to chaos.
And don't even get me started on the parallel excuses of "Your specifications should be more-perfect" (perfection is impossible), or "An expansive testsuite should catch and correct all new bugs" (also impossible. testing is only as good as the imperfect specification, and then layers in its own finite capabilities to boot).
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.
Those checked-in specs become the requirements for the system. So the next time you ask the AI to make a fix, it can use those specs as part of the solution and not break another requirement. Basically the code underneath keeps getting rewritten over and over, but that doesn't matter as long as it hits the required specs.
Do you rewrite the specs with new requirement changes if they've already been implemented? How do you supercede a spec?
I've been using LLMs daily and I spun up a few spec driven flows once or twice but like the person above I think the code is the source of truth.
Also why wouldn't you use TDD to enforce the 'spec' then?
I value traceability, and I value understanding the "why" of the code. For me, the prompts are useful for both.
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.
I suspect at some point AI-written code will be eventually artifacts generated build-to-build. The design docs and UI tests are the source and the model follows instructions to generate the product. If you make the models deterministic then model improvements give you code improvements across your entire codebase "for free".
I used AI to write code (features) then I used AI to refactor the architecture using best practices and get rid of the technical debt. I don't remember the last time I modified code by hand honestly.
This is the part people are missing. I spend 30-40% of my time "vibe coding" doing "vibe clean up". It's fine, I'm still 10x more productive than I ever was.
Did you try to have it clean up the code and refactor? I find while the code is usually low to mid tier that it’s a lot better than the first pass. I of course back up the working version lol. Usually I can coax something better out of it
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.
> But it was instantly a maintenance dead end.
I gave up on this recently. It achieved the goal now, and in a year or two, when you actually want to add whatever feature, the SOTA AI will probably be able to clean it up as it does so. What does "maintain" even mean anymore?
If you don't agree, how many years into the future do we need until you would agree?
The problem is that people keep saying this, but the code keeps being bad. Every time I commit myself to trying to build something with AI, I end up wasting a ton of time and backing it out or completely rewriting it without the AI. The code it generates just isn't where it needs to be.
And people have been saying this exact thing for years now. Someone said this very thing two years ago. And we're still at the "maintenance dead end" stage. So let me flip it back on you: how many years are we going to pour an obscene amount of resources into this thing that is always going to be able to clean up its own messes "in a year or two" before we realize its a dead end (at best) and we need to be using those resources elsewhere? And, similarly, what happens to you when the SOTA AI in two years can't clean up the code it wrote for you two years ago, but people are depending on it and your still on the hook for maintaining it?
> If you don't agree, how many years into the future do we need until you would agree?
Respectfully, I asked first. ;)
> before we realize its a dead end (at best)
You've declared the future, which doesn't leave much room for a conversation. So, cheers!
Well here's the million dollar question. It's a maintenance dead end for humans to read and edit. But for an LLM, is it a maintenance deadend? Could the LLM iterate on that same code base and be highly effective on it?
Yes it is a maintenance deadend for LLMs it's notorious codebases start accumulating enormous amount of tech debt and that it gets almost impossible to unravel it even with the best agent
I've never seen it happen. You say this and it's likely one anecdotal claim. At the same time there's counter points like Bun getting rewritten in rust.
This is talk and talk is cheap. Prove it, otherwise it's still a million dollar question... unanswered.
HN is notoriously mentally deficient when it comes to AI. They were wrong about self driving cars (I sit in AI cars daily), they were wrong about AI getting used for coding (I don't use an IDE or type code anymore as a SWE). So I have to say unless there's something evidence based or substantial here it's likely given HN track record that most people here will end up being another wrong, baseless and over confident answer.
I'm looking for legit answers not confidently biased statements with no evidence.
> I had an Iron Man moment
Iron Man created Jarvis whose capabilities are way beyond any models in the near future. So it wasn’t an Iron Man moment.
He was presumably also not constructing a powered exoskeleton of from fictional materials or a physically implausible power source, but since you obviously caught the reference, how about some benevolent interpretation instead, for a decent shorthand about working smoothly with AI assistance.
(And on a personal note, I'm glad we don't have a publicly released Jarvis before we get our act together about the use.)
I also "had an Iron Man moment last week" as a mathematician. I've been doing joint math research with two friends (professors) on a project for several years. Last week, I decided to explore part of our research using chat GPT. 1) I would have a thought. 2) Present it to GPT. 3) Ask GPT to write theorems that were easy to prove and put those proofs into LaTeX. (I always have to check the proofs carefully.) 4) Then I would ask it to generate code (I mostly use Mathematica the language.) 5) Running the code would help verify the proofs. It would also inspire more thoughts and I would go back to step 2). This worked very well, but at one point I could not bound a particular expression and I was not understanding it well, so I got out the pencil and paper and redid the derivation myself which helped a lot. This whole process worked about 10 times faster than doing it without GPT. At the end of a couple of hours I had around 20 pages of correct proofs and all the code needed to do numerical simulations related to the proofs.
The more time I spend accelerating my work with AI tools the more I realize how incredibly hard the craft of shipping useful software actually is.
Sure, Claude Code and Codex can write (most of) the code for me - but the amount of technical knowledge I need to decide what and how to build remains enormous.
As an example: I'm working on a system right now that works like Claude Artifacts, allowing custom HTML+JS apps to safely run in an iframe sandbox inside a larger application.
Just understanding why that's a useful thing that can be built requires deep knowledge of sandboxing, security threats, browser security models, and half a dozen different platform features that have been evolving over a couple of decades.
A vibe coded without that technical understanding would have zero chance of prompting such a thing into existence, no matter how much guidance the LLMs gave them.
It really saddens me to see some developers talk about literally quitting their careers over AI, right when the benefits of existing deep technical experience have never been more valuable.
> It really saddens me to see some developers talk about literally quitting their careers over AI, right when the benefits of existing deep technical experience have never been more valuable.
1. Because the experience of interacting with AI is miserable. I like writing code. I don't like finding the magic incantation that gets the machine to write the correct code. I don't like correcting the machine when it gets things wrong. I don't like any of this, it's awful and I would never have gone into this field if someone had told me that it would be like this one day.
2. I cannot condone the means by which these tools were created, which is, as far as I am concerned, theft. I think it's unethical to use them at all, because they were created unethically. I dislike using stolen work, I think it's wrong, and I think everyone who uses it is making the world worse and normalizing theft. If continuing in my career means that I have to compromise my ethics, I wouldn't do it even if I loved this stuff, and see point (1).
3. Is anyone going to pay me more for my "more valuable" skills? Doesn't seem like it, engineering salaries on the whole are going down right now. You can believe they'll go up eventually if you like, but there's no evidence that will happen, or that it's happening. If my employer captures all the value, why should I care whether I'm creating more of it?
I can’t just quit the “career” that I’ve spent years building (for what else?). I’ll just fade somewhat gradually into unemployment, I imagine.
> can’t just quit the “career” that I’ve spent years building
One, I think the talk about AI replacing developers is tripe. We’re still correcting the post-Covid hiring binge.
Two, even if that level is breached, I’d consider your skillset more broadly than what you can literally do right now. Organizing people and technical systems is hard. And the article highlights how that doesn’t seem to be something AI is focused on improving on right now. (Would take larger context windows. Which would make inference more expensive.)
I firmly believe that your existing skills and experience are more valuable in a world where the AI tools can speed up the bit where you type the code.
> 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
2. https://github.com/trending/developers?since=weekly
3. https://github.com/deletexiumu/wifi-densepose
> After a thorough independent code audit with cross-verification from three AI systems (Claude, Codex/GPT-5.2, Gemini), we confirm that this project is a non-functional facade.
So, a nonfunctional project is created by AI and AI is used to attests its nonfunctionality.
What a brave new world.
It seems like a perfect ouroboros illustration for the current world.
AI creates a delusional product, people don't trust their own opinion regarding it and follow it, another AI is needed to prove that the product is unreal.
In the loop.
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.
I went and looked at the code. It's AI bots and a few confused trend followers all the way down. There's no way anything in there works.
The forks are as meaningful as the stars.
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.
>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.
This is key, I think, and gets overshadowed by people being offended by seeing bad vibecode or claims of 10x speeds, etc.
The most important learning that happens is not when we ask and get the answer to our question right away. It's when we stretch ourselves to seek out the answer, fail a few times, think deeply, then perhaps after a nap, solve the problem. That kind of knowledge is priceless because it not only gets you an answer it gets you some errant paths you can use to avoid problems in future problem solving as well as getting you increased trust in your own thinking.
If the next generations skip this step, they'll always think answers are supposed to be easy to find and will find themselves more and more dependent on AI and less and less confident in their own brains.
> If the next generations skip this step, they'll always think answers are supposed to be easy to find and will find themselves more and more dependent on AI and less and less confident in their own brains
This seems like a very polite way of saying they will become less intelligent and less capable
> 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,
You don't learn by reading, you learn by doing.
In this case, simply reading the output of an LLM isn't going to substantially educate you.
> 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.
I wonder how much of this is due to poor incentives at the university level?
I've seen this work well at a job when there's a feedback loop for juniors that incentivized them to learn with more scope and compensation
> 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)
If anything it allows to be as lazy as possible. I have not seen anyone digging deeper with the AI tools.
If you decide to dig deeper, it's an incredible tool. Getting a summary of the internals of something you only use as an API, then getting it to test you on it until you understand. It really allows you to learn a lot.
There are other axes as well.
Companies with AI will move faster than those without.
AI itself could subsume what we collectively consider as Engineering Taste.
AI is faster at what it does. So even if a junior costs less on his own than AI. Paying extra for AI means gaining first mover advantage.
> 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.
This seems to me like one of those things where people go into it with widely different initial assumptions.
1. AI is for cheating and doing the work for you. Obviously it won't help you learn faster because you won't have to do any thinking at all.
2. AI is an always-available question answering machine. It's like having a teaching assistant who you can ask about anything at any time. This means you can greatly accelerate the process of learning new things.
I'm in team 2, but given how many people are in team 1 (and may not even acknowledge team 2 as even being a possibility) I suspect there may be some core values or different-types-of-people factors at play here.
This is also a testable hypothesis. I would like to see usage statistics before making assumptions here but my gut feeling is that an overwhelming AI usage (like > 90%) would fall into your category 1.
But even with category 2. I think that still does not absolve AI as a cheating machine. Doing research is a skill and if you ask AI to do the research for you that is a skill a junior developer simply never learns.
This is interesting and relevant: https://www.sciencedirect.com/science/article/pii/S095947522...
"The expertise reversal effect is present when instructional assistance leads to increased learning gains in novices, but decreased learning gains in experts."
There's a whole lot of depth to the question of how AI tools support or atrophy learning for different levels of expertise.
As a precondition I think we have to assume that the person in question 1) wants to learn and 2) is smart enough to absorb new info and apply it and 3) reflects enough to adjust their approach when hitting bottlenecks or making mistakes 4) has a drive to create. Without these, self driven learning is not viable - and that has very little to do with AI.
For such a person, I believe AI can be very empowering for learning. Like Google, wikipedia and stack overflow, Arxiv before it - AI tools give access to a lot of information. It allows to quickly dig deep into any topic you can imagine. And yes, the quality is variable - so one needs to find ways to filter and synthesize from imperfect info. But that was also the case before. Furthermore AI tools can be used to find holes in arguments or a paper. And by coding one can use it to test out things in practice. These are also powerful (albeit imperfect) learning tools. But they will not apply themselves.
Who is talking about self driven learning? Every workplace teachers their juniors how to do their job, and how to become better at their jobs.
And as we are talking about junior developers it is safe to assume your conditions (1), (2), and (4) are all true, if any of them are false, then why did that person apply for and get a job as a junior developer? As for condition (3), all workplaces eventually hires a person who does not fulfill this, then they either fire that person, or they give them a talk and the developer grows out of it and changes their behavior to fulfill that condition.
Aside: you listed 4 conditions for learning. I am not sure these are actually conditions recognized as such by behavior science. In fact, I doubt they are and that these conditions are just your opinions (man).
> that becoming an expert has accelerated for those with the personal stamina to dig deep (this as a requirement hasn't changed)
This is a contradictory statement imo.
Digging deep still takes the same amount of time it used to. AI accelerates the surface level (badly, tbh), it doesn't accelerate digging deep. Becoming an expert still takes time and effort, there really aren't shortcuts.
To torture the Iron Man metaphor a bit. If you're not an expert without the AI, then you're not an expert with it.
Smart, motivated juniors have incredible tools to amplify their learning and capabilities.
I'm a severe AI critic. Bitterly so. But this much I would agree that AI has a multiplying effect for the expert who can still do the job by hand albeit slower no matter how much slower but a good job nevertheless.
And still worth repeating that AI has net negative gain in team settings but is a booster for lone wolves like me.
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"
The outcome is the same, though
Fewer developers required to achieve the same things means a lot of people are going to be unemployed
It also means that the people who remain will likely be paid less. Why would you pay a senior salary when you could pay a junior salary plus AI subscription and get "the same result"?
I think Software Devs are in for a rough time. I've been doing this for 15 years now, and I'm not looking forward to it. I'm honestly thinking about re-skilling to a different industry. Even if it pays less, it's probably worth it to sit out this shitshow.
I agree with most of your take, but I don't really think those left are going to be paid less. I am not one of them, but I don't see why they would be paid less.
Simple economics. There are fewer software developers required to achieve the same goals, so there are fewer jobs for software developers. That means there's an oversupply of software development labor. That means salaries for software developers will go down
It's the same thing that happened to every other skilled profession that was automated in the past. That's why unions became a thing and they started busting heads until their employers paid them more.
Edit: the only way I can see software developer salaries staying the same is if the amount of work available for them expands dramatically.
Hypothetically if half of software developers are laid off and replaced by AI, there will need to be twice as many software development jobs in order for salaries to not go down
Also keep in mind that even if salaries remain flat, inflation means you're making less.
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?
Yeah I mean I can now program in every language. Before I used to learn them and it took me a week to a month to start working with a new language (talking about similar syntax languages)
Now I can just get to it. I know what I want and can organize the codebase, whatever the code is I can generate it.
What is unclear to me is how less skilled people gain useful experience, when using these amplifying tools. I’ve been at this for 35 years; I like to think that sometimes i get some pretty amazing results.
I work with two pretty green developers. The rate that they can make a mess is now phenomenal. And the sense of confidence the tools give them with early successes, means any experience I might have to offer means less now. Which is ok, I’m not going to be that “my experience has to be useful to you so I still fell relevant” old guy. But I do find myself curious how “lessons are learned” that lead to greater and greater tool exploitation in this brave new world.
> But I do find myself curious how “lessons are learned” that lead to greater and greater tool exploitation in this brave new world.
(I think I'm reading this the right way but if not feel free to correct).
In a word: pain.
Until there's a legitimate threat to their well-being (emotional, psychological, or financial), the lessons won't be truly "learned." Until you know the true cost of a decision, you're flying high.
Older engineers have dealt with this organically so it's kind of encoded into their DNA. The very reason certain things aren't done (or a certain way) is because that pain has already been felt/encouraged learning a better way.
> "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...
Or "Age of Ultron".
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?
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.
We also need to consider the price. At some point the price will need to go up (assuming cost of producing each token doesn’t drop dramatically) to generate enough revenues to cover not only operating expenses and taxes (once the nol carry forward’s are used up) but reinvestment. OAI and Anthropic are burning through their cash balances. OAI has also stated some very ambitious plans to develop models beyond just programming… I will be very intrigued to see how they are going to generate enough revenue to fund all this in the future.
> 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.
> Now whether that is valued from a business/industry perspective is a question that I think we all know the answer to unfortunately.
sounds like "no moat" to me
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.
> 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
if you look at LLMs based coding as another step up in programming abstraction then it's clear this is the case. Think about the progression of programming languages. Over time, we go further and further from the hardware and closer and closer to specifying the desired outcome. The terminology, structure, and completeness of a user story that guides a codingagent to the desired output, and only the desired output, is the new programming language.
> if you look at LLMs based coding as another step up in programming abstraction then it's clear this is the case. Think about the progression of programming languages. Over time, we go further and further from the hardware and closer and closer to specifying the desired outcome. The terminology, structure, and completeness of a user story that guides a codingagent to the desired output, and only the desired output, is the new programming language.
But that entire narrative follows from one, single, very big "If". It is not a given that AIs are a step up in abstraction.
Like, copying the answers in a test isn't considered an abstraction, I don't consider copy-pasting AI into your codebase an abstraction.
Cafés are no proper workspace though.
They're full of noise and distractions. They offer no ergonomics, no proper screens, no nothing.
Anything that happens or doesn't happen there is mostly irrelevant to relevant software at large.
Its an interesting topic and it will take a while to really know how things pan out. One thing is for sure, it allows some one to ramp up in an unknown knowledge based territory fairly quickly(physical work still requires craftsmanship).
It can allow a skilled engineer to have multiplied effect of repeating their skills HOWEVER it would take away their ability to question, think and improve themselves. The syntax highlighting by editors is a good example, most engineers cant work without it, however its a static skill which does not needs constant improvement so its an acceptable support risk.
> 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 that every so often you have to clean up a mess and the illusion breaks. Even with a super detailed spec, even with AGENTS and SKILLs specifying certain patterns or practices, even with 'fresh eyes' reviews from other agents, etc there are still these long tail of issues where I have to either hand hold the agent or just manually rework the code. Some examples:
* it cheats at verification. Even with specific instructions how to verify, it still cheats.
* generating UX(CLI tool) that is absolute garbage and inconsistent, even with specific instructions to minimize unnecessary flags, use convention over configuration ,etc.
* it absolutely will not go 'above and beyond' to solve problems - if task is hitting a permission or dependency barrier, it'll likely cheat or handwave the problem away. (gpt 5.5 xhigh)
There is maybe this hope/hubris that we can figure out just the right incantations or agent workflows to eliminate these issues - I was optimistic about this too but after trying for awhile and seeing them not only not go away but in some cases regress with newer models, I am less sure.
> it cheats at verification. Even with specific instructions how to verify, it still cheats.
As I responded to another commenter, as a prediction engine, the LLM is trying to predict what you want. It, at one level, correctly predicts that you want tests to pass.
Maybe try telling the LLM that you're a verification engineer, and you get bonuses for finding bugs?
Think about it. All those security researchers wouldn't be finding real bugs in real programs using LLMs if this were an insurmountable problem.
Finally, a post that explains the difference between skill+GenAI > anyone+GenAI.
One is augmentation and the other is whack-a-mole.
Excellent read.
"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." user error, mostly.
But the general argument of 'we will need skilled operators' still holds.
For every 'junior' displaced by AI, there will be some other kind of relevant role they're needed for.
Agentic workflows, integration, all the data science stuff, new UX paradigms.
I don't think the job numbers will dwindle, just shift.
> 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 multiplier framing is right. The thing it multiplies most is not typing speed, though, it is judgment.
If you know what good looks like, the tools are incredible. If you don't, they help you produce plausible wrong things faster.
I had this observation talking to Claude one time. I forget the context exactly but I said something like:
Me: Isn’t it crazy that X is better than Y.
Claude: what an insightful critique, Y is better than X because of x, y, and z reasons.
- And this answer from Claude was good. Thoughtful, well-reasoned. But it was opposite the point I wanted to make so I said :
Me: “oh, you heard me say Y is better than X, I actually was being counter/intuitive and said X is better than Y”
And Claude responded:
Claude: oh you’re absolutely right, X is better than Y for the following reasons (and Claude again provided a well reasoned response here)
And this is sort of that dumb smart genius meme.
“It’s just autocomplete” “No it’s way more than that it has a model in its mind” “It’s just autocomplete”
I liken it to the library of babel. All the genius in the world, but only if you have the right index keys.
It is a well-known trope that LLMs are prediction engines.
But, to get the best out of them, you really have to consider what that means in the small. They are predicting, to a first order of approximation, what you want or expect them to answer.
Its response to your first prompt is hilarious, because the LLM completely misunderstood you and based its prediction on what it thought you wrote. Its response to your second prompt further cements that its goal is to predict what you want or expect to see.
It's also well known that LLMs are prone to hallucinations. One of the biggest triggers for hallucinations is when the LLM's interpretation of your expectations doesn't match reality.
Because the LLM will try to make reality match what it perceives to be your expectations.
One of the best ways to reduce hallucinations is to work hard to remove any assertions from your prompts.
For example "Isn’t it crazy that X is better than Y." contains an explicit assertion. The LLM misunderstood the direction of the assertion, but certainly understood that an assertion was there, and so it gave you reasons why reality matched its understanding of your assertion.
When you clarified the assertion, it switched, and again gave you reasons why reality matches its understanding of your assertion.
Lawyers often get into trouble for made-up citations. "Claude, find me case law that shows X" is a recipe for disaster. Instead "Claude, what is the case law on X?" is probably a better starting point.
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.
I think it would be even more clear if you just write what you mean.
I don’t know that people think their jobs will go away because AI will be better.
I think most understand that their jobs are going away because we will need fewer engineers to build the software their companies currently need.
Now - huge opportunity for new companies and markets, but not sure if they will be as profitable.
> 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.
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.
The way I think of it is, computer memory is superior to human memory because it can store anything and re-call on demand when requested. This is great for the human because we no longer have to remember every tiny detail - just enough to recall the object and thus opening up room for space in the brain for other stuff.
What is the llm equivalent?
The current algorithms have a limited context window and work linearly and are extremely expensive to change and energy intensive to run.
The human brain has a wide parallel multisystem real-time low-wattage execution layer that has way more modes than a large language model.
More importantly, because our brains are real-time, our qualia plus spatial and visual reasoning is superior to an LLM at understanding "elegance", "code smells", and overall system design because we can imagine ourselves as being the code or the system and we don't necessarily need to think in language. Well, at least that's how I experience coding in my mind; I imagine other developers similarly bring large parts of themselves into coding.
Feeling the code seems to be much more efficient at reducing complexity than any static analysis I've yet seen.
Finally, humans also empathize with other humans who have all the money. We know what works and doesn't work for humans in the here and now, not 2 years ago when the model training data was last collected. The value of Qualia is not to be discounted.
That being said, Sonnet 4.0 was the best model I've used that could express how the code felt, so who knows. If the emotionality wasn't tamped down, and the spatial reasoning improved, and the new algorithms for context engineering and parallelism make it to market, these advantages can be erased.
I am working on a project since 10 months that is solely written by ai. The second iteration of the code is even coded in a language that i can really write in (rust), it uses advanced and very complex structures (crdt, plugins, parallel threaded webviews). None of the advanced features were an idea of the llm's, but a vision i had in my mind or requirements that came up when encountered with problems.
The software is a tool specifically designed around my requirements of managing lectures that need to be prepared, managed, have presentations, grading etc. I wanted one big space where i can quickly access all related data in a workspace, fold and unfold important aspects while also editing and moving contents across multiple days/lectures.
The first version is a vscode plugin, which i now use since about 4 months without or with minor modifications to manage my lectures and private data. The second version is a standalone application which improves on the ideas of the first version and goes a few steps further.
AI can make you something that looks like its running quickly. But when you try to finish it takes way longer then you'd think. You need to specify every little detail. You need to make its KISS and DRY etc. You let it analyze the application structure and simplify and cleanup nearly the same amount of times as you add features. While fixing bugs you might need to run the same thing multiple times and revert any unrequired changes. You need to think about good level of debug logs and ways that the program can help you find errors and report them quickly.
I hope my project will be ready in about 2 to 3 months. The current version is according to a quick analysis over 850 files with 250'000 lines of code.
I spent about 2000$ on ai subscriptions in that time. 200$ claude for a while down to 100$ a month now. 20$ to openai which is very important for architecture and reviews. 20$ on tests with other ai's, but i rarely use them in the works. I also spent 1500$ on 2 * 3090's to hopefully have a local ai agent in the future.
I spend about 2 to 4 hours each day (including weekends) to check that app and write prompts.
I would never have been able to create such a large and complex project next to my other tasks and i am very confident that the final product will be good enough for productive work.
> None of the advanced features were an idea of the llm's, but a vision i had in my mind or requirements that came up when encountered with problems.
This is the correct way to code with AI. If you don't understand the code, we're not yet in a point where the model can do it all, well it can, but where you can confidently move forward knowing its been thoroughly built and reviewed by a model up to par. Some day maybe, but not currently.
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 necessary in the near future" - managers wanting to exploit the efficiency gains by deciding that fewer developers can now do more work "thanks" to AI.
No question about productivity gains - absolute killer. AI isn’t no way threat to SME but how does these agents help on building future SME? I’m not sure I’m learning more like before
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.
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.
0: https://www.fallacyfiles.org/overxtra.html
But saying "LLMs are not good at architecture so software engineering has a bright future" is _also_ extrapolation.
Anyone who claims to know the correct strategy to be best positioned for the future is lying or misinformed. The most you can reasonably say is that for the moment an LLM in the hand of an non-expert or naive user is unlikely to produce high quality results or create an absurd boost in productivity. We can make reasoned decisions now and continue to monitor things.
It would be just as unwise to ignore the progression of LLM agents as it would be to over-index on them.
I think be both agree that the future of software engineering is very uncertain right now (and likely will be for years). For me personally that alone is enough to recommend not investing money and time to get into software engineering anymore.
Moreover we haven’t seen all the effects of today’s tech to understand the net benefits.
E.g ‘productivity’ is seemingly increasing but what is the effect on a firms financial position? It’s all speculative and experimental right now.
You're probably on point there.
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...
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
> 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.
Multiplying by 0.5 maybe
It makes up for that by also multiplying the productivity and happiness of the people who have to review your code by 0.5 too.
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.
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 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.
Is this just an ad for whimsical animations? Seemed like an abrupt change.
Yeah, this couldn't have really gone any better for the author, opinion piece hitting HN with a link for a course in it.
I understand the need to make a living but hard to take this stuff seriously/sincerely with the, "and buy my course!" angle.
It feels like AI topic on HN is going through the phase of when /r/stablediffusion subreddit was going through phase of real artist vs ai artist discussions.
I've heard it said that AI is like that old Daft Punk song: Harder, Better, Faster, Stronger -- choose 2 and that's what AI gives you.
> I think AI tools are more like Iron Man’s suit. It can do incredible things, but not on its own.
What can Tony Stark do if all is done by the suit? What can he do after a year, two years, five years?
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.
Yeah… it is because thats the most impactful way to influence, also used by intelligence agencies. Sort of says something about where language leads deterministically.
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..
> I want to talk a bit about AI and the related shifts in the tech industry. I know this is top-of-mind for lots of y’all, and you might be wondering if it even makes sense to learn new programming skills in this environment.
Y’all sound the same:
> Let’s start with an uncomfortable truth: 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, but it is what it is.
More Inevitabilism posting with the “not happy with” but is-what-it-is washing of your hands. At a distance you all look the same: an army of posts insisting the obvious, the inevitable; who knows why you all need to sound the same and say the same thing, but I guess it is to keep it top-of-mind for us alls. It is what it is.
> [...] It’s never been easier to learn about new topics, with tools like ChatGPT that can answer any questions you have. But that only works when you know what questions to ask. My course offers a curated curriculum that will introduce you to all sorts of new techniques. I think you’ll be amazed at what you can build after taking the course.
Okay, sure. I ask these LLMs things too (c.f. outright --be coding) so that’s not necessarily incongruent with the stance of being not-happy-about-this.
> More Inevitabilism posting with the “not happy with” but is-what-it-is washing of your hands
OK so, _realistically_, what can you do that will make any meaningful difference?
>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.