13 ms·

The Myth of Developer Obsolescence

370 points by cat-whisperer 1y ago

martzoukos 1y ago
AI does a pretty good job at helping you learn architecture, though.
ahofmann 1y ago
> It's architecting systems. And that's the one thing AI can't do. 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."
- erwincoumans 1y ago
  [flagged]
nhumrich 1y ago
> code is not an asset—it's a liability 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.
- artrockalter 1y ago
  An answer to the productivity paradox (https://en.m.wikipedia.org/wiki/Productivity_paradox https://en.m.wikipedia.org/wiki/Productivity_paradox) could be that increased technology causes increased complexity of systems, offsetting efficiency gains from the technology itself.
- RankingMember 1y ago
  Reminds me a lot of the old days where people were using MS FrontPage to create websites and the html was like 90% cruft.
  - 1shooner 1y ago
    >html was like 90% cruft. Have you looked at much top-tier website code lately?
    - DaSHacka 1y ago
      I visited stallman.org just the other day, yes.
      - absurdo 1y ago
        [flagged]
    - RankingMember 1y ago
      haha, you're not lying. Frameworks on top of frameworks- it's turtles all the way down.
- westoque 1y ago
  Such a great quote. Mostly true if viewed especially from a business standpoint. I for one also see code as creative expression, a form of art. I like coding because I can express a solution in a way that is elegant and nice to read for myself and others. A bit shallow but If you've read code that is written elegantly, you'll know that immediately.
  - a_imho 1y ago
    My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...
- coliveira 1y ago
  But if code can be easily replaced, why it needs to be a liability? If something goes wrong, the next generation of "programmers" will ask the ai to generate the code again.
  - dakiol 1y ago
    Code can't easily be replaced. It's "soft"ware sure, but why do you think banks are still using Cobol? Why do you think my old company is still running a deprecated version of Zend (PHP framework)?
    - skydhash 1y ago
      Also the reason the term technical debt has been used. Every decision you enforce with the code you write is something that you may need to revert later. And the cost of doing so can be really high. So high that in the parent comment, you just don’t bother.
    - coliveira 1y ago
      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.
      - dakiol 1y ago
        > If there are new problems tomorrow, they'll generate the code again. 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?
        coliveira 1y ago
        Tomorrow the "programmer" will tell the AI what the bug was or what change needs to be made and it will generate new code considering this added requirement.
tbrownaw 1y ago
The first listed iteration is to late, what about the COmmon Business-Oriented Language? Also, something being a liability and something having upkeep costs are not the same thing.
- werrett 1y ago
  > 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.
dinfinity 1y ago
> The most valuable skill in software isn't writing code, it's architecting systems. > 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.
- ta1243 1y ago
  90% of the problem an architect has is being able to understand and thus express the requirement and limitations of a system, and understanding how it interacts with everything else. I.e writing the prompt, understanding the answers, pushing back etc.
  - theyinwhy 1y ago
    90% of the problem an architect has are people.
    - majkinetor 1y ago
      This! 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.
- mrweasel 1y ago
  That's because a large percentage of "architects" aren't really all that great. We interviewed a candidate that didn't knew much of anything, in terms of actually operating IT infrastructure, but in their mind that didn't really matter because they where looking for more of an architects role and didn't want to touch things like terminals, YAML, databases and all that stuff. They completely serious just sat there and told us that they really just wanted to work in diagram tools and maybe Excel.... Architects are like managers, it's way harder than people imagine and very few people can actually do the work.
exodust 1y ago
> "For agency work building disposable marketing sites, this doesn't matter" 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!
- whstl 1y ago
  I mean... I have been on the receiving end (as the one responsible for "installing it") of websites built by agencies and "disposable" is an ok description. Some of those websites don't really have to be maintained, so they're built without care or documentation, by a team that often has low pay and high-rotation, and then given to a customer with the expectation it will be rebuilt after a few years anyway. 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.
whstl 1y ago
> For agency work building disposable marketing sites 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.
- jvanderbot 1y ago
  There's a whole book about this called people ware. It's why I'm fond of saying "may all your problems be technical". It's just never been that hard to solve technical problems with code except for an infinitesimal percentage of bleeding edge cases.
  - whstl 1y ago
    Yep. With a good enough team, even the technical problems are almost 100% caused by people issues.
    - osigurdson 1y ago
      I've heard this many times. It isn't clear what it means however. If nearly 100% of problems are "people problems", what are some examples of "people solutions"? That may help clarify.
      - whstl 1y ago
        Keep in mind I said "with a good enough team". "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.
jstummbillig 1y ago
I think the article is mostly wrong about why it is right. > 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.
- cheschire 1y ago
  Maybe I misunderstood your phrasing, butI think with enough context an AI could determine what you want to do with reasonable accuracy. 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.
  - dakiol 1y ago
    > but I think with enough context [...] 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...
ddtaylor 1y ago
I think we should look at one even earlier: COBOL. 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!
plainOldText 1y ago
I think these are key thoughts worth considering going forward: > 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.
- squidbeak 1y ago
  The thing is, as compute prices fall and AI advances in its capability, swarms of coding agents can sweat on every line of code, looking for cleaner implementations, testing them, 24hrs a day. Current models often produce spaghetti crap. But it's a bold assumption that will always be the case. 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.
  - piva00 1y ago
    I don't think comparing Go to developing systems to be useful, Go has a very clear goal to be achieved, it can be easily iterated over to achieve that singular goal. Developing systems is a much more complex task involving a lot of human subjectivity to even define a goal, there's whole swaths of attempts in methodology, processes, tools that try to even achieve some kind of definition of a software development goal, and none so far have been good enough to automate this process. 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.
    - squidbeak 1y ago
      You'll notice if you reread my comment that what I was comparing was the notion of the human player / developer's special something.
  - chrz 1y ago
    Why its bold? Bold is being so sure in predicting the future.
the__alchemist 1y ago
The articles point about LLMs being poor at architecture aligns with my primary rule of using them in code: Don't have them design data structures or function signatures. They can fill them in when appropriate, but I will not let an LL define them. (Structs, enums, fn sigs etc)
fhd2 1y ago
I think a few revolutions are missing in the list, that weren't technical, but organisational: 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.
- collyw 1y ago
  That was one thing where Visual basic actually came closest. Design your GUI with visual tools and fill in the blanks when you clicked the button.
dakiol 1y ago
I think that until LLMs can assertively say "no" to your requests, we won't be able to rely on them autonomously. The greatest downside of ChatGPT, Copilot, and similar tools is that they always give you something in return, they always provide some sort of answer and rarely challenge your original request. That's the biggest difference I've noticed so far between working with humans and machines. Humans will usually push back, and together you can come up with something better (perhaps with less code or fewer processes, or less dependencieS). Chatbots (as of now) just throw at you one of the thousands of potential solutions to shut your mouth.
- aleph_minus_one 1y ago
  > I think that until LLMs can assertively say "no" to your requests, we won't be able to rely on them autonomously. The greatest downside of ChatGPT, Copilot, and similar tools is that they always give you something in return, they always provide some sort of answer and rarely challenge your original request. 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. :-)
  - dakiol 1y ago
    Well, yeah : )
