The Myth of Developer Obsolescence
alonso.network
alonso.network
Funny, because I did some freelancing work fixing disposable vibe-coded landing pages recently. And if there's one thing we can count on is that the biggest control-freaks will always have that one extra stupid requirement that completely befuddles the AI and pushes it into making an even bigger mess, and then I'll have to come fix it.
It doesn't matter how smart the AI becomes, the problems we face with software are rarely technical. The problem is always the people creating accidental complexity and pushing it to the next person as if it was "essential".
The biggest asset of a developer is saying "no" to people. Perhaps AIs will learn that, but with competing AIs I'm pretty sure we'll always get one or the other to say yes, just like we have with people.
It's just never been that hard to solve technical problems with code except for an infinitesimal percentage of bleeding edge cases.
"People problems" are problems mainly caused by lack of design consistency, bad communication, unclear vision, micromanagement.
A "people solution" would be to, instead of throwing crumbs to the developers, actually have a shared vision that allows the developers/designers/everyone to plan ahead, produce features without fear (causing over-engineering) or lack of care (causing under-engineering).
Even if there is no plan other than "go to market ASAP", everyone should be aware of it and everyone should be aware of the consequences of swerving the car 180 degrees at 100km/h.
Feedback both ways is important, because if you only have top-down communication, the only feedback will be customer complaints and developers getting burned out.
100% management-induced problems.
For example in chess AI is already far better than humans. Including on tasks like evaluating positions.
Admittedly, I use "AI" in a broad sense here, despite the article being mostly focused on LLMs.
Sometimes. I have often had to say "no" because the customer request is genuinely impossible. Then comes the fun bit of explaining why the thing they want simply cannot exist, because often they'll try "But what if you just ... ?" – "No! It doesn't work that way, and here's why..."
I had to explain recently that `a * x !== b * x when a !== b`*... it is infuriating hearing "but the result is the same in this other competitor" coupled with the "maybe the problem here is you're not knowledgeable enough to understand".
We've definitely had our fair share of "IDK what to tell you, those guys are mathing wrong".
TBF, though, most customers are pretty tolerant of explainable differences in computed values. There's a bunch of "meh, close enough" in finance. We usually only run into the problem when someone (IMO) is looking for a reason not to buy our software. "It's not a perfect match, no way we can use this" sort of thing.
At this particular job I used the plus, the star (multiplication) and once I even got to use the minus.
There's a legend going around that a friend of mine has used division, but he has a PhD.
What you have to do is dig into the REASONS they want X or Y or Z (all of which are either expensive, impossible, or both) - then show them a way to get to their destination or close to it.
In the business user’s mind, negotiation means the developer can do X but the developer is lazy. Usually, it is requirement X doesn’t make any sense because a meeting was held where the business decided to pivot to a new direction and decided the new technical solution. The product owner simply gives out the new requirement without the context. If an architect or senior developer was involved in the meeting, they would have told the business you just trashed six months of development and we will now start over.
But fundamentally it just means "the base of data", the same way "a codebase" doesn't just mean a Git repository. "Downloading the database" just means there's a way to download all the data, and CSV is a reasonable export format. Don't get confused into thinking it means a way to download the Postgres data folder.
In today's world with all the SPAs that don't push to history or don't manage to open the correct page based on history, this seems like a valid requirement
It's up to you to work with them to identify key features and figure out precisely what to do.
I think AI will get there when it comes to “you asked for a gif but they don’t support transparency”, but I am 100% sure people will continue to write “make the logo a square where every point is equidistant from the center” requirments.
EDIT: yes jpg, not gif, naughty typo + autocorrect
Why wouldn't the AI deal with that the same way human developers do? Follow up with questions, or iterate requirements?
[edit] In other words, llms that lie less will be more valuable for certain people, therefore llms that tell you when you are dumb will eventually win in those circles, regardless of how bruising it is to the user's ego.
Even experienced engineers can be surprisingly bad at this. Not everyone can tell their boss “That’s a stupid requirement and here’s why. Did you actually mean …” when their paycheck feels on the line.
The higher you get in your career, the more that conversation is the job.
They just want a yes-bot.
I think that the more you find ways to (productively) make that conversation your job, the higher you get in your career.
There's also no "ruling out" the Earth will get zapped by a gamma-ray burst tomorrow, either. You seem to be talking about something that, if done properly, would require AGI.
You can do anything with AI. Anything at all. The only limit is yourself.
Nobody can predict how soon a technology will plateau. People make predictions based on insane hot takes like "I pray to our new overloards who will make me immortal" and "there's nothing new under the sun, everything is just marketing"...
There might be the next AI winter starting starting next year, AI might wipe out humanity in our lifetime, even both of those might happen. Both very unlikely (qualitatively) ends of a huge spectrum.
That's not to say that we "don't know anything and thus give up talking about it". Otherwise I wouldn't participate in this discussion and I hope you wouldn't either if you didn't expect to sometimes learn something or be confronted with a new idea.
I just find both attitudes "it's making us immortal" as well as "I'm so experienced, I know that no new technology ever lives up to expectations and can mock people who admit they don't know that" unproductive. You don't know. Most technologies don't live up to expectations, a few work out even much better than expected. I'm sure before the Lee Sedol match, you thought to yourself "right, so it's going to win this and then plateau exactly a decade later"?
The thing is, with enough magical thinking, of course they could do anything. So that let's unscrupulous salesmen sell you something that is not actually possible. They let you do the extrapolation, or they do it for you, promising something that doesn't exist, and may never exist.
How many years has Musk been promising "full self driving", and how many times recently have we seen his cars driving off the road and crashing into a tree because it saw a shadow, or driving into a Wile E Coyote style fake painted tunnel?
While there is some value in evaluating what might come in the future when evaluating, for example, whether to invest in an AI company, you need to temper a lot of the hype around AI by doing most of your evaluation based on what the tools are currently capable of, not some hypothetical future that is quite far from where they are.
One of the things that's tricky is that we have had a significant increase in the capability of these tools in the past few years; modern LLMs are capable of something far better than two or three years ago. It's easy to think "well, what if that exponential curve continues? Anything could be possible."
But in most real life systems, you don't have an unlimited exponential growth, you have something closer to a logistic curve. Exponential at first, but it eventually slows down and approaches a maximum asymptotically.
Exactly where we are on that logistic curve is hard to say. If we still have several more years of exponential growth in capability, then sure, maybe anything is possible. But more likely, we've already hit that inflection point, and continued growth will go slower and slower as we approach the limits of this LLM based approach to AI.
And what is the endgame for AI?
Also technologies don't develop like evolution really so not sure why you drew that comparison.
Technologies plateau for a combination of reasons - too expensive to make it better, no interest in making it better, can't figure out any more science (key people involved leave / die / lose interest, or it's just too difficult with our current knowledge), theoretical limits (like we are reaching in silicon chips). I don't see a lot of similarity with evolution there.
This is what people never understand about no coding solutions. There is still a process that takes time to develop things, and you will inevitably have people become experts at that process who can be paid to do it much better and quicker than the average person.
It applies outside of tech too. Even if you can make potato pave at home, having it at a restaurant by someone who has made it thousands of times everyday, is preferred. Especially when you want a specific alteration
The out put was verbose, but it tried and then corrected me
> Actually, let me clarify something important: what you've described - "every point equidistant from the center" - is actually the definition of a circle, not a square!
here's the prompt
> use ascii art, can you make me an image of a square where every point is equidistant from the center?
If we're just looking for clever solutions, the set of equidistant points in the manhattan metric is a square. No clarifications needed until the client inevitably rejects the smart-ass approach.
Depends on what “transparent” means.
The task has been set; the soul weeps
> On two occasions I have been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
From Passages from the Life of a Philosopher (1864), ch. 5 "Difference Engine No. 1"
You put in 2+2, and 4 comes out. That's the right answer.
If you put in 1+1, which are the wrong figures for the question of 2+2, will 4 still come out? It's easy to make a machine that always says 4.
What an absurdly elegant way of saying one can't comprehend the stupidity behind some questions.
Given those requirements, I would draw a square on the surface of a sphere, making each point of the square equidistant from the sphere's center.
We can argue that AI can do this or that, or that it can't do this or that. But what is the alternative that is better? There often isn't one. We have already been through this repeatedly in areas such as cloud computing. Running you own servers is leaner, but then you have to acquire servers, data centers and operations. Which is hard. While cloud computing has become easy.
In another story here there are many defending that HN is simple [0]. Then it is noted that it might be getting stale [1]. Unsurprisingly as the simple nature of HN doesn't offer much over asking an LLM. There are things an LLM can't do, but HN doesn't do much of that.
For people to be better we actually need people. Who have housing, education and healthcare. And good technologies that can deliver performance, robustness and security. But HN is full of excuses why those things aren't needed, and that is something that AI can match. And it doesn't have to be that good to do it.
[0] https://news.ycombinator.com/item?id=44099357 [1] https://news.ycombinator.com/item?id=44101473
It's not just on HN; there's a lot of faith in the belief that eventually AI will enable enlightened individuals infinite leverage that doesn't hinge on pesky Other People. All they need to do is trust the AI, and embrace the exponentials.
Calls for the democratization of art also fall under this. Part of what develops one's artistic taste is the long march of building skills, constantly refining, and continually trying to outdo yourself. In other words: The Work. If you believe that only the output matters, then you're missing out on the journey that confers your artistic voice.
If people had felt they had sufficient leverage over their own lives, they wouldn't need to be praying to the machine gods for it.
That's a much harder problem for sure. But I don't see AI solving that.
In my experience this is always the hardest part of the job, but it's definitely not what a lot of developers enjoy (or even consider to be their responsibility).
I think it's true that there will always be room for developers-who-are-also-basically-product-managers, because success for a lot of projects will boil down to really understanding the stakeholders on a personal level.
There's also an art to it in how you frame the response, figuring out what the clients really want, and coming up with something that gets them 90% there w/o mushrooming app complexity. Good luck with AI on that.
I see two variants of the "please hear me, I have good ideas" effect: positive and negative:
1) This looks great, have you thought about adding <seemingly cool sounding thing that is either impossible to implement or wouldn't actually be useful in the real world>?
And
2) Oh no! Aren't you worried about <breaking something in some strange edge case in some ill advised workflow that no real world person would ever use>?
"I'll look into it" is a great answer. Heaven help the poor LLMs who have to take all this stuff seriously and literally...
But its a lie if you don't do it. In some other cultures you teach people to accept that their complaint isn't important rather than teach programmers to lie, and those people accept it since its normal there to deny complaints.
I don't think its healthy for a culture to force lies like that.
I realize that the value of this approach is highly dependent on a culture of public respect. Common in Japan, and common in some cultures in the U.S. Making the wrong person look stupid is a recipe for career problems in those cultures.
In my personal experience there’s no substitute to building relationships if you’re an individual or small company looking for contract/freelance work.
It starts slow, but when you’re doing good work and maintain relationships you‘ll be swimming in work eventually.
Often personal relationships with companies that employed me in the past, or companies where ex-colleagues worked.
The only single time I did freelance work for anyone else was when my neighbour (a graphic designer) sent some work my way.
Much better is variations of "We could do that, but it would take X weeks and/or cost this much in expenses/performance.
This leads to a conversation that enlightens both parties. It may even result in you understanding why and how the request is good after all.
Onus is yours to explain the difficulty and ideally the other party decides their own request is unreasonable, once you’ve provided an unreasonable timeline to match.
Actually straight-up saying no is always more difficult because if you’re not actually a decision-maker then what you’re doing is probably nonsense. You’re either going to have to explain yourself anyways (and it’s best explained with an unreasonable timeline), or be removed from the process.
It’s also often the case that the requestor has tried to imagine himself in your shoes in an attempt to better explain his goals, and comes up with some overly complex solution — and describes that solution instead of the original goal. Your goal with absurd requests is to pierce that veil and reach the original problem, and then work back to construct a reasonable solution to it
Product wanted it done in 6 months, to which I countered that the timeframe was highly unlikely no matter how many devs could be onboarded. We then proceeded to do weekly scope reduction meetings. After a month we got to a place where we comfortably felt a team of 5 could knock it out... ended up cutting the number of bugs down only marginally as stability was a core need, but the features were reduced to only 5.
Never once did I push back and say something wasn't a good idea, much of what happened was giving high level estimates, and if something was considered important enough, spending a few hours to a few days doing preliminary design work for a feature to better hone in on the effort. It was all details regarding difficultly/scope/risk to engender trust that the estimates were correct, and to let product pick and choose what were the most important things to address.
It’s not just about time or budget, at all. Some things are downright impossible without the appropriate data.
I mention this above but: I was recently in a situation where a PM wanted two calls to a pure mathematical function to have the same result even though the inputs were different.
I can patiently explain this multiple times and provide alternatives and try to explore the actual problem space, but it comes a point that the PM saying “maybe I should ask another engineer” becomes grating enough to make you want to quit.
Working with people who not only are unable to do their jobs but also refuse to listen to others has become too normalized in this industry.
> Working with people who not only are unable to do their jobs but also refuse to listen to others has become too normalized in this industry.
In parts of it, sure. But there really are places with higher quality of people. You will have to prove yourself a bit more to get hired there, of course.
What you're implying here is extremely disrespectful and uncalled for. This phrase alone says much more about you than it does about me.
The point of my story is that taking cheap shots at your interlocutor isn't the way to build software, or win discussions. Let's at least aim to be a bit more respectful towards each other here.
I hope the fact that you need good skills to get good jobs is not controversial.
I meant this as a message of hope: There really are good jobs out there, so don't give up on the industry!
However: even joining companies with amazing engineering departments, salaries and even great executive departments is not a guarantee that the software making process is at the same level. I say this with experience in one FAANG, two YC startups and two multi-billion-dollar unicorns.
There is a fundamental disdain towards both developers and users in the industry, visible on one side by the RTO/layoffs/AI-replacement, and on the other with dark patterns, cookie-banners, autoplay videos, behavioral experimentation and recklessness with data and general slowness.
I still maintain that saying "no" to things that damage the world and compromise the work is the duty of anyone calling themselves an engineer.
Finally, a Microsoft FrontPage for the 2020's
"control-freak" not necessary. For any known sequence/set of feature requirements it is possible to choose an optimal abstraction.
It's also possible to order the requirements in such a way, that introduction of next requirement will entirely invalidate an abstraction, chosen for the previously introduced requirements.
Most of the humans have trouble recovering from such a case. Those who do succeed are called senior software engineers.
Until a level of absolutely massive scale, modern tooling and code and systems reasonably built can handle most things technically, so it usually comes down to minimizing complexity as the #1 thing you can do to optimize development. And that could be
- code design complexity - design complexity - product complexity - communication complexity - org complexity
And sometimes minimizing these ARE mutually exclusive (most times not, and in an ideal world never… but humans...) which is why much of our job is to all push back and trade off against complexity in order to minimize it. With the understanding that there are pieces of complexity so inherent in a person/company/code/whatever’s processes that in the short term you learn to work around/with it in order to move forward at all, but hopefully in the long term make strategic decisions along the way to phase it out
Haven't we found a better term for that yet?
It is intentional, designed complexity...
There's no accident about it: engineers or management chose it.
Recent discussion on accidental versus essential (kicked off by a flagged article): https://news.ycombinator.com/item?id=44090302 (choosing good dichotomies is difficult, since there's always exceptions to both categories)
I don’t really care for the name but I care about grifters pretending it doesn’t really exist.
> It's architecting systems. And that's the one thing AI can't do.
Why do people insist on this? AI absolutely will be able to do that, because it increasingly can do that already, and we are now goalposting around what "architecting systems" means.
What it cannot do, even in theory, is decide for you to want to do something and decide for you what that should be. (It can certainly provide ideas, but the context space is so large that I don't see how it would realistically be better at seeing an issue that exists in your world, including what you can do, who you know, and what interests you.)
For the foreseeable future, we will need people who want to make something happen. Being a developer will mean something else, but that does not mean that you are not the person most equipped to handle that task and deal with the complexities involved.
In fact, I think this is the scary thing that people are ringing the alarm bells about. With enough surveillance, organizations will be able to identify you reliably out in the world enough to build significant amount of context, even if you aren’t wearing a pair of AI glasses.
And with all that context, it will become a reasonable task for AI to guess what you want. Perhaps even guess a string of events or actions or activities that would lead you towards an end state that is desirable by that organization.
This is primarily responding to that one assertion though and is perhaps tangential to your actual overall point.
I think that's the key. The only ones who can provide enough accurate context are software developers. No POs or managers can handle such levels of detail (or abstraction) to hand them over via prompts to a chatbot; engineers are doing this on a daily basis.
I laugh at the image of a non-technical person like my PO or the manager of my manager giving "orders" to an LLM to design a high-scalable tiny component for handling payments. There are dozens of details that can go wrong if not-enough details are provided: from security, to versioning, to resilience, to deployment, to maintainability...
It's also unlikely that context windows will become unbounded to the point where all that data can fit in context, and even if it can it's another question entirely whether the model can actually utilize all the information.
Many, many unknown unknowns would need to be overcome for this to even be in the realm of possibility. Right now it's difficult enough to get simple agents with relatively small context to be reliable and perform well, let alone something like what you're suggesting.
I don’t know if I really believe that it would be better than a human in every domain. But it definitely won’t have a cousin on the board of a competitor, reveal our plans to golfing buddies, make promotions based on handshake strength, or get canceled for hitting on employees.
To be CEO is to have opinions and convictions, even if they are incorrect. That's beyond LLMs.
More to the point, I was under the impression that current super-subservient LLMs were just a result of the fine-tuning process. Of course, the LLM doesn’t have an internal mental state so we can’t say it has an opinion. But, it could be fine-tuned to act like it does, right?
Who is fine-tuning the LLM? If you're having someone turns the dials and setting core concepts and policies so that they persist outside the context window it seems to me that they're the actual leader.
I’m speculating about a company run by an LLM (which doesn’t exist yet), so it seems plausible enough that all of the employees of the company could use it together (why not?).
Think about it: if, in 10 years, I create a company and my only employee is a highly capable LLM that can execute any command I give, who's going to be liable if something goes wrong? The LLM or me? It's gonna be me, so I better give the damm LLM explicit and non-ambiguous commands... but hey I'm only the CEO of my own company, I don't know how to do that (otherwise, I would be an engineer).
See, "AI" don't even have to guess it, I make full public disclosure of it. If anything can help with such a goal, including automated inference (AI) devices, there is no major concern with such a tool per se.
The leviathan monopolizing the tool for its own benefit in a detrimental way for human beings is an orthogonal issue.
¹ this is a bit anthropocentric statement, but it's a good way to favor human agreement, and I believe still actually implicitely require living in harmony with the rest of our follow earth inhabitants
For example, my mother calls and asks if I want to come over.
How is an AI ever going to have the context to decide that for me? Given the right amount and quality of sensors starting from birth or soon after – sure, it's not theoretically impossible.
But as a grown up person that has knowledge about the things we share, and don't share, the conflicts in our present and past, the things I never talked about to anyone and that I would find hard to verbalize if I wanted to, or admit to myself that I don't.
It can check my calendar. But it can't understand that I have been thinking about doing something for a while, and I just heard someone randomly talking about something else, that resurfaced that idea and now I would really rather do that. How would the AI know? (Again, not theoretically impossible given the right sensors, but it seems fairly far away.)
I could try and explain of course. But where to start? And how would I explain how to explain this to mum? It's really fucking complicated. I am not saying that llm's would not be helpful here by generalization monsters, actually it's both insane and sobering how helpful they can be giving the amount of context that they do not have about us.
Which means it cannot architect a software solution just by itself, unless it could read people's minds and know what they might want.
AIs can ——— on some time horizon ——— do anything that Is can do.
Just because one is organic-based doesn’t necessitate superior talent.
But if we want to do it anyway: the current stalls and approaches to iterating on LLM's do not give much short term promise. This approach seems to already be plateauing.
My guess though is that the lack of hiring is simply a result of the over saturation of the market. Just looking at the growth of CS degrees awarded you have to conclude that we'd be in such a situation eventually.
These things don't happen overnight though, it'll probably take a few years yet for the shock of whatever is going on right now to really play out.
We’ve been seeing layoffs for over 3 years…
That was before the pandemic and AI.
It was predictable that some layoffs would eventually happen, we just didn't know it would be so fast.
I wonder if it's AI, the market, both, or some other cause... :/
You think executives are gonna be saying, “yeah we’re laying off people because our revenue stinks and we have too high of costs!” They’re gonna tell people, “yeah, we definitely got AI. It’s AI, that’s our competitive edge and why we had to do layoffs. We have AI and our competitors don’t. That’s why we’re better. (Oh my god, I hope this works. Please get the stock back up, daddy needs a new yacht.)”
The layoffs started exactly as soon as the US government decided to stop giving free money to investment funds. A few days before they announced it.
A bit before it, it was clear it was going to happen. But I do agree that years earlier nobody could predict when it wold stop.
Depends on where too. Was just talking to a friend yesterday who works for a military sub (so not just software) and they said their projects are basically bottlenecked by hiring engineers.
Fintech unicorn that has AI in its name, but still forbids usage of LLMs for coding (my previous job) --> no hiring of juniors since 2023.
YC startup funded in 2024 heavily invested in AI (my current job) --> half the staff is junior.
I think the demand for developers will similarly fluctuate wildly while LLM:s are still being improved towards the point of being better programmers than most programmers. Then programmers will go and do other stuff.
Being able to make important decisions about what to build should be one of those things that should increase in demand as the price of building stuff goes down. Then again, making important technical decisions and understand their consequences have always been part of what developers do. So we should be good at that.
They were most certainly not! Which is why you had a solid 60+ years of sail+steam ships. And even longer for cargo! [0]
Parent picked a great metaphor for AI adoption: superior in some areas, inferior in others, with the balance changing with technological advancement.
[0] https://en.m.wikipedia.org/wiki/SS_Great_Western https://en.m.wikipedia.org/wiki/SS_Sirius_(1837) https://www.reddit.com/r/AskHistorians/comments/4ap0dn/when_...
So what are the areas that AI are superior to traditional programming? If your answer is suggestion, then refinement with traditional tooling, then it's just a workflow addon like contextual help, google search, and github code search. And I prefer the others because they are more reliable.
We have six major phases in the software development lifecycle: 1) Planning, 2) Analysis, 3) Design, 4) Implementation, 5) Testing, 6) Maintenance. I failed to see how LLM assistance is objectively better even in part than not having it at all. Everything I've read is mostly anecdote where the root cause is inexperience and lack of knowledge.
This is already happening. Over the past 4-5 years I've known more than 30 senior devs either transition into areas other than development, or in many case, completely leave development all together. Most have left because they're getting stuck in situations like you describe. Having to pick up more managerial stuff and AI isn't capable of even doing junior level work so many just gave up and left.
Yes, AI is helping in a lot of different ways to reduce development times, but the offloading of specific knowledge to these tools is hampering actual skill development.
We're in for a real bumpy ride over the next decade as the industry comes to gripes with how to deal with a lot of bad things all happening at the same time.
Planning is the ability to map concerns to solutions and project solution delivery according to resources available. I am not convinced AI is anywhere near getting that right. It’s not straightforward even when your human assets are commodities.
Acting on plans is called task execution.
Architecture is the design and art of interrelated systems. This involves layers of competing and/or cooperative plans. AI absolutely cannot do this. A gross hallucination at one layer potentially destroys or displaces other layers and that is catastrophically expensive. That is why real people do this work and why they are constantly audited.
And yet I can ask it how to architect my database in a logical way, and it clearly has solid ideas that again, it doesn’t script itself.
So really it teaches us or instructs us one way to do things, it’s not executing in any realm…yet
If people still had to think for themselves, what would be the point?
I mean we literally have a industry that just do that (Vercel,Netfly etc)
Not really. Programming means explaining the machine what to do. How you do it has changed over the years. From writing machine language and punching cards to gluing frameworks and drawing boxes. But the core is always the same: take approximative and ambiguous requirements from someone who doesn't really knows what he wants and turn it into something precise the machine can execute reliably, without supervision.
Over the years, programmers have figured out that the best way to do it is with code. GUIs are usually not expressive enough, and English is too ambiguous and/or too verbose, that's why we have programming languages. There are fields that had specialized languages before electronic computers existed, like maths, and for the same reason.
LLMs are just the current step in the evolution of programming, but the role of the programmer is still the same: getting the machine to do what people want, be it by prompting, drawing, or writing code, and I suspect code will still prevail. LLMs are quite good at repeating what has been done before, but having them write something original using natural language descriptions is quite a frustrating experience, and if you are programming, there is a good chance there is at least something original to it, otherwise, why not use an off-the-shelf product?
We are at the peak of the hype cycle now, but things will settle down. Some things will change for sure, as always when some new technology emerges.
I feel like a lot of people need to go re-read moon is a harsh mistress.
On the bright side, the element of development that is LEAST represented in teaching and interviewing (how to structure large codebases) will be the new frontier and differentiator. But much as scripting language removed the focus on pointers and memory management, AI will abstract away discrete blocks of code.
It is kind of the dream of open source software, but advanced - don't rebuild standard functions. But also, don't bother searching for them or work out how to integrate them. Just request what you need and keep going.
"Your job is now to integrate all of this AI generated slop together smoothly" is a thought that is going to keep me up at night and probably remove years from my life from stress
I don't mean to sound flippant. What you are describing sounds like a nightmare. Plumbing libraries together is just such a boring, miserable chore. Have AI solve all the fun challenging parts and then personally do the gruntwork of wiring it all together?
I wish I were closer to retirement. Or death
At this clip it isn't very hard to imagine the developer layer becoming obsolete or reduced down to one architect directing many agents.
In fact, this is probably already somewhat possible. I don't really write code anymore, I direct claude code to make the edits. This is a much faster workflow than the old one.
I don't see LLMs as much different really, our jobs becoming easier just means there's more things we can do now and with more capabilities comes more demand. Not right away of course.
The hard part is to have a consistent system that can evolve without costing too much. And the bigger the system, the harder it is to get this right. We have principles like modularity, cohesion, information hiding,... to help us on that front, but not a clear guideline on how to achieve it. That's the design phase.
Once you have the two above done, coding is often quite easy. And if you have a good programming ecosystem and people that know it, it can be done quite fast.
Largely, because there were still upstream blockers that constrained throughput.
Typically imprecise business requirements (because someone hadn't thought sufficiently about the problem) or operation at scale issues (poorly generalizing architecture).
> our jobs becoming easier just means there's more things we can do now and with more capabilities comes more demand
This is the repeatedly forgotten lesson from the computing / digitization revolution!
The reason they changed the world wasn't because they were more capable (versus their manual precursors) but because they were economically cheaper.
Consequently, they enabled an entire class of problems to be worked on that were previously uneconomical.
E.g. there's no company on the planet that wouldn't be interested in more realtime detail of its financial operations... but that wasn't worth enough to pay bodies to continually tabulate it.
>> The NoCode movement didn't eliminate developers; it created NoCode specialists and backend integrators. The cloud didn't eliminate system administrators; it transformed them into DevOps engineers at double the salary.
Similarly, the article feels around the issue here but loses two important takeaways:
1) Technologies that revolutionize the world decrease total cost to deliver preexisting value.
2) Salary ~= value, for as many positions as demand supports.
Whether are more or fewer backend integrators, devops engineers, etc. post-transformation isn't foretold.
In recent history, those who upskill their productivity reap larger salaries, while others' positions disappear. I.e. the cloud engineer supporting millions of users, instead of the many bodies that used to take to deliver less efficiently.
It remains to be seen whether AI coding will stimulate more demand or simply increase the value of the same / fewer positions.
PS: If I were career plotting today, there's no way in hell I'd be aiming for anything that didn't have a customer-interactive component. Those business solution formulation skills are going to be a key differentiator any way it goes. The "locked in a closet" coder, no matter how good, is going to be a valuable addition for fewer and fewer positions.
I am finding LLMs useful for coding in that it can do a lot of heavy lifting for me, and then I jump in and do some finishing touches.
It is also sort of decent at reviewing my code and suggesting improvements, writing unit tests etc.
Hidden in all that is I have to describe all of those things, in detail, for the LLM to do a decent job. I can of course do a "Write unit tests for me", but I notice it does a much better job if I describe what are the test cases, and even how I want things tested.
If anyone's moving the "architecture" goal posts it would be anyone who thinks that "architecture" so much as fits into the context window of a modern LLM, let alone that they are successfully doing it. They're terrible architects right now, like, worse than useless, worse than I'd expect from an intern. An intern may cargo cult design methodologies they don't understand yet but even that is better than what LLMs are producing.
Whatever the next generation AI is, though, who can tell. What an AI could do that could actually construct symbolic maps of a system, manipulate that map directly, then manifest that in code, could accomplish is difficult to say. However nobody knows how to do that right now. It's not for lack of trying, either.
Because it isn't even close to entry level architecture. And the structure of LLM's makes it hard to iterate the way architecture requires. It basically gets a little bit of context only to essentially tear down and rebuild at blistering speeds. You can't really architect that way.
>What it cannot do, even in theory, is decide for you to want to do something and decide for you what that should be.
Something sadly common among clients, even large ones.
I tried to formalize and embed information about infrastructure, so AI generated code can adapt to that, but there are serious challenges. I wish I would get an AI secretary, but in that case please be a real human.
AI is much better at creating code line by line with small context windows. If it gets too big and complicated, the code will certainly not run or work. Statistical certainty with the same mechanisms that make AI work in the first place.
If an AI can create a project, it has to be completely self-contained. Still useful, but also restricted.
And AI embedding is another pain in the arse and even the large tech firms fail here. It is so much work to prepare data for embedding. Human work, since AI isn't fit to do that yet. Maybe it will, but it would be naive to estimate that you can finally rest as a developer. There will be other bullshit to deal with.
The only people that value quality are engineers. Any predictions of the future by engineers that rely on other people suddenly valuing quality can safely be ignored.
If customers didn't value quality, then every startup would have succeeded, just by providing the most barely functioning product at the cheapest prices, and making enough revenue by volume.
You've just described hustle culture. And yes, it does lead to business success. Engineers don't like hustle.
> Hustles don't fail
Then by definition there should be few engineers with financial problems, right? Almost every engineer wants to succeed with their side hustle
You're still only thinking in terms of startups. I'm thinking about landscapers and ticket scalpers. No engineer is doing that. But if you were willing to, you'd make money.
It sounds a lot like you're saying "all engineers are lazy" and that's just obviously wrong.
> providing the most barely functioning product at the cheapest prices, and making enough revenue by volume
This is hustling.
Plenty of engineers are building barely-functional products as fast (cheap, because time is money) as can be and doing a ton of volume. The entire Bangalore contractor scene was built this way, as well as a ton of small Western contractor shops. You honestly think no engineers understand undercutting competition? Really?
I'm not sure though I'd call business folks with software products that are hustling engineers. Different mindset.
It sounds like you've bought into some ridiculous "sigma grindset" nonsense and you're now gatekeeping it as an identity. For your own good, stop. Contrary to what you seem to believe, hustles do fail, and if you close your mind to that possibility you're going to eventually hustle on the wrong thing and burn yourself out on a hustle that doesn't work. And even if you don't, you'll make yourself intolerable to anyone you'd want to interact with. It's not a good path.
Of course it is.
> It sounds like you've bought into some ridiculous "sigma grindset" nonsense and you're now gatekeeping it as an identity.
This kind of rationalistic bullshit is exactly what I make it my mission to rail against on HN. Speaking in a general sense can only be done well from an intuititionist perspective. My original post on this garnered 25 upvotes, quite above average these days. You're the one mistaking my generalization for gatekeeping, and it's precisely because you're holding on to a rationalist mindset, so you project that onto others.
All I was doing was committing to the bit. No half-measures for me. Nobody follows threads after the first day or so anyway. No harm in continuing discussions past the sell-by date.
The terms "rationalist" and "institutionalist" you're using have too many different meanings in different contexts for this to be a meaningful set of sentences. Care to define your terms or use different ones so I can tell what you're talking about?
> My original post on this garnered 25 upvotes, quite above average these days.
I do not care how popular a wrong idea is. This is especially true on HN, where the focus on profit over humans has led to extremely harmful ideologies becoming popular.
> All I was doing was committing to the bit.
So this was supposed to be a joke? It was pretty unfunny.
Rationalist: someone who only values positivistic reasoning. Someone like this does not have a useful guide to truth and typically deigns to fill the role themselves.
Intuitionist: someone who is comfortable dealing in vague, messy, imprecision. The kind of stuff the real world is based on.
> I do not care how popular a wrong idea is.
I do not care whether you care or not or whether you think it's wrong or not. This is that 'not having a useful guide to truth so you deign to fill the role yourself'. If you had a useful guide to truth in this instance, your argument that it's wrong would be based on that, not just on your feelings.
I'll give an example so as to not leave you completely lost. If I told you 1+1=3, then you could prove it to me that I'm wrong. All you'd need is a few apples. This would be a positivistic approach to reasoning and since you're a rationalist, this is the kind of reasoning you value.
If you tried to convince me Naziism was the best political theory, I would have two fundamentally different ways to respond. I could try the rationalist way, to attempt to construct a convincing argument through the history of political movements, perhaps grounding my argument in the idea of best for most.
But intuitionist me knows that's a dumb plan, and would just solve it by having the bartender throw you out of the bar, no nazis allowed.
The reason the rationalist approach to the Nazi question doesn't work is because positivistic logic must flow from something and that something must be a settled place of knowledge, the justified true belief. Political philosophy isn't a positivistic domain. You can't prove Naziism isn't the best political philosophy because politics is one group of people having power over others. Nazis are immune to reason. That's why no nazis in bars.
When rationalists try to operate in non-positivistic domains, they get out of their element quickly, because rationalists tend to discount the humanities as useful fields to study, and so they have to substitute something other than knowledge to form positivistic arguments.
An intuitionist very much values the humanities and realizes, over time, the limitations of positivism. If you study enough of the humanities, you will form an intuitive view of the world that can survive being challenged, proof isn't as useful as the rationalist thinks it is. A rationalist's view of reality is thus brittle, while intuitionist understanding is flexible.
And so when you said I was buying into some sigma grindset bullshit, that's an example of rationalist reduction of someone's understanding as similar. In reality I was just intuitively wandering around the space of what different folks in and around business care about, using my experience in corporate America as a guide. I identified this idea of 'hustle' as separating two different mindsets and was trying to sketch a loose picture of what this was.
An fellow intuitionist would see exactly what I was trying to do, and would help with his own intuitive understandings of business. A rationalist is only interested in reductive determination, so you reductively deduced me to 'sigma grindset' guy.
Anyway, that was fun to write, even though I'm pretty sure you aren't going to follow.
So... you basically define "rationalist" as someone who is wrong. Sounds like a pointless word to me. And let me guess, you're going to call me a rationalist later, rather than actually respond to anything I said? Let's continue and find out!
> Intuitionist: someone who is comfortable dealing in vague, messy, imprecision. The kind of stuff the real world is based on.
So... someone who doesn't use phrases like "no engineer" because they're obviously wrong in a messy, imprecise world?
It doesn't sound much like you're the intuitionist here, but I am sure you think you are!
> I do not care whether you care or not or whether you think it's wrong or not. This is that 'not having a useful guide to truth so you deign to fill the role yourself'. If you had a useful guide to truth in this instance, your argument that it's wrong would be based on that, not just on your feelings.
My argument wasn't based on my feelings. It's based on your beliefs. I'm appealing to your belief that popularity isn't equivalent to correctness. And if you're going to pretend you don't believe that, I'm out, because you're not making an honest argument.
> An fellow intuitionist would see exactly what I was trying to do, and would help with his own intuitive understandings of business. A rationalist is only interested in reductive determination, so you reductively deduced me to 'sigma grindset' guy.
Wow, what self-congratulatory nonsense.
Maybe, the intuitionist isn't interested in helping you reduce the world into two deterministic roles: hustling business people and quality-focused engineers. Maybe, the intuitionist's experience has led them to a very different intuition, because they actually care about understanding what other people are doing instead of congratulating themselves for getting a business degree.
To use your silly terminology, the intuitionist solution to people like you dismissing pretty obvious facts isn't to argue facts, because you're more interested in sounding smart than in reality. The solution is to dismiss your nonsense as "sigma grindset bullshit" or some equally pejorative AND ACCURATE description. The argumentative equivalent of kicking the Nazi out of the bar.
Believe it or not, one can be an intuitionist without losing interest in the truth. One can both kick the Nazi out of the bar and argue against Nazism.
But hey, if you want to work yourself to death on a hustle that fails because you think hustling sounds masculine, have at that sigma grindset bro. All I ask is that you don't spread that mental illness.
Lol. I trade the markets. One trade, ten minutes. Then I catch up on socials, close up the machine then do whatever the hell I want. You wouldn't catch me dead doing anything remotely resembling hustling. Read my essay again. Or don't!
The only people that often value quality are engineers.
I might even add that the overwhelming majority of engineers are happy to sacrifice quality - and ethics generally - when the price is right. Not all, maybe.
It's a strange culture we have, one which readily produces engineer types capable of complex logic in their work, and at the same time, "the overarching concern of business is always profit" seems to sometimes cause difficulty.
We are in this weird twilight zone where everything is still relativity high quality and stuff sort of works but in a few decades shit will start degrading faster than you can say “OpenAI”.
Weird thing will start happening like tax systems for the government not being able to be upgraded while consuming billions, infrastructure failing for unknown reasons, simple non or low-power devices that are now ubiquitous will become rare. Everything will require subscriptions and internet access and nothing will work right. You will have to talk to LLMs all day.
But, then there will be a demand for "all-in-one" reliable mega apps to replace everything else. These apps will usher in the megacorp reality William Gibson described.
Is it? AI very much seems to be in market capture mode. And IIRC, very few businesses actually report profits.
I can only predict AI models ramping up the cost like crazy once the victor captures the market. Same as every other tech trend in the last 20 years.
Regardless which model is currently the best, it looks like there will be an open weight model ~6 months behind it which can be vendored at costs that are closely tied to the hardware costs.
When we got healthcare.gov it was pretty much this, maybe worse actually. Website was unusable and delivered like 5% of the requirements. It was pretty bad and people were pissed.
Of course in typical American government fashion, the task was outsourced to some companies in the private sector. Which then took 2 years to do it, went way over budget, and still delivered nothing.
I don’t know about Medicaid, but the other two are already true right now.
First of all, all the most successful software products have had very high quality. Google search won because it was good and fast. All the successful web browsers work incredibly well. Ditto the big operating systems. The iPhone is an amazing product. Facebook, Instagram, TikTok; whatever else you think, these are not buggy or sluggish products, (especially in their prime). Stripe grew by making a great product. The successful B2B products are also very high quality. I don't have much love for Databricks, but it works well. I have found Okta to be extremely impressive. Notion works really well. (There are some counterexamples: I'm not too impressed by Rippling, for instance.)
Where are all these examples of products that have succeeded despite not valuing quality?
These days when site crashes I welcome it as a gentle reminder to not spend there even that 1 minute I sometimes do. Anyway its now mostly fake ai generated ads to obscure groups I have 0 interest in, I keep reporting them to FB but even for outrighr fraud or scams FB comes back to me with resolution in maybe 2% of the cases. EU on you you cheap scammers.
But in the past I used it for ie photo sharing with family and friends, since I was super active in adventuring and travelling around the world. Up to 10k photos over a decade.
Photo albums uploads randomly failed, or uploaded some subset, some photos twice. On stable fiber optic, while flickr or google photos never ever had such issue. Cannot comment, some internal gibberish error. Comment posted twice. Page reloads to error. Links to profiles or photos go to empty page. Sometimes even main page just empty feed or some internal error. I saw the sentence "Something went wrong" hundreds or maybe even thousands of times, it became such a classic 500 variant. And so on and on, I dont keep list around. Always on Firefox and ublock origin.
I would be properly ashamed to be ever profesionally linked with such, by huge margin, worst technical product that I ever came across. That is, if I could somehow ignore what a cancer to society I would be helping to build, but that would require advanced sociopathical mental tricks on myself I am simply neither capable nor willing to do.
Nah, FB doesnt deserve to be mentioned in same category as the rest, on any reasonable basis.
I agree that my impression of facebook when I started using it (around '04) I think, was "what is this, like seven php files? I could make this!", but by the time of their IPO I thought it was pretty well polished. It's accumulated a lot of cruft since then.
Salesforce. Quickbooks. Any Oracle product.
Fucking Windows.
Windows products since the 2000s. They may have won on quality early on but today succeed mainly via compliance controls and switching costs IMO.
Also big legacy B2B digital systems of record. Pretty much any ERP. Can’t say firsthand but this is my impression of SAP products and Oracle products. Also Encompass, the system of record for a large majority of the U.S. mortgage market. Most medical software.
There are a lot of recordkeeping systems that have a massive moat from handling decades worth of nuance. Their “quality” by modern UX and performance standards is very poor but they handle all the nooks and crannies of their industry.
If think you're really close with one nuance.
Business does not value CODE quality. Their primary goal is to ship product quickly enough that they can close customers. If you're in a fast moving or competitive space, quality matters more because you need to ship differentiating features. If the space is slow moving, not prone to migration, etc, then the shipping schedule can be slower and quality is less important.
That said, customers care about "quality" but they likely define it very differently.. primarily as "usability"
They don't care about the code behind the scenes, what framework you used, etc as long as the software a) does what they want and b) does it "quick enough" in their opinion.
Business folks love to say this, but a lot of this time this is glossing over a pretty inherent coupling between code quality and doing what users want quick enough. I've worked on a lot of projects with messy code, and that mess always translated into problems which users cared about. There isn't some magical case where the code is bad and the software is great for the users--that's not a thing that exists, at least not for very long.
If someone in the supply chain before you cares more about something being cheap, then that is all you get.
They build hardware-based amp/pedal modelers (e.g. virtual pedalboards + amp) for guitars that get a very steady stream of updates. From a feel and accuracy perspective, they outcompete pretty much everyone else, even much bigger companies such as Line 6 (part of Yamaha). Pretty small company AFAIK, maybe less than 20 people or so. Most of the improvements stem from the CEO's ever-improving understanding of how to model what are very analog systems accurately.
They do almost everything you shouldn't do as a startup:
* mostly a hardware company
* direct sales instead of going through somewhere like Sweetwater
* they don't pay artists to endorse them
* no subscriptions
* lots of free, sometimes substantial updates to the modeling algorithms
* didn't use AI to build their product quickly
Quality is how they differentiate themselves in a crowded market.
This isn't an edge case, either. This is how parts of the market function. Not every part of every market is trapped in a race to the bottom.
Similarly with the example: lots of guitarists are keen on NAM (Neural Amp Modeler) because it is free and runs on a PC, or one of the cheaper hardware pedals such as the ToneX. The low-end of this market is always chasing the high-end, but these cheaper options are fantastic for the sound quality they can produce and have come a long way from the L6 Pods of years ago.
Completely agree.
> They'll buy the cheapest tools on Amazon and happily vibe code their way into a hole, then throw the broke code out and vibe code some more.
Now I completely disagree and it is easy to prove: Apple. I don't need to say anything else.
1. The push for "software architects" to create plans and specifications for those pesky developers to simply follow. I remember around 2005, there was some hype around generating code from UML and having developers "just" fill in the blanks. The result I've observed were insanely over engineered systems where even just adding a new field to be stored required touching like 8 files across four different layers.
2. The "agile transformation" era that followed shortly after, where a (possibly deliberate) misunderstanding of agile principles lead to lots of off-the-shelf processes, roles, and some degree of acceptance for micro managing developers. From what I've seen, this mostly eroded trust, motivation and creativity. Best case scenario, it would create a functioning feature factory that efficiently builds the wrong thing. More often than not, it just made entire teams unproductive real fast.
What I've always liked to see is non-developers showing genuine interest in the work of developers, trying to participate or at least support, embracing the complexity and clarifying problems to solve. No matter what tools teams use and what processes they follow, I've always seen this result in success. Any effort around reducing the complexity inherent in software development, did not.
> And as we'll see, that's the one skill AI isn't close to replacing.
Yet we never 'see' this in the article. It just restates it a few times without providing any proof.
I'd argue the opposite: specifically asking AI for designing an architecture already yields better results than what a good 30% of 'architects' I've encountered could ever come up with. It's just that a lot of people using AI don't explicitly ask for these things.
I.e writing the prompt, understanding the answers, pushing back etc.
Unless AI is introduced as a regular coworker and stakeholder wants to communicate with it regularly, I don't see this changing anytime soon.
Reverse engineering stuff when non-cooperative stakeholders dominate the project has its limits too and requires "god mod" type of access to internal infrastructure, which is not something anybody gets.
Architects are like managers, it's way harder than people imagine and very few people can actually do the work.
Also I hate that "architect" is used as a synonym of "cloud architect". There is much more to software architecture than cloud.
I don't know whether you were actually looking for an architect? There are different types of architects. For example, you have got enterprise architects that indeed will never touch yaml, you have got solution architects who have a more narrow focus, and you have got engineers with a plate of overbearing work and team responsibilities. The latter are better called lead engineer. In my experience, being a good (lead) engineer doesn't make one a good architect, but companies try to make their job posting more sexy by titling it with "architect". One would imho do better by taking lead engineers seriously just in their own right.
Architects in general need to be very skilled in abstract reasoning, information processing & conceptual thinking. However, the people hiring for an "architect" often look for a 2x/nx engineer, who is able to code x widgets per hour. That is a stupid mismatch.
I would agree however that someone without previous practical experience would be rather unsuitable, especially "below" enterprise architect level.
> Andreessen said that venture capital might be one of the few jobs that will survive the rise of AI automation. He said this was partly because the job required several “intangible” skills and was more of an art than a science.
https://fortune.com/article/mark-andreessen-venture-capitali...
I've seen a lot more ai-generated art than ai-generated science.
Ex: If you're a lazy typist like most, then a code assistant can speed you up significantly, when you use it as an autocomplete plus. But if you're a very practiced vim user and your fingers fly over the keyboard, or a wizard lisp hacker who uses structural editing, then a code assistant slows you down or distracts you even.
Ohhh, you mean power point writers. Sorry, lost you for a minute there.
On the other hand, they are pretty poor at reasoning from first principles to solve problems that are far outside their training corpus. In some domains, like performance-sensitive platforms, the midwit solution is usually the wrong one and you need highly skilled people to do the design work using context and knowledge that isn’t always available to LLMs. You could probably use an LLM to design a database kernel but it will be a relatively naive one because the training data isn’t available to do anything close to the state-of-the-art.
I'm honestly shocked by the number of upvotes this article has on Hacker News. It's extremely low quality. It's obviously written with ChatGPT. The tells are:
(1) Incorrect technology "hype cycle". It shows "Trigger, Disillusionment, Englightnment Productivity". It's missing the very important "Inflated Expectations".
(2) Too many pauses that disrupt the flow of ideas:
- Lots of em-dashes. ChatGPT loves to break up sentences with em-dashes.
- Lots of short sentences to sound pithy and profound. Example: "The executives get excited. The consultants circle like sharks. PowerPoint decks multiply. Budgets shift."
(3) "It isn't just X, it's X+1", where X is a normal descriptor, where X+1 is a more emphatic rephrasing of X. ChatGPT uses this construct a lot. Here are some from the article:
- "What actually happens isn't replacement, it's transformation"
- "For [...] disposable marketing sites, this doesn't matter. For systems that need to evolve over years, it's catastrophic."
Similarly, "It's not X, it's inverse-X", resulting in the same repetitive phrasing:
- "The NoCode movement didn't eliminate developers; it created NoCode specialists and backend integrators."
- "The cloud didn't eliminate system administrators; it transformed them into DevOps engineers"
- "The most valuable skill in software isn't writing code, it's architecting systems."
- "The result wasn't fewer developers—it was the birth of "NoCode specialists""
- "The sysadmins weren't eliminated; they were reborn as DevOps engineers"
- "the work didn't disappear; it evolved into infrastructure-as-code,"
- "the technology doesn't replace the skill, it elevates it to a higher level of abstraction."
- "code is not an asset—it's a liability."
---------
I wish people stopped using ChatGPT. Every article is written in the same wordy, try-to-hard-to-sound-profound, ChatGPT mannerisms.
Nobody writes in their own voice anymore.
The author of this post is right, code is a liability, but AI leaders have somehow convinced the market that code generation on demand is a massive win. They're selling the industry on a future where companies can maintain "productivity" with a fraction of the headcount.
Surprisingly, no one seems to ask (or care) about how product quality fares in the vibe code era. Last month Satya Nadella famously claimed that 30% of Microsoft's code was written by AI. Is it a coincidence that Github has been averaging 20 incidents a month this year?[1] That's basically once a work day...
Nothing comes for free. My prediction is that companies over-prioritizing efficiency through LLMs will pay for it with quality. I'm not going to bet that this will bring down any giants, but not every company buying this snake oil is Microsoft. There are plenty of hungry entrepreneurs out there that will swarm if businesses fumble their core value prop.
I am in the other camp. Companies ignoring AI are in for a bad time.
My point was more of a response to the inflated expectations that people have about AI. The current generation of AI tech is rife with gotchas and pitfalls. Many companies seem to be making decisions with the hope that they will out-innovate any consequences.
AI, especially for programming, is essentially no better than your typical foriegn offshore programming firm, with nonsensical comments and sprawling conflicting code styles.
If it eventually becomes everything the proponents say it will, they could always just start using it more.
[1] AI: Accelerated Incompetence. https://www.slater.dev/accelerated-incompetence/
Yes, this. 100% this. The goal is for a program to serve a goal/purpose with the least a amount of code possible. AI does the exact opposite. Now that code generation is easy, there is no more natural constraint preventing too much liability.
https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...
What's the difference (from an LLM point of view) between code generated one week ago and code generated now? How does the LLM know where or how to fix the bug? Why the LLM didn't generate the code without that particular bug to begin with?
> Because, until recently, it was very costly to replace the code. AI "programmers" will create completely new code in a few minutes so there's no need to maintain it. If there are new problems tomorrow, they'll generate the code again.
In order for the programmer to know what change needs to be made to fix the bug, the programmer needs to debug the code first. But if code is costly to replace (and we'll use LLMs to regenerate code from scratch in that case), code is also costly to debug (reason for code being costly to replace is that code has grown to be an unmaintanable mess... that's the very same reason debugging is also costly).
Also, it doesn't make sense to ask programmers to debug and tell LLMs to code. Why not tell directly the LLM to debug as well?
So, your scenario of generating "new code" every time doesn't really sustain itself. Perhaps for very tiny applications it could work, but for the vast majority of projects where usually ~100 engineers work, it would lead to an unmaintainable mess. If it's unmaintainable, then no programmer can debug it efficiently, and if no programmer can debug it, no one can tell the LLM to fix it.
AIs can debug code too. And the "programmer" doesn't need to know how to fix, only describe what error is happening.
I guess the question is "replaced with what?" How can you be sure it's a 1:1 replacement?
Have you looked at much top-tier website code lately?
http://www.softwarepreservation.org/projects/FORTRAN/BackusE...
And that’s where it starts to get interesting.
The current generation of generative AI based on LLMs simply won't be able to properly learn to code large code bases, and won't make the correct evaluative choices of products. Without being able to reason and evaluate objectively, you won't be a good "developer" replacement. Similar to how asking LLMs about (complex) integrals, it will often end it's answer with "solution proved by derivation", not because it has actually done it (it will also end with this on incorrect integrals), but because that's what its training data does.
It's entirely possible that in 5 or 10 years at least some developers will be fully replaced.
(And probably a lot of people in HR, finance, marketing, etc. too.)
I think you hit on something with finance as well. Give Microsoft a decade of improving AI's understanding of Excel and I'm thinking a whole lot of business analyst types would be unnecessary. Today, in an organization of 25 or 50 thousand employees, you may have dozens to hundreds depending on the industry. Ten years from now? Well, let's just say no one is gonna willingly carry hundreds of business analysts salaries on their books while paying the Microsoft 365AI license anyway. Only the best of those analysts will remain. And not many of them.
But also thousands of companies are going to be able to implement with a team of 1-10 people what before was only available to organizations of 25 or 50 thousand employees.
Maybe 5 or 10 years things will change, but at this point I can't see myself being replaced without some sort of paradigm shift, which is not what the current brand of AI improvements are offering - it seems like they are offering iterations of the same thing over and over, each generation slightly more refined or with more ability to generate output based upon its own output - so I see no reason to assume my job is in jeopardy just because it might be at some later date.
Someone needs to tell me what exactly is going to change to cause this sudden shift in what AI can do, because right now I don't see it. It seems to have given people a licence to suggest science fiction be treated like a business plan.
And don't think that because the crazy "everything will be AI in 6 months" predictions predictably haven't come to pass that that means it won't ever happen.
I'm old enough to remember the failure of online clothes shopping in the dot-com era. Sometimes things just take a while.
Sure it not yet happening doesn't mean it won't ever happen, but it also no evidence that it will. When the latest apocalypse cult fails to predict the end of the world does that make you more or less convinced that the world will end the next time someone yells it? The longer this future developer apocalypse is delayed the less credible it seems.
I mean... hopefully it is really obvious why those are very different!
It's like how building an house is pretty much logistic and repetitive works. Designing an house is complex enough that you requires a degree and years of experience before you're trusted to do it well.
AI is fundamentally different in that regard.
There should be a name for this fallacy - the previous attempts failed therefore all attempts will fail.
Important to note I'm not saying there is no technology ever that won't fill that gap, GenAI probably would, but I'm not at all convinced that LLMs are the right tech to do everything that needs to be done to replace devs.
Currently most projects are outside of the capabilities of AI. Platforms can get better and add more features, why is that different than AI getting better and can do more?
Back then it wasn't known if it was possible to make these platforms generic enough that you could replace programmers. You couldn't.
Today we aren't sure if it is possible to make transformer based AI generic enough to replace programmers. Time will tell if we can.
So to me it looks exactly the same.
But these are the precise improvements that require a fundamental change to how these systems work.
So far, no one has figured out how to make AI systems achieve this. And yet, we're supposed to believe that tinkering with LLMs will get us there Real Soon Now.
They can be a useful tool, but their current capabilities and (I personally believe) their ability to improve indefinitely are wildly overhyped. And the industry as a whole has some sort of blinders on, IMO, related to how progress made with them is lumpy and kind of goes in both directions in the sense that every time someone introduces their grand new model and I play around with it I'll find some things it is better at than the previous version and some things it is worse at than the previous version. But number go up, so progress... I guess?
On one hand I can laugh this all off as yet another management fad (and to be clear, I don't think LLM usage is a fad, just the idea that this is going to be world-changing technology rather than just another tool), but what scares me most about the current AI hype isn't whether LLMs will take all of our jobs, but rather the very real damage that is likely to be caused by the cadre of rich and now politically powerful people who are pushing for massive amounts of energy production to power all of this "AI".
Some of them are practically a religious cult in that they believe in human-caused climate change, but still want to drastically ramp up power production to absurd levels by any means necessary while handwaving away the obvious impact this will have by claiming that whatever damage is caused by the ramp up in power production will be solved when the benevolent godlike AI that comes out on the other side will fix it for us.
Yeah, I uh don't see it working out that way. At all.
But yeah I think I agree. By the time my job is actually fully redundant, society is fucked anyway.
Some were entirely replaced already, like landing page developers. But the amount of AI/nocode developers is much bigger and growing fast so no dev roles were eliminated. That is just of more of the same in tech, keeping up with it.
(only a bit /s)
But if it's false, there's no saying you can't eventually have an ai model that can read your entire aws/infra account, look at logs, financials, look at docs and have a coherent picture of an entire business. At that point the idea that it might be able to handle architecture and long term planning seems plausible.
Usually when I read about developer replacement, it's with the underlying assumption that the agents/models will just keep getting bigger, better and cheaper, not that today's models will do it.
When AIs are largely on their own, their practices will evolve as well, but without there being a population of software developers who participate and follow those changes in concepts and practices. There will still have to be a smaller number of specialists who follow and steer how AI is doing software development, so that the inevitable failure cases can be analyzed and fixed, and to keep the AI way of doing things on a track that is still intelligible to humans.
Assuming that AI will become that capable, this will be a long and complex transition.
Think about it this way: five years ago plenty of companies hired more SWEs to increase productivity, gladly accepting additional cost. So it’s not about cost imo.
I might be wrong, but perhaps a useful way to look at all of this is to ignore stated reasons for layoffs and look at the companies themselves.
I don't quite agree. I see the skill in translating the real world with all its inconsistencies in to something a computer understands.
And this is where all the no/lo-code platforms fall apart. At some point that translation step needs to happen and most people absolutely hate it. And now you hire a dev anyway. As helpful as they may be, I haven't seen LLMs do this translation step any better.
Maybe there is a possibility that LLMs/AI remove the moron out of "extremely fast moron" that are computers in ways I haven't yet seen.
I suspect that if current trends continue, today's higher level languages will eventually become lower level languages in the not so distant future. It will be less important to know them, just like it is not critical to know assembly language to write a useful application today.
System architecture will remain critical.
Building a software was always about using those abstractions to solve a problem. But what clients give us are mostly wishes and wants. We turn those into a problem, then we solve that problem. It goes from "I want $this" (requirement) to "How can $this be done?" (analysis), then to "$this can be done that way" (design). We translate the last part into code. But there's still "Is $this done correctly?" (answered by testing) and "$this is no longer working" (maintenance).
So we're not moving to natural language, because the whole point of code is to ossify design. We're moving towards better representation of common design elements.
"We're moving towards better representation of common design elements."
I would say big component (maybe 90%) of the new abstractions created is fashion. So the representation is often becoming less common, in the sense, more fragmented.
I think the hope is for natural language to fix this, by being the common language to describe abstractions, and to somehow reduce the fashion element. That's the promise of AI.
But if it will happen - I am a bit skeptical because it's the (human need to create) fashion that's unaddressed elephant in the room.
Human languages is the ultimate leaky abstraction, because while you can put names on something, you needs more words to refine it, and that action is recursive.
That’s why formal language was born. And then we invented computers for automated interpretation of formal notation. All the current abstractions are still formal (the semantic is unambiguous as soon as the variables are fixed)
The transition from natural to formal is not a probabilistic process. It’s identifying a set of abstractions that closely fit the ambiguous nature of the natural soecifications, then going on to compose them and fixing variables. This is the design process. The result is made real by the code, which is the complete specification.
I think this time there is a key difference: AI coding is fully embedded into a software dev's workflow, and it indeed cuts loads of work for at least some of the projects and engineers. In contrast, few, if none, engineers would go to a No-Code/Low-Code tool and them maintain them in their repo.
The impact would be that we will need fewer engineers as the productivity of us increases. That alone may not be enough to change the curve of supply and demand. However, when this is combined with the current market condition of lacking business growth, the curve will be changed: the fewer new problems we have, the more repetitive solutions we will get, the more repetitive solutions we will work on, the more accurate the code generated by AI will be, and therefore the less code we will need a human to write.
So, this time it will not be about AI replacing engineers, but about AI replacing enough repetitive work that we will need fewer engineers.
> The result wasn't fewer developers
Makes me wonder if the right thing to do is to get rid of the non-developers instead?
In other words, they are very economical replacements for many non-developers.
And the most valuable skill in defending a stance is moving goal posts.
Is this bad news? It means that managers who think too much of their "great" ideas (without having a deep knowledge of the respective area) and want "obedient" subordinates will be in for a nasty surprise. :-)
The team used supplemental oxygen on the climb, with the starting altitude and flow rate not being reported [1]. This is speculative, but if they were using more oxygen than typical and starting at a lower altitude, that's a massive advantage.
Further, Andrew Ushakov traveled from NYC to the summit in just under 4 days this year without the use of xenon (but also with supplemental oxygen with unknown starting altitude and flow rate). He used a hypoxic tent to prepare as well, and depending on the accuracy of the reporting may have even spent less time doing that than the xenon team did [1].
[0] https://www.npr.org/2025/05/18/nx-s1-5398553/a-new-company-i... [1] https://www.alanarnette.com/blog/2025/05/21/everest-2025-fas...
Visual programming (NoCode/LowCode) tools have been very successful in quite a few domains. Animation, signal processing, data wrangling etc. But they have not been successful for general purpose programming, and I don't think they ever will be. More on this perenial HN topic at:
https://successfulsoftware.net/2024/01/16/visual-vs-text-bas...
I would bet on those against your assertion.
but I digress.
I agree with the core of the idea though, and I have written about it as well (https://www.linkedin.com/posts/brunocborges_ai-wont-eliminat...).
Where the author just asked gpt to "tell me why AI can't replace my job".
So — little — content. This — is — slop.
*I mean the whole first section is the most AI sounding thing I've ever seen, even the attempt at a punchy opening is obvious:
The executives get excited. The consultants circle like sharks. PowerPoint decks multiply. Budgets shift.
And then reality sets in.
Also, something being a liability and something having upkeep costs are not the same thing.
What would your definition of /liability/ be then? 'An ongoing commitment to pay future costs' is a pretty good one.
> Code is not an asset, it's a liability.
> Every line must be maintained, debugged, secured, and eventually replaced. The real asset is the business capability that code enables.
> The skill that survives and thrives isn't writing code. It's architecting systems. And that's the one thing AI can't do.There's a pretty big herd of sacred cows in programming and this debate always surfaces them. But I remember similar arguments being made about Go once and its version of human beings' special something. We saw then that sacred cows don't live long when AI really arrives.
It can happen that AI will get good enough to help with the human aspect of software development but using playing Go as an analogy doesn't really work.
SQL, with all its warts, has not been dethroned. HTML is still king.
This is like saying your transportation fleet as a delivery company isn’t an asset but a liability, it makes no sense.
Almost all assets require varying amounts of maintenance.
Those default ground-state of those tanks are liabilities. They may be assets today, but maintaining that conditional status requires constant work.
God I felt like I was the only one that noticed. People would say 'DevOps can code' as if that made DevOps a new thing, but being able to automate anything was a core principle of the SAGE-style systems admin in the 90s / early 2000s.
But AI can do some architecting. It's just not really the sort of thing where an unskilled person with a highly proficient LLM is going to be producing a distributed system that does anything useful.
It seems to me that the net effect of AI will be to increase the output of developers without increasing the cost per developer. Effectively, this will make software development cheaper. I suppose it's possible that there is some sort of peak demand for software that will require less developers over time to meet, but, generally, when something becomes cheaper, the demand for that thing will tend to increase.
I think the rumors of our demise are overblown.
This was the response by non-developers to make it obsolete to need to spell out your business details to an expensive programmer who, we presume, will just change them anyhow and make up their own numbers!
That didn't work for shit either, although to the authors point it did create a ton of jobs!
Seeing the difference in complexity between a distributed "monolith" and an actual one makes me wonder how serious some of us are about serving the customer. The speed with which you can build a rails or PHP app makes everything proposed since 2016 seem kind of pointless from a business standpoint. Many SaaS B2B products could be refactored into a single powershell/bash script.
It can take a very firm hand to guide a team away from the shiny distractions. There is no way in hell an obsequious AI contraption will be able to fill this role. I know for a fact the LLMs are guiding developers towards more complexity because I have to constantly prompt things like "do not use 3rd party dependencies" and "demonstrate using pseudocode first" to avoid getting sucked into npm Narnia.
That's interesting, I remember talking to the CTO of a big American bank in the nineties who told me the opposite. They wanted to buy rather than build.
Nobody knows how the future looks like, but I would change that sentence slightly:
"It's architecting systems. And that's the one thing AI can't yet do."
Now just for the heck of it I’ll attempt to craft the strongest rebuttal I can:
This blog misses the key difference between AI and all other technologies in software development. AI isn’t merely good at writing code. It’s good at thinking. It’s not going to merely automate software development, it’s going to automate knowledge work. You as a human have no place in a world where your brain is strictly less capable in all realms of decisionmaking compared to machines.
I think a better comparison is to Jevons Paradox. New Technologies make developers more efficient and thus cheaper. This increases demand more than what is gained by the efficiency increases.
I don't see us anytime soon running out of things that are worth automating, especially if the cost for that continues to drop.
This time it really _is_ different, and we're looking at a world totally saturated with an abundance of bits. This will not be a simple restructuring of labor markets but something very significant and potentially quite severe.
https://www.lesswrong.com/posts/6Xgy6CAf2jqHhynHL/what-2026-...
Which makes it really obvious their aim is to get rid of (expensive) developers, not to unlock our time to enable us to work on higher things
This could explain the cycle by itself. Dynamic equations often tend to oscillate. Anything that temporarily accelerates the production of code imposes a maintenance cost later on.
This is why LLMs will not replace developers.
However, if the tooling has improved 10x, then the product complexity has gone up 100x. Nowadays, you can one-shot a Tetris game using an LLM. Back in the day this would take weeks, if not months. But now, nobody is impressed by a Tetris level game.
Writing code should almost be an afterthought to understanding the problem deeply and iteratively.
a must-have principle throughout the entire software engineering career.
>What actually happens isn't replacement, it's transformation.
"Statement --/, negation" pattern is the clearest indicator of ChatGPT I currently know.
Weak conclusion as AI already does that quite well.
Tell that to Coca-Cola.. whose most valuable asset is literally an algorithm
Can it persist in times when borrowing money is not free (nonzero interest rates)
And the disdain for marketing sites continues. I'd argue the thing that's in front of your customer's face isn't "disposable"! When the customer wants to tinker with their account, they might get there from the familiar "marketing site". Or when potential customers and users of your product are weighing up your payment plans, these are not trivial matters! Will you really trust Sloppy Jo's AI in the moment customers are reaching for their credit cards? The 'money shot' of UX. "Disposable"? "Doesn't matter"? Pffff!
I don't think "disposable" is being used here as a pejorative adjective for them. They are important, but they are built in a special way indeed.
The same day that a tutorial from Capgemini consultant on how to write code using AI appeared here, I heard from a project manager who has AI write up code that is the reviewed by the human project team--because that is far easier.
I expect most offshoring to go the way of the horse and buggy because it may be easier to explain the requirements to cursor, and the turnaround time is much faster.
I keep saying that - AI is the brick maker - you build the house. and its your decision to build that house that only needs bricks in the right place ...