IshKebab 1y ago
These kinds of articles are arguing against nothing. Anybody can see that AI can't really replace developers today (though it can certainly save you huge chunks of time in some situations). But what about in 5 years? 10 years? Things are changing rapidly and nobody knows what's going to happen. 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.)
- bilbo0s 1y ago
  If you're gonna give AI a decade of improvements, then I'll go ahead and bet on a whole lot of developers being replaced. Not just some developers being replaced. 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.
  - owebmaster 1y ago
    > 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. 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.
- SketchySeaBeast 1y ago
  Well, we're on year 3 of developers being out of jobs in 6 months. 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.
analog31 1y ago
>>> Here's what the "AI will replace developers" crowd fundamentally misunderstands: 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. 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.
JimDabell 1y ago
You can go back further than the article describes as well. Back in the 90s the same sorts of articles were written about how WYSIWYG editors like FrontPage, Dreamweaver, etc. were going to make web developers obsolete.
- 0x445442 1y ago
  Next hot YC startup... Training AI on UML diagrams :)
- ohadron 1y ago
  Took a while but Wix / Webflow / SquareSpace / Wordpress did end up automating a bunch of work.
  - JimDabell 1y ago
    They did, but do you think there are more or fewer web development jobs now compared with the 90s?
    - tonyedgecombe 1y ago
      There is a whole lot of brochure type web work that has disappeared, either to these site builders or Facebook. I don't know what happened to the people doing that sort of work but I would assume most weren't ready to write large React apps.
      - JimDabell 1y ago
        Why are you assuming that? How do you think all the new React jobs were filled? React developers don’t magically spring into existence with a full understanding of React out of nowhere, they grow into the job.
    - ohadron 1y ago
      The web developer / web page ratio in 2025 is for sure way lower than it was in 1998.
kookamamie 1y ago
> The most valuable skill in software isn't writing code, it's architecting systems. And the most valuable skill in defending a stance is moving goal posts.
joshuakelly 1y ago
Read this, and then compare it to Daniel Kokotajlo's "What 2026 Looks Like" published 4 years ago. 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-looks-like https://www.lesswrong.com/posts/6Xgy6CAf2jqHhynHL/what-2026-...
elzbardico 1y ago
One thing that I observed is that my company now strongly leans "build" in all the "build vs buy" decisions. And it is not a tech company. And yes, AI is not magical, I am working 10 hours a day because of that, even with the non-negligible help from AI.
- tonyedgecombe 1y ago
  >One thing that I observed is that my company now strongly leans "build" in all the "build vs buy" decisions. 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.
  - elzbardico 1y ago
    Note the qualifier: now. Because of AI my company is less inclined to buy and less risk averse to build.
gwbas1c 1y ago
> "Why hire expensive developers when anyone can build an app?" > The result wasn't fewer developers Makes me wonder if the right thing to do is to get rid of the non-developers instead?
- cromulent 1y ago
  Yes. LLMs are good at producing plausible statements and responses that radiate awareness, consideration, balance, and at least superficial knowledge of the technology in question. Even if they are non-committal, indecisive, or even inaccurate. In other words, they are very economical replacements for many non-developers.
  - ok123456 1y ago
    "Rewrite this as a 'fully-loaded' use case as defined by Cockburn: ..."
- booleandilemma 1y ago
  It's been my experience that the people running the show at these companies aren't developers themselves, but non-developers. Those people are never going to want to get rid of themselves, no matter how little they bring to the table.
catigula 1y ago
I love how I instantly know if something is written with GPT-4o now. >What actually happens isn't replacement, it's transformation. "Statement --/, negation" pattern is the clearest indicator of ChatGPT I currently know.
- bitwize 1y ago
  I think ChatGPT learned this construction because a lot of human pundits/"thought leaders" write like that. Of course whether it comes from one of these or from ChatGPT, it's of about equal value either way...
  - catigula 1y ago
    It's too trite for me, too much effort to construct for little pay-off. I feel like it was rewarded for "cleverness" in this regard but it's cleverness perceived by RLHFers.
sunegg 1y ago
The issue with these AI systems is how incredibly well they function in isolated circumstances, and how much they crash and burn when they have to be integrated into a full tech stack (even if the tech stack is also written by the same model). 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.
black_13 1y ago
[dead]
readthenotes1 1y ago
The author seems to miss the point that code being a liability has not affected the amount that is written by people who don't care. 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.
hcfman 1y ago
Man! Us people in Europe would love this double the salary scenario to apply here.
- ActionHank 1y ago
  Have you tried owning guns and not having health care?
  - mdaniel 1y ago
    I know what you're getting at, but the way you phrased it makes it sound like a more terminal outcome
neallindsay 1y ago
The picture at the top of the article seems to be a bad (AI-generated, I assume) illustration of the Gartner Hype cycle. There are supposed to be five stages, but the text at the bottom doesn't line up with the graph because it is missing the "peak of inflated expectations" while the graph seems to be missing the "plateau (of) productivity" stage.
- yellow_lead 1y ago
  And it's like 1.7MB
- aryehof 1y ago
  Whats sad is the misrepresentation will likely become over time, the new “truth”.
hermitcrab 1y ago
>The NoCode/LowCode Revolution 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-based-programming-which-is-better/ https://successfulsoftware.net/2024/01/16/visual-vs-text-bas...
- hackable_sand 1y ago
  Unreal blueprints are an example of graphical abstractions that are very successful for designer-coder workflows. I would bet on those against your assertion.
  - hermitcrab 1y ago
    Unreal blueprints is very successful in it's intended domain. But it isn't intended for general purpose programming. No-one is going to code a banking system in Unreal blueprints and it won't be replacing C++, Java or javascript.
    - hackable_sand 1y ago
      As a counterpoint you very well could whip up a UI and make a web-enabled desktop app using blueprints, but I digress.
eduction 1y ago
Kind of funny that the things that time and again save developers, especially expensive US/California based ones, are those they tend to hate - meetings, writing prose, and customer service. Writing code should almost be an afterthought to understanding the problem deeply and iteratively.
gherkinnn 1y ago
> The most valuable skill in software isn't writing code, it's architecting systems. 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.
- cheema33 1y ago
  If you look at the history of programming languages, we have been moving in the direction of "natural language" over time. We started at 1s and 0s. And then moved up to assembly language. Which I imagine was considered a higher level language back then. 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.
  - skydhash 1y ago
    We have move towards higher abstractions, not natural languages. It looks like natural language because we name those abstractions from natural languages, but their semantics can be quite different. 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.
    - js8 1y ago
nailer 1y ago
> The sysadmins weren't eliminated; they were reborn as DevOps engineers with fancy new job titles and substantially higher compensation packages. 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.
crakhamster01 1y ago
I'm increasingly certain that companies leaning too far into the AI hype are opening themselves up to disruption. 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. [1] https://www.githubstatus.com/history https://www.githubstatus.com/history
- cheema33 1y ago
  > I'm increasingly certain that companies leaning too far into the AI hype are opening themselves up to disruption. I am in the other camp. Companies ignoring AI are in for a bad time.
  - crakhamster01 1y ago
    Haha, I tried to couch this by adding "too far", but I agree. Companies should let their teams try out relevant tools in their workflows. 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.
  - DaSHacka 1y ago
    How so? Not enough art slop logos so they don't have to pay an artist? Other than in maximizing shareholder return I fail to see how foregoing AI is putting them "behind". 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.
overflow897 1y ago
I think articles like this have the big assumption under them that we are going to plateau with progress. If that assumption is true, then sure. 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.
- layer8 1y ago
  There is a high risk that the systems that AIs build, and their reasoning, will become inscrutable with time, as if built by aliens. There is a huge social aspect to software development and the tech stack and practices we have, that ensures that (despite all disagreements) we as developers are roughly on the same page as to how to go about contemporary software development (which now for example is different than, say, 20 or 40 years ago). 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.
mediumsmart 1y ago
>The most valuable skill in software isn't writing code, it's architecting systems. 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 ...
bob1029 1y ago
I strongly agree with the architecture piece. 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.
throwawayobs 1y ago
I'm old enough to remember when you wouldn't need to hire expensive developers anymore because object-oriented programming would make it possible to have semi-skilled employees assemble software from standardized parts. They even talked about the impending "software factory".
- cheema33 1y ago
  The Javascript ecosystem is quite large. And does provide a massive library of "standardized parts". To some degree that dream has been realized. A semi-skilled person can build simple applications in a very short amount of time. This was not possible in the early days. 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.
  - prmph 1y ago
    And yet no LLM can one-shot a simple markdown viewer with automatic indentation based on section levels. I tried.
vinceguidry 1y ago
This article makes a fundamental mistake where the author thinks that business values quality. Business has never valued quality. Customers can value quality, but business only values profit margins. If customers will only buy quality, then that's what business will deliver. But customers don't value quality either, most of the time. They value bang-for-buck. 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. 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.
- throw234234234 1y ago
  Depends solely on the domain IMO. There are domains where stakeholders absolutely value quality (e.g. loss of revenue, fines and other consequences). This isn't universally true.
- philosopher1234 1y ago
  Businesses can value quality in cost centers because it can bring costs down
  - vinceguidry 1y ago
    Individual managers can. The business as a whole is looking at a much bigger picture. But what managers value is throughput, not necessarily unit economics. They'll accept faster delivery at worse unit economics.
- prmph 1y ago
  I don't know where you get the impression that customer's don't value quality. They value quality, a lot. 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.
  - vinceguidry 1y ago
octo888 1y ago
At my company they're doubling down. Forcing us to use AI, and product and managers suddenly cosplaying architect and senior developer, attempting to muscle in on developers'/architects' roles. Ie trying to takeaway the thing the developers would have more time for if the AI tools achieved their aims. And to triple down, they're offshoring. 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
- cheema33 1y ago
  If things are going south as fast as you say they are, then you don't have time to complain. You need to get ahead of this AI beast. Ignore it at your own peril. It takes a while to get good at it. If you are let go from your current job, you will need strong AI skills to land your next gig.
1vuio0pswjnm7 1y ago
The Myth of Developer Relevance Can it persist in times when borrowing money is not free (nonzero interest rates)
animanoir 1y ago
[dead]
janalsncm 1y ago
I think for the most part the layoffs in software are layoffs because of uncertainty, not because of technology. They are being justified after the fact with technobabble. If there wasn’t economic uncertainty companies would gladly accept the extra productivity. 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.
- BugheadTorpeda6 1y ago
  What extra productivity? Why doesn't it show up in the economic figures?
ogogmad 1y ago
I think that as programmer productivity increases, demand for programmers also increases, but only INITIALLY. However, if productivity improves too much, and programming gets automated too much, then demand for programmers will begin to drop very rapidly. It's non-linear.
hintymad 1y ago
> The NoCode/LowCode Revolution 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.
brunoborges 1y ago
The amount of em dashes in this article is quite telling... 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-eliminate-software-developer-jobs-activity-7325913879266361346-fPl0?utm_source=share&utm_medium=member_desktop&rcm=ACoAAADoNvsBUd5N6GpFo_v2ZBJBng4w9fERfXo https://www.linkedin.com/posts/brunocborges_ai-wont-eliminat...).
- fellowniusmonk 1y ago
  It reads very much like the positive — bloviation — of AI. 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.
holtkam2 1y ago
I loved this article and it is the strongest argument I’ve ever heard for “why I shouldn’t be freaking out about the future of my engineering career”. 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.
legulere 1y ago
I don't think the higher pay is true. There are simply less people proficient in new technology at the beginning. You're simply seeing classic demand and response play out. After a while things will calm down again. 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.
moralestapia 1y ago
>It's architecting systems. And that's the one thing AI can't do. Weak conclusion as AI already does that quite well.
FrameworkFred 1y ago
I agree with some of the article. I agree that code is a liability that's distinct from the asset that the code is part of. It's like tires on a car, they're liability-like whereas the car can be thought of as an asset. 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.
bahmboo 1y ago
Funny how no one has commented on the graphic being wrong. The enlightenment and disillusionment labels are swapped.
mpweiher 1y ago
“Since FORTRAN should virtually eliminate coding and debugging…” -- FORTRAN Preliminary report, 1954 http://www.softwarepreservation.org/projects/FORTRAN/BackusEtAl-Preliminary%20Report-1954.pdf http://www.softwarepreservation.org/projects/FORTRAN/BackusE...
- ogogmad 1y ago
  You can be wrong a lot and then suddenly be right. Look up "being a Turkey": https://en.wikipedia.org/wiki/Turkey_illusion https://en.wikipedia.org/wiki/Turkey_illusion
  - mpweiher 1y ago
    I think you are missing the fact that it did, in fact, eliminate “coding”. And that’s where it starts to get interesting.
- cauliflower99 1y ago
  This is brilliant.
wayeq 1y ago
> code is not an asset—it's a liability. Tell that to Coca-Cola.. whose most valuable asset is literally an algorithm
- collyw 1y ago
  Can you expand on that?
chasing 1y ago
For vibe coding to replace software engineering vibe coding will have to become… software engineering.
protocolture 1y ago
AI is an unlimited line of credit at the bank of technical debt.
simultsop 1y ago
> 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. a must-have principle throughout the entire software engineering career.
inadequatespace 1y ago
So, what do all of these responses and the article itself seem to dance around? It's not that it makes developers obsolete, but rather increases inequality. In other words, either creates a class of inferior developers because they don't have whatever new skill, or in the case of offshoring, literally creates a class of lower developers.
msgodel 1y ago
To put it in the language of "programming as theory building" AI produced artifacts are stillborn. No one had or has the theory in their mind that corresponds to them. A software developer could read the output and develop this but then you're doing actual software development again. This is why LLMs will not replace developers.
goric 1y ago
IMO this climb doesn't really do much to prove of xenon's effectiveness (altitude researcher Dr. Peter Hackett says as much [0]). 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-is-changing-how-people-summit-everest-by-making-climbers-inhale-xenon 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-fast-everest-summits-3-or-5-days/ https://www.alanarnette.com/blog/2025/05/21/everest-2025-fas...

370 points by cat-whisperer 1y ago

AI does a pretty good job at helping you learn architecture, though.

> It's architecting systems. And that's the one thing AI can't do. 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."

erwincoumans 1y ago
[flagged]

nhumrich 1y ago

> code is not an asset—it's a liability 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.

artrockalter 1y ago
An answer to the productivity paradox (https://en.m.wikipedia.org/wiki/Productivity_paradox https://en.m.wikipedia.org/wiki/Productivity_paradox) could be that increased technology causes increased complexity of systems, offsetting efficiency gains from the technology itself.
RankingMember 1y ago
Reminds me a lot of the old days where people were using MS FrontPage to create websites and the html was like 90% cruft.
- 1shooner 1y ago
  >html was like 90% cruft. Have you looked at much top-tier website code lately?
  - DaSHacka 1y ago
    I visited stallman.org just the other day, yes.
    - absurdo 1y ago
      [flagged]
  - RankingMember 1y ago
    haha, you're not lying. Frameworks on top of frameworks- it's turtles all the way down.
westoque 1y ago
Such a great quote. Mostly true if viewed especially from a business standpoint. I for one also see code as creative expression, a form of art. I like coding because I can express a solution in a way that is elegant and nice to read for myself and others. A bit shallow but If you've read code that is written elegantly, you'll know that immediately.
- a_imho 1y ago
  My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...
coliveira 1y ago
But if code can be easily replaced, why it needs to be a liability? If something goes wrong, the next generation of "programmers" will ask the ai to generate the code again.
- dakiol 1y ago
  Code can't easily be replaced. It's "soft"ware sure, but why do you think banks are still using Cobol? Why do you think my old company is still running a deprecated version of Zend (PHP framework)?
  - skydhash 1y ago
    Also the reason the term technical debt has been used. Every decision you enforce with the code you write is something that you may need to revert later. And the cost of doing so can be really high. So high that in the parent comment, you just don’t bother.
  - coliveira 1y ago
    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.
    - dakiol 1y ago
      > If there are new problems tomorrow, they'll generate the code again. 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?
      - coliveira 1y ago
        Tomorrow the "programmer" will tell the AI what the bug was or what change needs to be made and it will generate new code considering this added requirement.

tbrownaw 1y ago

The first listed iteration is to late, what about the COmmon Business-Oriented Language? Also, something being a liability and something having upkeep costs are not the same thing.

werrett 1y ago
> 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.

dinfinity 1y ago

> The most valuable skill in software isn't writing code, it's architecting systems. > 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.

ta1243 1y ago
90% of the problem an architect has is being able to understand and thus express the requirement and limitations of a system, and understanding how it interacts with everything else. I.e writing the prompt, understanding the answers, pushing back etc.
- theyinwhy 1y ago
  90% of the problem an architect has are people.
  - majkinetor 1y ago
    This! 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.
mrweasel 1y ago
That's because a large percentage of "architects" aren't really all that great. We interviewed a candidate that didn't knew much of anything, in terms of actually operating IT infrastructure, but in their mind that didn't really matter because they where looking for more of an architects role and didn't want to touch things like terminals, YAML, databases and all that stuff. They completely serious just sat there and told us that they really just wanted to work in diagram tools and maybe Excel.... Architects are like managers, it's way harder than people imagine and very few people can actually do the work.

exodust 1y ago

> "For agency work building disposable marketing sites, this doesn't matter" 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!

whstl 1y ago
I mean... I have been on the receiving end (as the one responsible for "installing it") of websites built by agencies and "disposable" is an ok description. Some of those websites don't really have to be maintained, so they're built without care or documentation, by a team that often has low pay and high-rotation, and then given to a customer with the expectation it will be rebuilt after a few years anyway. 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.

whstl 1y ago

> For agency work building disposable marketing sites 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.

jvanderbot 1y ago
There's a whole book about this called people ware. It's why I'm fond of saying "may all your problems be technical". It's just never been that hard to solve technical problems with code except for an infinitesimal percentage of bleeding edge cases.
- whstl 1y ago
  Yep. With a good enough team, even the technical problems are almost 100% caused by people issues.
  - osigurdson 1y ago
    I've heard this many times. It isn't clear what it means however. If nearly 100% of problems are "people problems", what are some examples of "people solutions"? That may help clarify.
    - whstl 1y ago
      Keep in mind I said "with a good enough team". "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.

jstummbillig 1y ago

I think the article is mostly wrong about why it is right. > 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.

cheschire 1y ago
Maybe I misunderstood your phrasing, butI think with enough context an AI could determine what you want to do with reasonable accuracy. 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.
- dakiol 1y ago
  > but I think with enough context [...] 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...

ddtaylor 1y ago

I think we should look at one even earlier: COBOL. 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!

plainOldText 1y ago

I think these are key thoughts worth considering going forward: > 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.

squidbeak 1y ago
The thing is, as compute prices fall and AI advances in its capability, swarms of coding agents can sweat on every line of code, looking for cleaner implementations, testing them, 24hrs a day. Current models often produce spaghetti crap. But it's a bold assumption that will always be the case. 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.
- piva00 1y ago
  I don't think comparing Go to developing systems to be useful, Go has a very clear goal to be achieved, it can be easily iterated over to achieve that singular goal. Developing systems is a much more complex task involving a lot of human subjectivity to even define a goal, there's whole swaths of attempts in methodology, processes, tools that try to even achieve some kind of definition of a software development goal, and none so far have been good enough to automate this process. 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.
  - squidbeak 1y ago
    You'll notice if you reread my comment that what I was comparing was the notion of the human player / developer's special something.
- chrz 1y ago
  Why its bold? Bold is being so sure in predicting the future.

the__alchemist 1y ago

The articles point about LLMs being poor at architecture aligns with my primary rule of using them in code: Don't have them design data structures or function signatures. They can fill them in when appropriate, but I will not let an LL define them. (Structs, enums, fn sigs etc)

fhd2 1y ago

I think a few revolutions are missing in the list, that weren't technical, but organisational: 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.

collyw 1y ago
That was one thing where Visual basic actually came closest. Design your GUI with visual tools and fill in the blanks when you clicked the button.

dakiol 1y ago

I think that until LLMs can assertively say "no" to your requests, we won't be able to rely on them autonomously. The greatest downside of ChatGPT, Copilot, and similar tools is that they always give you something in return, they always provide some sort of answer and rarely challenge your original request. That's the biggest difference I've noticed so far between working with humans and machines. Humans will usually push back, and together you can come up with something better (perhaps with less code or fewer processes, or less dependencieS). Chatbots (as of now) just throw at you one of the thousands of potential solutions to shut your mouth.

aleph_minus_one 1y ago
> I think that until LLMs can assertively say "no" to your requests, we won't be able to rely on them autonomously. The greatest downside of ChatGPT, Copilot, and similar tools is that they always give you something in return, they always provide some sort of answer and rarely challenge your original request. 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. :-)
- dakiol 1y ago
  Well, yeah : )

IshKebab 1y ago

These kinds of articles are arguing against nothing. Anybody can see that AI can't really replace developers today (though it can certainly save you huge chunks of time in some situations). But what about in 5 years? 10 years? Things are changing rapidly and nobody knows what's going to happen. 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.)

bilbo0s 1y ago
If you're gonna give AI a decade of improvements, then I'll go ahead and bet on a whole lot of developers being replaced. Not just some developers being replaced. 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.
- owebmaster 1y ago
  > 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. 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.
SketchySeaBeast 1y ago
Well, we're on year 3 of developers being out of jobs in 6 months. 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.

analog31 1y ago

>>> Here's what the "AI will replace developers" crowd fundamentally misunderstands: 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. 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.

JimDabell 1y ago

You can go back further than the article describes as well. Back in the 90s the same sorts of articles were written about how WYSIWYG editors like FrontPage, Dreamweaver, etc. were going to make web developers obsolete.

0x445442 1y ago
Next hot YC startup... Training AI on UML diagrams :)
ohadron 1y ago
Took a while but Wix / Webflow / SquareSpace / Wordpress did end up automating a bunch of work.
- JimDabell 1y ago
  They did, but do you think there are more or fewer web development jobs now compared with the 90s?
  - tonyedgecombe 1y ago
    There is a whole lot of brochure type web work that has disappeared, either to these site builders or Facebook. I don't know what happened to the people doing that sort of work but I would assume most weren't ready to write large React apps.
    - JimDabell 1y ago
      Why are you assuming that? How do you think all the new React jobs were filled? React developers don’t magically spring into existence with a full understanding of React out of nowhere, they grow into the job.
  - ohadron 1y ago
    The web developer / web page ratio in 2025 is for sure way lower than it was in 1998.

kookamamie 1y ago

> The most valuable skill in software isn't writing code, it's architecting systems. And the most valuable skill in defending a stance is moving goal posts.

joshuakelly 1y ago

Read this, and then compare it to Daniel Kokotajlo's "What 2026 Looks Like" published 4 years ago. 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-looks-like https://www.lesswrong.com/posts/6Xgy6CAf2jqHhynHL/what-2026-...

elzbardico 1y ago

One thing that I observed is that my company now strongly leans "build" in all the "build vs buy" decisions. And it is not a tech company. And yes, AI is not magical, I am working 10 hours a day because of that, even with the non-negligible help from AI.

tonyedgecombe 1y ago
>One thing that I observed is that my company now strongly leans "build" in all the "build vs buy" decisions. 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.
- elzbardico 1y ago
  Note the qualifier: now. Because of AI my company is less inclined to buy and less risk averse to build.

gwbas1c 1y ago

> "Why hire expensive developers when anyone can build an app?" > The result wasn't fewer developers Makes me wonder if the right thing to do is to get rid of the non-developers instead?

cromulent 1y ago
Yes. LLMs are good at producing plausible statements and responses that radiate awareness, consideration, balance, and at least superficial knowledge of the technology in question. Even if they are non-committal, indecisive, or even inaccurate. In other words, they are very economical replacements for many non-developers.
- ok123456 1y ago
  "Rewrite this as a 'fully-loaded' use case as defined by Cockburn: ..."
booleandilemma 1y ago
It's been my experience that the people running the show at these companies aren't developers themselves, but non-developers. Those people are never going to want to get rid of themselves, no matter how little they bring to the table.

catigula 1y ago

I love how I instantly know if something is written with GPT-4o now. >What actually happens isn't replacement, it's transformation. "Statement --/, negation" pattern is the clearest indicator of ChatGPT I currently know.

bitwize 1y ago
I think ChatGPT learned this construction because a lot of human pundits/"thought leaders" write like that. Of course whether it comes from one of these or from ChatGPT, it's of about equal value either way...
- catigula 1y ago
  It's too trite for me, too much effort to construct for little pay-off. I feel like it was rewarded for "cleverness" in this regard but it's cleverness perceived by RLHFers.

sunegg 1y ago

The issue with these AI systems is how incredibly well they function in isolated circumstances, and how much they crash and burn when they have to be integrated into a full tech stack (even if the tech stack is also written by the same model). 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.

black_13 1y ago

[dead]

readthenotes1 1y ago

The author seems to miss the point that code being a liability has not affected the amount that is written by people who don't care. 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.

hcfman 1y ago

Man! Us people in Europe would love this double the salary scenario to apply here.

ActionHank 1y ago
Have you tried owning guns and not having health care?
- mdaniel 1y ago
  I know what you're getting at, but the way you phrased it makes it sound like a more terminal outcome

neallindsay 1y ago

The picture at the top of the article seems to be a bad (AI-generated, I assume) illustration of the Gartner Hype cycle. There are supposed to be five stages, but the text at the bottom doesn't line up with the graph because it is missing the "peak of inflated expectations" while the graph seems to be missing the "plateau (of) productivity" stage.

yellow_lead 1y ago
And it's like 1.7MB
aryehof 1y ago
Whats sad is the misrepresentation will likely become over time, the new “truth”.

hermitcrab 1y ago

>The NoCode/LowCode Revolution 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-based-programming-which-is-better/ https://successfulsoftware.net/2024/01/16/visual-vs-text-bas...

hackable_sand 1y ago
Unreal blueprints are an example of graphical abstractions that are very successful for designer-coder workflows. I would bet on those against your assertion.
- hermitcrab 1y ago
  Unreal blueprints is very successful in it's intended domain. But it isn't intended for general purpose programming. No-one is going to code a banking system in Unreal blueprints and it won't be replacing C++, Java or javascript.
  - hackable_sand 1y ago
    As a counterpoint you very well could whip up a UI and make a web-enabled desktop app using blueprints, but I digress.

eduction 1y ago

Kind of funny that the things that time and again save developers, especially expensive US/California based ones, are those they tend to hate - meetings, writing prose, and customer service. Writing code should almost be an afterthought to understanding the problem deeply and iteratively.

gherkinnn 1y ago

> The most valuable skill in software isn't writing code, it's architecting systems. 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.

cheema33 1y ago
If you look at the history of programming languages, we have been moving in the direction of "natural language" over time. We started at 1s and 0s. And then moved up to assembly language. Which I imagine was considered a higher level language back then. 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.
- skydhash 1y ago
  We have move towards higher abstractions, not natural languages. It looks like natural language because we name those abstractions from natural languages, but their semantics can be quite different. 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.
  - js8 1y ago

nailer 1y ago

> The sysadmins weren't eliminated; they were reborn as DevOps engineers with fancy new job titles and substantially higher compensation packages. 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.

crakhamster01 1y ago

I'm increasingly certain that companies leaning too far into the AI hype are opening themselves up to disruption. 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. [1] https://www.githubstatus.com/history https://www.githubstatus.com/history

cheema33 1y ago
> I'm increasingly certain that companies leaning too far into the AI hype are opening themselves up to disruption. I am in the other camp. Companies ignoring AI are in for a bad time.
- crakhamster01 1y ago
  Haha, I tried to couch this by adding "too far", but I agree. Companies should let their teams try out relevant tools in their workflows. 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.
- DaSHacka 1y ago
  How so? Not enough art slop logos so they don't have to pay an artist? Other than in maximizing shareholder return I fail to see how foregoing AI is putting them "behind". 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.

overflow897 1y ago

I think articles like this have the big assumption under them that we are going to plateau with progress. If that assumption is true, then sure. 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.

layer8 1y ago
There is a high risk that the systems that AIs build, and their reasoning, will become inscrutable with time, as if built by aliens. There is a huge social aspect to software development and the tech stack and practices we have, that ensures that (despite all disagreements) we as developers are roughly on the same page as to how to go about contemporary software development (which now for example is different than, say, 20 or 40 years ago). 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.

mediumsmart 1y ago

>The most valuable skill in software isn't writing code, it's architecting systems. 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 ...

bob1029 1y ago

I strongly agree with the architecture piece. 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.

throwawayobs 1y ago

I'm old enough to remember when you wouldn't need to hire expensive developers anymore because object-oriented programming would make it possible to have semi-skilled employees assemble software from standardized parts. They even talked about the impending "software factory".

cheema33 1y ago
The Javascript ecosystem is quite large. And does provide a massive library of "standardized parts". To some degree that dream has been realized. A semi-skilled person can build simple applications in a very short amount of time. This was not possible in the early days. 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.
- prmph 1y ago
  And yet no LLM can one-shot a simple markdown viewer with automatic indentation based on section levels. I tried.

vinceguidry 1y ago

This article makes a fundamental mistake where the author thinks that business values quality. Business has never valued quality. Customers can value quality, but business only values profit margins. If customers will only buy quality, then that's what business will deliver. But customers don't value quality either, most of the time. They value bang-for-buck. 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. 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.

throw234234234 1y ago
Depends solely on the domain IMO. There are domains where stakeholders absolutely value quality (e.g. loss of revenue, fines and other consequences). This isn't universally true.
philosopher1234 1y ago
Businesses can value quality in cost centers because it can bring costs down
- vinceguidry 1y ago
  Individual managers can. The business as a whole is looking at a much bigger picture. But what managers value is throughput, not necessarily unit economics. They'll accept faster delivery at worse unit economics.
prmph 1y ago
I don't know where you get the impression that customer's don't value quality. They value quality, a lot. 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.
- vinceguidry 1y ago

octo888 1y ago

At my company they're doubling down. Forcing us to use AI, and product and managers suddenly cosplaying architect and senior developer, attempting to muscle in on developers'/architects' roles. Ie trying to takeaway the thing the developers would have more time for if the AI tools achieved their aims. And to triple down, they're offshoring. 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

cheema33 1y ago
If things are going south as fast as you say they are, then you don't have time to complain. You need to get ahead of this AI beast. Ignore it at your own peril. It takes a while to get good at it. If you are let go from your current job, you will need strong AI skills to land your next gig.

1vuio0pswjnm7 1y ago

The Myth of Developer Relevance Can it persist in times when borrowing money is not free (nonzero interest rates)

animanoir 1y ago

[dead]

janalsncm 1y ago

I think for the most part the layoffs in software are layoffs because of uncertainty, not because of technology. They are being justified after the fact with technobabble. If there wasn’t economic uncertainty companies would gladly accept the extra productivity. 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.

BugheadTorpeda6 1y ago
What extra productivity? Why doesn't it show up in the economic figures?

ogogmad 1y ago

I think that as programmer productivity increases, demand for programmers also increases, but only INITIALLY. However, if productivity improves too much, and programming gets automated too much, then demand for programmers will begin to drop very rapidly. It's non-linear.

hintymad 1y ago

> The NoCode/LowCode Revolution 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.

brunoborges 1y ago

The amount of em dashes in this article is quite telling... 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-eliminate-software-developer-jobs-activity-7325913879266361346-fPl0?utm_source=share&utm_medium=member_desktop&rcm=ACoAAADoNvsBUd5N6GpFo_v2ZBJBng4w9fERfXo https://www.linkedin.com/posts/brunocborges_ai-wont-eliminat...).

fellowniusmonk 1y ago
It reads very much like the positive — bloviation — of AI. 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.

holtkam2 1y ago

I loved this article and it is the strongest argument I’ve ever heard for “why I shouldn’t be freaking out about the future of my engineering career”. 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.

legulere 1y ago

I don't think the higher pay is true. There are simply less people proficient in new technology at the beginning. You're simply seeing classic demand and response play out. After a while things will calm down again. 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.

moralestapia 1y ago

>It's architecting systems. And that's the one thing AI can't do. Weak conclusion as AI already does that quite well.

FrameworkFred 1y ago

I agree with some of the article. I agree that code is a liability that's distinct from the asset that the code is part of. It's like tires on a car, they're liability-like whereas the car can be thought of as an asset. 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.

bahmboo 1y ago

Funny how no one has commented on the graphic being wrong. The enlightenment and disillusionment labels are swapped.

mpweiher 1y ago

“Since FORTRAN should virtually eliminate coding and debugging…” -- FORTRAN Preliminary report, 1954 http://www.softwarepreservation.org/projects/FORTRAN/BackusEtAl-Preliminary%20Report-1954.pdf http://www.softwarepreservation.org/projects/FORTRAN/BackusE...

ogogmad 1y ago
You can be wrong a lot and then suddenly be right. Look up "being a Turkey": https://en.wikipedia.org/wiki/Turkey_illusion https://en.wikipedia.org/wiki/Turkey_illusion
- mpweiher 1y ago
  I think you are missing the fact that it did, in fact, eliminate “coding”. And that’s where it starts to get interesting.
cauliflower99 1y ago
This is brilliant.

wayeq 1y ago

> code is not an asset—it's a liability. Tell that to Coca-Cola.. whose most valuable asset is literally an algorithm

collyw 1y ago
Can you expand on that?

chasing 1y ago

For vibe coding to replace software engineering vibe coding will have to become… software engineering.

protocolture 1y ago

AI is an unlimited line of credit at the bank of technical debt.

simultsop 1y ago

> 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. a must-have principle throughout the entire software engineering career.

inadequatespace 1y ago

So, what do all of these responses and the article itself seem to dance around? It's not that it makes developers obsolete, but rather increases inequality. In other words, either creates a class of inferior developers because they don't have whatever new skill, or in the case of offshoring, literally creates a class of lower developers.

msgodel 1y ago

To put it in the language of "programming as theory building" AI produced artifacts are stillborn. No one had or has the theory in their mind that corresponds to them. A software developer could read the output and develop this but then you're doing actual software development again. This is why LLMs will not replace developers.

goric 1y ago

IMO this climb doesn't really do much to prove of xenon's effectiveness (altitude researcher Dr. Peter Hackett says as much [0]). 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-is-changing-how-people-summit-everest-by-making-climbers-inhale-xenon 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-fast-everest-summits-3-or-5-days/ https://www.alanarnette.com/blog/2025/05/21/everest-2025-fas...