[HN Gopher] The recurring dream of replacing developers
___________________________________________________________________
The recurring dream of replacing developers
Author : glimshe
Score : 216 points
Date : 2026-01-17 14:31 UTC (8 hours ago)
(HTM) web link (www.caimito.net)
(TXT) w3m dump (www.caimito.net)
| jalapenos wrote:
| The dumb part of this is: so who prompts the AI?
|
| Well probably we'd want a person who really gets the AI, as
| they'll have a talent for prompting it well.
|
| Meaning: knows how to talk to computers better than other people.
|
| So a programmer then...
|
| I think it's not that people are stupid. I think there's actually
| a glee behind the claims AI will put devs out of work - like they
| feel good about the idea of hurting them, rather than being
| driven by dispassionate logic.
|
| Maybe it's the ancient jocks vs nerds thing.
| peacebeard wrote:
| Devs are where projects meet the constraints of reality and
| people always want to kill the messenger.
| booleandilemma wrote:
| Devs are where the project meets reality in general, and this
| is what I always try to explain to people. And it's the same
| with construction, by the way. Pictures and blueprints are
| nice but sooner or later you're going to need someone digging
| around in the dirt.
| nasmorn wrote:
| No high paid manager wants to learn that their visionary
| thinking was just the last iteration of the underpants gnome
| meme. Some things sound good at first but unfortunately are
| not that easy to actually do
| spwa4 wrote:
| Even that is the wrong question. The whole promise of the stock
| market, of AI is that you can "run companies" by just owning
| shares and knowing nothing at all. I think that is what
| "leaders" hope to achieve. It's a slightly more dressed get-
| rich-quick scheme.
|
| Invest $1000 into AI, have a $1000000 company in a month.
| That's the dream they're selling, at least until they have
| enough investment.
|
| It of course becomes "oh, sorry, we happen to have taken the
| only huge business for ourselves. Is your kidney now for sale?"
| rvz wrote:
| > Invest $1000 into AI, have a $1000000 company in a month.
| That's the dream they're selling, at least until they have
| enough investment.
|
| But you need to buy my AI engineer course for that first.
| dboreham wrote:
| > who prompts the AI
|
| LLMs are a box where the input has to be generated by
| someone/something, but also the output has to be verified
| somehow (because, like humans, it isn't always correct). So you
| either need a human at "both ends", or some very clever AI
| filling those roles.
|
| But I think the human doing those things probably needs
| slightly different skills and experience than the average
| legacy developer.
| reactordev wrote:
| Rules engines were designed for just such a thing. Validating
| input/output. You don't need a human to prompt AI, you need a
| pipeline.
|
| While a single LLM won't replace you. A well designed system
| of flows for software engineering using LLMs will.
| Alex_L_Wood wrote:
| Well, who designs the system of flows?
| lkjdsklf wrote:
| If you ask the AI labs, the AI systems themselves will
| build these kinds of workflows for themselves.
|
| That's the goal.
| reactordev wrote:
| Business Analysts
|
| (or rather, Business People)
| benoau wrote:
| Some people just see it as a cost, one "tech" startup I worked
| at I got this lengthy pitch from a sales exec that they
| shouldn't have a software team at all, that we'd never be able
| to build anything useful without spending millions and that
| money would be better-spent on the sales team, although they'd
| have nothing to sell lmfao. And the real laugh was the dev team
| was heavily subsidized by R&D grants anyway.
| plagiarist wrote:
| They don't need to put all developers out of work to have a
| financial impact on the career.
| duskdozer wrote:
| How about another AI? And who prompts _that_ AI? You 're right
| - another AI!
| lkjdsklf wrote:
| With all these AIs chaining and prompting eachother, we're
| approaching the point where some unlucky person is going to
| ask an AI something and it will consume all the energy in the
| universe trying to compute the answer.
| in_a_society wrote:
| Only to get in response: "INSUFFICIENT DATA FOR MEANINGFUL
| ANSWER"
| lstodd wrote:
| The answer would be 42.
| kankerlijer wrote:
| Outside of SV the thought of More Tech being the answer to ever
| greater things is met with great skepticism these days. It's
| not that people hate engineers, and most people are content to
| hold their nose while the mag7 make 401k go up, but people are
| sick of Big Tech. Like it or not, the Musks, Karps, Thiels,
| Bezos's have a lot to do with that.
| cyanydeez wrote:
| Popularity gets you nowhere though. What matters is money and
| money. Those 401k holders are tied down to the oligarchy.
| psychoslave wrote:
| Not imputing that to you, but it seems like they are people
| out there that believe money is all that matters. The map
| with the richest details won't save anyone in a territory
| that was turned into a wasteland unable to produce a single
| apple on the whole land.
| cyanydeez wrote:
| Yes, but thats because Capitalism is mostly built of the
| idea of fungibility. So yeah, Americans have told
| themselves for over a century, whatever they need, just
| substitute money and you can get it eventually. All other
| things aside, that's a pretty toxic way if not downright
| psychotic, way to reframe your relationship with society
| and other people.
| rvz wrote:
| Who fixes the unmaintainable mess that the AI created in which
| the vibe coder prompted?
|
| The Vibe Coder? The AI?
|
| Take a guess who fixes it.
| tosapple wrote:
| For now, training these things on code and logic is the first
| step of building a technological singularity.
| lkjdsklf wrote:
| The real question is, do you even need to fix it? Does it
| matter?
|
| The reason those things matter in a traditional project is
| because a person needs to be able to read and understand the
| code.
|
| If you're vibe coding, that's no longer true. So maybe it
| doesn't matter. Maybe the things we used to consider
| maintenance headaches are irrelevant.
| otabdeveloper4 wrote:
| The reason those things matter in a traditional project is
| because the previous developers fucked up, and the product
| is now crashing and leaking money and clients like a
| sinking Titanic.
| heliumtera wrote:
| The day you successfully implemented your solution with a
| prompt, you solution is valued at the cost of a prompt. There
| is no value to anything easily achieved by generative tools
| anymore. Now it is in either:
|
| a. generative technology but requiring substantial amount of
| coordination, curation, compute power. b. substantial amount of
| data. c. scarce intelectual human work.
|
| And scarce but non intellectually demanding human work was
| dropped from the list of valuable things.
| krater23 wrote:
| The link doesn't works for me, just get thrown on the main page
| after a second.
| DeadlineDE wrote:
| Looks like the article was pulled down? I could not find it in
| the english archive either.
| furyofantares wrote:
| The article itself is AI slop anyway, I guess we're ignoring it
| because we all want to discuss this or something. Very
| frustrating.
| walterbell wrote:
| _> Understanding this doesn't mean rejecting new tools. It means
| using them with clear expectations about what they can provide
| and what will always require human judgment._
|
| Speaking of tools, that style of writing rings a bell.. Ben
| Affleck made a similar point about the evolving use of computers
| and AI in filmmaking, wielded with creativity by humans with
| lived experiences, https://www.youtube.com/watch?v=O-2OsvVJC0s.
| Faster visual effects production enables more creative options.
| erichocean wrote:
| Spreadsheets replaced developers for that kind of work, while
| simultaneously enabling multiple magnitudes more work of that
| type to be performed.
| ozim wrote:
| I do agree, that's like my go to thought.
|
| Citizen developers were already there doing Excel. I have seen
| basically full fledged applications in Excel since I was in
| high school which was 25 years ago already.
| tacostakohashi wrote:
| If anything, there were a bunch of low barrier to entry
| software development options like HyperCard, MS Access,
| Visual Basic, Delphi, 4GLs etc. around in the 90s, that went
| away.
|
| It feels like programming then got a lot harder with internet
| stuff that brought client-server challenges, web frontends,
| cross platform UI and build challenges, mobile apps, tablets,
| etc... all bringing in elaborate frameworks and build systems
| and dependency hell to manage and move complexity around.
|
| With that context, it seems like the AI experience /
| productivity boost people are having is almost like a
| regression back to the mean and just cutting through some of
| the layers of complexity that had built up over the years.
| 65 wrote:
| And I would argue speadsheets still created more developers.
| Analytics teams need developers to put that data somewhere, to
| transform it for certain formats, to load that data from a
| source so they can create spreadsheets from it.
|
| So now instead of one developer lost and one analyst created,
| you've actually just created an analyst and kept a developer.
| klodolph wrote:
| Kind of off topic but this has got to be one of my least favorite
| CSS rules that I've seen in recent memory: .blog-
| entry p:first-letter { font-size: 1.2em; }
| backwardsponcho wrote:
| I love me a good drop cap, but you're right in that this
| example is not good.
| CodingJeebus wrote:
| > Which brings us to the question: why does this pattern repeat?
|
| The pattern repeats because the market incentivizes it. AI has
| been pushed as an omnipotent, all-powerful job-killer by these
| companies because shareholder value depends on enough people
| believing in it, not whether the tooling is actually capable.
| It's telling that folks like Jensen Huang talk about people's
| negativity towards AI being one of the biggest barriers to
| advancement, as if they should be immune from scrutiny.
|
| They'd rather try to discredit the naysayers than actually work
| towards making these products function the way they're being
| marketed, and once the market wakes up to this reality, it's
| gonna get really ugly.
| psychoslave wrote:
| >The pattern repeats because the market incentivizes it.
|
| Market is not universal gravity, it's just a storefront for
| social policy.
|
| No political order, no market, no market incentives.
| lotu wrote:
| Yes very much so, if they could make their product do the
| things they claim they would be focused on doing that, not
| telling people to stop being naysayers.
| cyanydeez wrote:
| Mythical Man Month -> Mythical AI Agent Swarm
| PeterStuer wrote:
| The reverse is developer's recurring dream of replacing non-IT
| people, usually with a 100% online automated self promoting SaaS.
| AI is also the latest incarnation of that.
| mjevans wrote:
| When do we get the Star Trek / Orville dream of every job is a
| good job?
| xnx wrote:
| Don't take it personal. All business want to reduce costs. As
| long as people cost money, they'll want to reduce people.
| bill_joy_fanboy wrote:
| Which is why quiet quitting is the logical thing.
|
| Managers and business owners shouldn't take it personally that
| I do as little as possible and minimize the amount of labor I
| provide for the money I receive.
|
| Hey, it's just business.
| safety1st wrote:
| What a nihilistic perspective and empty life.
|
| If the deck is stacked against labor and in favor of the
| owner, become the owner. Start a business. Create things that
| are better. Enrich the world. Put food on the table for a few
| people in the process.
|
| Be something instead of intentionally being nothing. Win.
| Giefo6ah wrote:
| Let's say the average firm has 10 workers. 90% of people
| are nihilists and empty lifers?
|
| Do I want to lead a business filled with losers?
| bill_joy_fanboy wrote:
| > What a nihilistic perspective and empty life.
|
| Equally nihilistic are owners, managers, and leaders who
| think they will replace developers with LLMs.
|
| Why care about, support, defend, or help such people? Why
| would I do that?
| falloutx wrote:
| Every founder and owner is basically a money chaser and
| bill_joy_fanboy is the true businessman. You will not get
| it.
| tbrownaw wrote:
| And you do this honestly, by negotiating reduced hours for
| the same pay or by negotiating piecework rather than time-
| based pay. Right?
| nullorempty wrote:
| What does the term mean? I think the answer to your
| question is obvious.
| bill_joy_fanboy wrote:
| Like any shrewd businessman, I negotiate to receive the
| highest price possible for the minimum cost on my end. This
| is how business is done.
| throwjjj wrote:
| Which is why I fire the quiet quitters on the spot
| CodingJeebus wrote:
| > Don't take it personal. All business want to reduce costs. As
| long as people cost money, they'll want to reduce people.
|
| "Don't take it personal" does not feed the starving and does
| not house the unhoused. An economic system that over-indexes on
| profit at the expense of the vast majority of its people will
| eventually fail. If capitalism can't evolve to better provide
| opportunities for people to live while the capital-owning class
| continues to capture a disproportionate share of created
| economic value, the system will eventually break.
| bdcravens wrote:
| While not an incorrect statement, trillions of dollars have
| been paid to software developers to build software that
| invariably reduced labor costs.
| CodingJeebus wrote:
| You're absolutely correct on that. The technology industry,
| at least the segment driven by VC (which is a huge portion
| of it), is funded based on ideas that the capital-owning
| class thinks is a good idea. Reducing labor costs is always
| an easy sell when you're trying to raise a round.
| bdcravens wrote:
| Even in boring development jobs. For example, one of my
| first development jobs was for a large hospital, building
| an intranet app to make nurse rounds more efficient so
| they didn't have to hire as many.
| bdcravens wrote:
| The irony being that software, and developers, have often been
| the tool for reducing head count.
| psychoslave wrote:
| Some businesses want to reduce costs. Some want to tackle the
| challenge of using resources available in the most profitable
| manner, including making their employees grow to better
| contribute in tackling tomorrow's challenges.
|
| A business leader board that only consider people as costs are
| looking at the world through sociopath lenses.
| cannonpalms wrote:
| This is just a layer of emotion on top of raw capitalism. And
| it will always prove to be a lie when push comes to shove.
| MontyCarloHall wrote:
| It's not so much about replacing developers, but rather
| increasing the level of abstraction developers can work at, to
| allow them to work on more complex problems.
|
| The first electronic computers were programmed by manually re-
| wiring their circuits. Going from that to being able to encode
| machine instructions on punchcards did not replace developers.
| Nor did going from raw machine instructions to assembly code. Nor
| did going from hand-written assembly to compiled low-level
| languages like C/FORTRAN. Nor did going from low-level languages
| to higher-level languages like Java, C++, or Python. Nor did
| relying on libraries/frameworks for implementing functionality
| that previously had to be written from scratch each time. Each of
| these steps freed developers from having to worry about lower-
| level problems and instead focus on higher-level problems. Mel's
| intellect is freed from having to optimize the position of the
| memory drum [0] to allow him to focus on optimizing the higher-
| level logic/algorithms of the problem he's solving. As a result,
| software has become both more complex but also much more capable,
| and thus much more common.
|
| (The thing that distinguishes gen-AI from all the previous
| examples of increasing abstraction is that those examples are
| deterministic and often formally verifiable mappings from higher
| abstraction -> lower abstraction. Gen-AI is neither.)
|
| [0] http://catb.org/jargon/html/story-of-mel.html
| SkiFire13 wrote:
| > It's not so much about replacing developers, but rather
| increasing the level of abstraction developers can work at, to
| allow them to work on more complex problems.
|
| People do and will talk about replacing developers though.
| MontyCarloHall wrote:
| Were many of the aforementioned advancements marketed as
| "replacing developers"? Absolutely. Did that end up
| happening? Quite the opposite; each higher-level abstraction
| only caused the market for software and demand for developers
| to grow.
|
| That's not to say developers haven't been _displaced_ by
| abstraction; I suspect many of the people responsible for re-
| wiring the ENIAC were completely out of a job when punchcards
| hit the scene. But their absence was filled by a greater
| number of higher-level punchcard-wielding developers.
| Palomides wrote:
| the infinite-fountain-of-software machine seems more likely
| to replace developers than previous innovations, and the
| people pushing the button will not be, in any current sense
| of the word, programming
| fn-mote wrote:
| You absolutely need to be trying to accomplish these
| things personally to understand what is/will be easy and
| where the barriers.
|
| Recognizing the barriers & modes of failure (which will
| be a moving target) lets you respond competently when you
| are called. Raise your hourly rate as needed.
| AndrewKemendo wrote:
| I think the thing that's so weird to me is this idea that we
| have to all somehow internalize the concept of transistor
| switching as the foundational unchangeable root of computing
| and therefore anything that is too far abstract from that is
| not somehow real computing or something mess like that
|
| Again ignoring completely that when you would program vacuum
| tube computers it was an entirely different type of abstraction
| than you do with Mosfets for example
|
| I'm finding myself in the position where I can safely ignore
| any conversation about engineering with anybody who thinks that
| there is a "right" way to do it or that there's any kind of
| ceremony or thinking pattern that needs to stay stable
|
| Those are all artifacts of humans desiring very little variance
| and things that they've even encoded because it takes real
| energy to have to reconfigure your own internal state model to
| a new paradigm
| ori_b wrote:
| The goal of AI companies is to replace all intellectual labor.
| You can argue that they're going to fail, but it's very clear
| what the actual goal is.
| billy99k wrote:
| One of my clients is an AI startup in the security industry.
| Their business model is to use AI agents to perform the
| initial assessment and then cut the security contractors
| hours by 50% to complete the job.
|
| I don't think AI will completely replace these jobs, but it
| could reduce job numbers by a very large amount.
| smj-edison wrote:
| I think one thing I've heard missing from discussions though is
| that each level of abstraction needs to be introspectable. LLMs
| get compared to compilers a lot, so I'd like to ask: what is
| the equivalent of dumping the tokens, AST, SSA, IR,
| optimization passes, and assembly?
|
| That's where I find the analogy on thin ice, because somebody
| has to understand the layers and their transformations.
| fn-mote wrote:
| "Needs to be" is a strong claim. The skill of debugging
| complex problems by stepping through disassembly to find a
| compiler error is very specialized. Few can do it. Most
| applications don't need that "introspection". They need the
| "encapsulation" and faith that the lower layers work well
| 99.9+% of the time, and they need to know who to call when it
| fails.
|
| I'm not saying generative AI meets this standard, but it's
| different from what you're saying.
| smj-edison wrote:
| Sorry, I should clarify: it's needs to be introspectable by
| somebody. Not every programmer needs to be able to
| introspect the lower layers, but that capability needs to
| exist.
|
| Now I guess you can read the code an LLM generates, so
| maybe that layer does exist. But, that's why I don't like
| the idea of making a programming language for LLMs, by
| LLMs, that's inscrutable by humans. A lot of those
| intermediate layers in compilers are designed for humans,
| with only assembly generation being made for the CPU.
| tosapple wrote:
| This is a good point but may be moot. Our consumer-facing
| LLMs speak C, Python, and JavaScript.
|
| 'Decompilers' are work in the machine code direction for
| human consumption, they can be improved by LLMs.
|
| Militarily, you will want machine code and JS capable
| systems.
|
| Machine code capablities cover both memory leaks and
| firmware dumps and negate the requirement of "source"
| comprehension.
|
| I wanted to +1 you but I don't think I have the karma
| required.
| tosapple wrote:
| Also, smuggling a single binary out of a set of systems
| is likely far easier than targetting a source code
| repository or devbox directly.
| falloutx wrote:
| > It's not so much about replacing developers, but rather
| increasing the level of abstraction developers can work at, to
| allow them to work on more complex problems.
|
| Thats not the goal the Anthropic's CEO has. Nor does any other
| CEO for that matter.
| SonnyTark wrote:
| I recently did a higher education contract for one semester in a
| highly coding focused course. I have a few years of teaching
| experience pre-LLMs so I could evaluate the impact internally, my
| conclusion is that academic education as we know it is basically
| broken forever.
|
| If educators use AI to write/update the lectures and the
| assignments, students use AI to do the assignments, then AI
| evaluates the student's submissions, what is the point?
|
| I'm worried about some major software engineering fields
| experiencing the same problem. If design and requirements are
| written by AI, code is mostly written by AI, and users are mostly
| AI agents. What is the point?
| UncleEntity wrote:
| >> What is the point?
|
| To replace humans permanently from the work force so they can
| focus on the things which matter like being good pets?
|
| Or good techno-serfs...
| bflesch wrote:
| I agree in higher education you need to be willing to learn and
| it's easy to weasel through it without actually building any
| skills. On an individual level that's a tragedy of wasted time
| and potential. On the teaching side it's just fraud if you let
| AI correct the work of your students or if you don't penalize
| people handing in AI-written assignments.
|
| In the US there was this case of a student using religious
| arguments with hand-waving references to the will of god for
| her coursework. Her work was rejected by the tutor and she
| raised a big fuzz on TV. In the end this US university fired
| the tutor and gave her a passing grade.
|
| These kind of stories are not an AI issue but a general problem
| of USA as a country shifting away from education towards
| religious fanaticism. If someone can reference their
| interpretation of god's words without even actually citing the
| bible and they receive a passing grade the whole institution
| loses their credibility.
|
| Today, the United States are a post-factual society with a
| ruling class of christian fanatics. They have been vulnerable
| to vaporware for years. LLMs being heralded as artificial
| intelligence only works with people who never experienced real
| intelligence.
|
| Luckily, every year only a handful of people who have
| motivation, skills and luck are needed to move the needle in
| science and technology. These people can come from many
| countries who have better education systems and no religious
| fanaticism.
| AstroBen wrote:
| What's worse is that universities aren't incentivized to fight
| it at all. Students getting high marks is a good look for them
| blahnjok wrote:
| > We're still in that same fundamental situation. We have better
| tools--vastly better tools--but the thinking remains essential.
|
| But less thinking is essential, or at least that's what it's like
| using the tools.
|
| I've been vibing code almost 100% of the time since Claude 4.5
| Opus came out. I use it to review itself multiple times, and my
| team does the same, then we use AI to review each others' code.
|
| Previously, we whiteboarded and had discussions more than we do
| now. We definitely coded and reviewed more ourselves than we do
| now.
|
| I don't believe that AI is incapable of making mistakes, nor do I
| think that multiple AI reviews are enough to understand and solve
| problems, yet. Some incredibly huge problems are probably on the
| horizon. But for now, the general "AI will not replace
| developers" is false; our roles have changed- we are managers
| now, and for how long?
| mattgreenrocks wrote:
| You made the choice to change your development workflow to
| that. You chose to abdicate thinking to the LLM.
|
| If it's working for you, then great. But don't pretend like it
| is some natural law and must be true everywhere.
| cannonpalms wrote:
| Those whiteboarding sessions and discussions used to serve as
| useful opportunities for context building. Where will that
| context be built within the cycle now? During a production
| incident?
| bdcravens wrote:
| It's like developers are only now awakening to the reality that
| despite being paid well, they never were the capitalists.
| johanbcn wrote:
| The link redirects back to the blog index if your browser is
| configured in Spanish, because it forces to change the language
| to spanish and the article is not available in spanish.
|
| Here's an archived link: https://archive.is/y9SyQ
| strict9 wrote:
| As I have heard from mid level managers and C suite types across
| a few dev jobs. Staff are the largest expense and the technology
| department is the largest cost center. I disagree because Sales
| couldn't exist with a product but that's a lost point.
|
| This is why those same mid level managers and C suite people are
| salivating over AI and mentioning it in every press release.
|
| The reality is that costs are being reduced by replacing US teams
| with offshore teams. And the layoffs are being spun as a result
| of AI adoption.
|
| AI tools for software development are here to stay and accelerate
| in the coming months and years and there will be advances. But
| cost reductions are largely realized via onshore/offshore
| replacement.
|
| The remaining onshore teams must absorb much more slack and fixes
| and in a way end up being more productive.
| jandrese wrote:
| > I disagree because Sales couldn't exist with a product
|
| There are a lot of counterexamples throughout history.
| fn-mote wrote:
| This is too cryptic. Be clearer what you mean. Ponzi schemes?
| jasonjmcghee wrote:
| Many companies aren't selling anything special or are just
| selling an "idea".
|
| Like liquid death sells water for a strangely high amount
| of money - entirely sales / marketing.
|
| International Star Registry gives you a piece of paper and
| a row in a database that says you own a star.
|
| Many luxury things are just because it's sold by that
| luxury brand. They are "worth" that amount of money for the
| status of other people knowing you paid that much for it.
| sosborn wrote:
| Those are all products.
| Tade0 wrote:
| > The reality is that costs are being reduced by replacing US
| teams with offshore teams.
|
| Hailing from an outsourcing destination I need to ask: to where
| specifically? We've been laid off all the same. Me and my team
| spent the second half of 2025 working half time because that's
| the proposition we were given.
|
| What is this fabled place with an apparent abundance of highly
| skilled developers? India? They don't make on average much less
| than we do here - the good ones make more.
|
| My belief is that spending on staff just went down across the
| board because every company noticed that all the others were
| doing layoffs, so pressure to compete in the software space is
| lower. Also all the investor money was spent on datacentres so
| in a way AI is taking jobs.
| svilen_dobrev wrote:
| _Science is hated because its mastery requires too much hard
| work, and, by the same token, its practitioners, the scientists,
| are hated because of their power they derive from it._ - Dijkstra
| '1989
|
| https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD104...
| Twey wrote:
| This is the best explanation of (my take on) this I've seen so
| far.
|
| On top of the article's excellent breakdown of what is happening,
| I think it's important to note a couple of driving factors about
| why (I posit) it is happening:
|
| First, and this is touched upon in the OP but I think could be
| made more explicit, a lot of people who bemoan the existence of
| software development as a discipline see it as a morass of
| incidental complexity. This is significantly an instance of
| Chesterton's Fence. Yes, there certainly is incidental complexity
| in software development, or at least complexity that is
| incidental at the level of abstraction that most corporate
| software lives at. But as a discipline, we're pretty good at
| eliminating it when we find it, though it sometimes takes a while
| -- but the speed with which we iterate means we eliminate it a
| lot faster than most other disciplines. A lot of the complexity
| that remains is actually irreducible, or at least we don't yet
| know how to reduce it. A case in point: programming language
| syntax. To the outsider, the syntax of modern programming
| languages, where the commas go, whether whitespace means
| anything, how angle brackets are parsed, looks to the uninitiated
| like a jumble of arcane nonsense that must be memorized in order
| to start really solving problems, and indeed it's a real barrier
| to entry that non-developers, budding developers, and sometimes
| seasoned developers have to contend with. But it's also (a
| selection of competing frontiers of) the best language we have,
| after many generations of rationalistic and empirical refinement,
| for humans to unambiguously specify what they mean at the
| semantic level of software development as it stands! For a long
| time now we haven't been constrained in the domain of programming
| language syntax by the complexity or performance of parser
| implementations. Instead, modern programming languages tend
| toward simpler formal grammars because they make it easier for
| _humans_ to understand what's going on when reading the code. AI
| tools promise to (amongst other things; don't come at me AI
| enthusiasts!) replace programming language syntax with natural
| language. But actually natural language is a terrible syntax for
| clearly and unambiguously conveying intent! If you want a more
| venerable example, just look at mathematical syntax, a language
| that has never been constrained by computer implementation but
| was developed by humans for humans to read and write their
| meaning in subtle domains efficiently and effectively.
| Mathematicians started with natural language and, through a long
| process of iteration, came to modern-day mathematical syntax.
| There's no push to replace mathematical syntax with natural
| language because, even though that would definitely make some
| parts of the mathematical process easier, we've discovered
| through hard experience that it makes the process as a whole much
| harder.
|
| Second, humans (as a gestalt, not necessarily as individuals)
| always operate at the maximum feasible level of complexity,
| because there are benefits to be extracted from the higher
| complexity levels and if we are operating below our maximum
| complexity budget we're leaving those benefits on the table. From
| time to time we really do manage to hop up the ladder of
| abstraction, at least as far as mainstream development goes. But
| the complexity budget we save by no longer needing to worry about
| the details we've abstracted over immediately gets reallocated to
| the upper abstraction levels, providing things like development
| velocity, correctness guarantees, or UX sophistication. This
| implies that the sum total of complexity involved in software
| development will always remain roughly constant. This is of
| course a win, as we can produce more/better software (assuming we
| really have abstracted over those low-level details and they're
| not waiting for the right time to leak through into our nice
| clean abstraction layer and bite us...), but as a process it will
| never reduce the total amount of 'software development' work to
| be done, whatever kinds of complexity that may come to comprise.
| In fact, anecdotally it seems to be subject to some kind of
| Braess' paradox: the more software we build, the more our society
| runs on software, the higher the demand for software becomes. If
| you think about it, this is actually quite a natural consequence
| of the 'constant complexity budget' idea. As we know, software is
| made of decisions (https://siderea.dreamwidth.org/1219758.html),
| and the more 'manual' labour we free up at the bottom of the
| stack the more we free up complexity budget to be spent on the
| high-level decisions at the top. But there's no cap on decision-
| making! If you ever find yourself with spare complexity budget
| left over after making all your decisions you can always use it
| to make decisions about how you make decisions, ad infinitum, and
| yesterday's high-level decisions become today's menial labour.
| The only way out of that cycle is to develop intelligences
| (software, hardware, wetware...) that can not only reason better
| at a particular level of abstraction than humans but also climb
| the ladder faster than humanity as a whole -- singularity, to use
| a slightly out-of-vogue term. If we as a species fall off the
| bottom of the complexity window then there will no longer be a
| productivity-driven incentive to ideate, though I rather look
| forward to a luxury-goods market of all-organic artisanal ideas
| :)
| njhnjh wrote:
| > don't come at me AI enthusiasts!
|
| no need to worry; none of them know how to read well enough to
| make it this far into your comment
| daxfohl wrote:
| Actually they're the only ones who do: copy and paste into
| chatgpt with "distill this please".
| Twey wrote:
| Twitter has a lot to answer for!
| daxfohl wrote:
| I don't even think that "singularity-level coding agents" get
| us there. A big part of engineering is working with PMs,
| working with management, working across teams, working with
| users, to help distill their disparate wants and needs down
| into a coherent and usable system.
|
| Knowing when to push back, when to trim down a requirement,
| when to replace a requirement with something slightly
| different, when to expand a requirement because you're aware of
| multiple distinct use cases to which it could apply, or even a
| new requirement that's interesting enough that it might warrant
| updating your "vision" for the product itself: that's the real
| engineering work that even a "singularity-level coding agent"
| alone could not replace.
|
| An AI agent almost universally says "yes" to everything. They
| have to! If OpenAI starts selling tools that refuse to do what
| you tell them, who would ever buy them? And maybe that's the
| fundamental distinction. Something that says "yes" to
| everything isn't a partner, it's a tool, and a tool can't
| replace a partner by itself.
| Twey wrote:
| I think that's exactly an example of climbing the abstraction
| ladder. An agent that's incapable of reframing the current
| context, given a bad task, will try its best to complete it.
| An agent capable of generalizing to an overarching goal can
| figure out when the current objective is at odds with the
| more important goal.
|
| You're correct in that these aren't really 'coding agents'
| any more, though. Any more than software developers are!
| FrankRay78 wrote:
| I've been creating agents to better navigate the early
| stages of SDLC. Here's my findings of the last 12 months:
|
| I Built A Team of AI Agents To Perform Business Analysis
|
| https://bettersoftware.uk/2026/01/17/i-built-a-team-of-ai-
| ag...
| heliumtera wrote:
| Business quacks being forever bamboozled because turns out
| implementation is the only thing that matters and hacker culture
| outlived every single promise to eradicate hacker culture.
| jackfranklyn wrote:
| The pattern that gets missed in these discussions: every "no-code
| will replace developers" wave actually creates more developer
| jobs, not fewer.
|
| COBOL was supposed to let managers write programs. VB let
| business users make apps. Squarespace killed the need for web
| developers. And now AI.
|
| What actually happens: the tooling lowers the barrier to entry,
| way more people try to build things, and then those same people
| need actual developers when they hit the edges of what the tool
| can do. The total surface area of "stuff that needs building"
| keeps expanding.
|
| The developers who get displaced are the ones doing purely
| mechanical work that was already well-specified. But the job of
| understanding what to build in the first place, or debugging why
| the automated thing isn't doing what you expected - that's still
| there. Usually there's more of it.
| Palomides wrote:
| >every "no-code will replace developers" wave actually creates
| more developer jobs, not fewer
|
| you mean "created", past tense. You're basically arguing it's
| impossible for technical improvements to reduce the number of
| programmers in the world, ever. The idea that only humans will
| ever be able to debug code or interpret non-technical user
| needs seems questionable to me.
| groundzeros2015 wrote:
| This doesn't seem immediately false. Industrial society
| creates more complexity and specializations. There is more
| work to do all the time.
| Retric wrote:
| Actual AI seems like a possibility here.
|
| Also the percentage of adults working has been dropping for
| a while. Retired used to be a tiny fraction of the
| population that's no longer the case, people spend more
| time being educated or in prison etc.
|
| Overall people are seeing a higher standard of living while
| doing less work.
| groundzeros2015 wrote:
| > Also the percentage of adults working has been dropping
| for a while.
|
| There are lots of negative reasons for this that aren't
| efficiency. Aging demographics. Poor education.
| Increasing complexity leaves people behind.
| Retric wrote:
| Efficiency is why things continue to work as fewer people
| work. Social programs, bank account, etc are just an
| abstraction you need a surplus or the only thing that
| changes is who starves.
| zby wrote:
| Classic Jevons Paradox - when something gets cheaper the market
| for it grows. The unit cost shrinks but the number of units
| bought grows more than this shrinkage.
| enos_feedler wrote:
| Of course that is true. The nuance here is that software
| isn't just getting cheaper but the activity to build it is
| changing. Instead of writing lines of code you are writing
| requirements. That shifts who can do the job. The customer
| might be able to do it themselves. This removes a market, not
| grows one. I am not saying the market will collapse just be
| careful applying a blunt theory to such a profound
| technological shift that isn't just lowering cost but
| changing the entire process.
| lotu wrote:
| You say that like someone that has been coding for so long
| you have forgotten what it's like to not know how to code.
| The customer will have little idea what is even possible
| and will ask for a product that doesn't solve their actual
| problem. AI is amazing at producing answers you previously
| would have looked up on stack overflow, which is very
| useful. It often can type faster that than I can which is
| also useful. However, if we are going to see the
| exponential improvements towards AGI AI boosters talk about
| we would have already seen the start of it.
|
| When LLMs first showed up publicly it was a huge leap
| forward, and people assumed it would continue improving at
| the rate they had seen but it hasn't.
| akhil08agrawal wrote:
| Exactly. The customer doesn't know what's possible, but
| increasingly neither do we unless we're staying current
| at frontier speed. AI can type faster and answer Stack
| Overflow questions. But understanding what's newly
| possible, what competitors just shipped, what research
| just dropped... that requires continuous monitoring
| across arXiv, HN, Reddit, Discord, Twitter. The gap isn't
| coding ability anymore. It's information asymmetry. Teams
| with better intelligence infrastructure will outpace
| teams with better coding skills. That's the shift people
| are missing.
| falloutx wrote:
| >The customer will have little idea what is even possible
| and will ask for a product that doesn't solve their
| actual problem.
|
| How do you know that? For tech products most of the users
| are also technically literate and can easily use Claude
| Code or whatever tool we are using. They easily tell CC
| specifically what they need. Unless you create social
| media apps or bank apps, the customers are pretty tech
| savvy.
| kelipso wrote:
| One example is programmers who would code physics
| simulations that run in massive data. You need a decent
| amount of software engineering skills to maintain
| software like that but the programmer maybe has a BS in
| Physics but doesn't really know the nuances of the actual
| algorithm being implemented.
|
| With AI, probably you don't need 95% of the programmers
| who do that job anyway. Physicists who know the algorithm
| much better can use AI to implement a majority of the
| system and maybe you can have a software engineer
| orchestrate the program in the cloud or supercomputer or
| something but probably not even that.
|
| Okay, the idea I was trying to get across before I
| rambled was that many times the customer knows what they
| want very well and much better than the software
| engineer.
| falloutx wrote:
| Yes, I made the same point. Customers are not as dumb as
| our PMs and Execs think they are. They know their needs
| more than us, unless its about social media and banks.
| pixl97 wrote:
| We talk about things like S curves for AGI, and how it's
| slowing down.
|
| But where is the S curves for programmers at?
| ngrilly wrote:
| "Thinking clearly about complexity" is much more that
| writing requirements.
| mistrial9 wrote:
| "yours is not to reason why, yours is just to do, or die"
|
| ( variation of .. "Ours is not to reason why, ours is but
| to do and die" )
| array_key_first wrote:
| There are also technical requirements, which, in practice,
| you will need to make for applications. Technical
| requirements can be done by people that can't program, but
| it is very close to programming. You reach a manner of
| specification where you're designing schemas, formatting
| specs, high level algorithms, and APIs. Programmers can be,
| and are, good at this, and the people doing it who aren't
| programmers would be good programmers.
|
| At my company, we call them technical business analysts.
| Their director was a developer for 10 years, and then
| skyrocket through the ranks in that department.
| altmanaltman wrote:
| I think it's like super insane people think that anyone
| can just "code" an app with AI and that can replace
| actual paid or established open-source software,
| especially if they are not a programmer or know how to
| think like one. It might seem super obvious if you work
| in tech but most people don't even know what an HTTP
| server is or what is pytho, let alone understanding best
| practices or any kind of high-level thinking regarding
| applications and code. And if you're willing to spend
| that time in learning all that, might as well learn
| programming as well.
|
| AI usage in coding will not stop ofc but normal people
| vibe coding production-ready apps is a pipedream that has
| many issues independent of how good the AI/tools are.
| AstroBen wrote:
| > The customer might be able to do it themselves
|
| Have you ever paid for software? I have, many times, for
| things I could build myself
|
| Building it yourself as a business means you need to staff
| people, taking them away from other work. You need to
| maintain it.
|
| Run even conservative numbers for it and you'll see it's
| pretty damn expensive if humans need to be involved. It's
| not the norm that that's going to be good ROI
|
| No matter how good these tools get, they can't read your
| mind. It takes real work to get something production ready
| and polished out of them
| 1718627440 wrote:
| > Instead of writing lines of code you are writing
| requirements.
|
| https://www.commitstrip.com/en/2016/08/25/a-very-
| comprehensi...
| falloutx wrote:
| Jevons paradox is the stupid. What happened in the past is
| not a guarantee for the future. If you look at the economy,
| you would struggle to find buyers for any slop AI can
| generate, but execs keep pushing it. Case in point the whole
| Microslop saga, where execs start treating paying customers
| as test subjects to please the share holders.
| felipeerias wrote:
| Does that automatically translate into more openings for the
| people whose full time job is providing that thing? I'm not
| sure that it does.
|
| Historically, it would seem that often lowering the amount of
| people needed to produce a good is precisely what makes it
| cheaper.
|
| So it's not hard to imagine a world where AI tools make
| expert software developers significantly more productive
| while enabling other workers to user their own little
| programs and automations on their own jobs.
|
| In such a world, the number of "lines of code" being used
| would be much greater that today.
|
| But it is not clear to me that the amount of people working
| full time as "software developers" would be larger as well.
| pydry wrote:
| This suggests that the latent demand was a lot but it still
| doesnt prove it is unbounded.
|
| At some point the low hanging automation fruit gets tapped out.
| What can be put online that isnt there already? Which business
| processes are obviously going to be made an order magnitude
| more efficient?
|
| Moreover, we've never had more developers and we've exited an
| anomalous period of extraordinarily low interest rates.
|
| The party might be over.
| fn-mote wrote:
| Look at traditional manufacturing. Automation has made
| massive inroads. Not as much of the economy is directly
| supporting (eg, auto) manufacturers as it used to be (stats
| check needed). Nevertheless, there are plenty of mechanical
| engineering jobs. Not so many lower skill line worker jobs in
| the US any more, though. You have to ask yourself which
| category you are in (by analogy). Don't be the SWE working on
| the assembly line.
| pydry wrote:
| >Don't be the SWE working on the assembly line.
|
| The job is literally building automation.
|
| There is no equivalent to "working on the assembly line" as
| an SWE.
|
| >Not so many lower skill line worker jobs in the US any
| more, though
|
| Because Globalization.
| lotu wrote:
| Yes there totally are web development, shovel ware app
| development, are two that I can think of off the top of
| my head.
| pydry wrote:
| That's an assembly line just one churning out cheap crap.
| xnx wrote:
| Machinery made farmers more efficient and now there are more
| farmers than ever.
| victorbjorklund wrote:
| Is this sarcasm?
| wordpad wrote:
| Machinery and scale efficiencies made cost of entry higher
| than ever though
|
| That's not the case for IT where entry barrier has been
| reduced to nothing.
| asdff wrote:
| The machinery replaced a lot of low skill labor. But in its
| wake modern agriculture is now dependent on high skill labor.
| There are probably more engineers, geologists,
| climatologists, biologists, chemists, veterinarians, lawyers,
| and statisticians working in the agriculture sector today
| than there ever were previously.
| m3047 wrote:
| Yes: farmers.
| defrost wrote:
| Indeed.
|
| And overall _fewer_ farmers with more technological skill
| sets than back in the dustbowl days.
|
| Here (Western Australia) the _increase_ in average farm
| size by product can be plotted over time along with the
| fall in numbers working that land.
| tejtm wrote:
| Pre industrial revolution something like 80+ percent of the
| population was involved in agriculture. I question the
| assertion of more farmers now especially since an ever
| growing percentage of farms are not even owned by corporeal
| entities never mind actual farmers.
|
| ooohhh I think I missed the intent of the statement... well
| done!
| herval wrote:
| 80% of the world population back then is less than 50% of
| the current number of people working in farming, so the
| assertion isn't wrong, even if fewer people are working on
| farming proportionally (as it should be, as more complex,
| desirable and higher paid options exist)
| teaearlgraycold wrote:
| There's only so much land and only so much food we need to
| eat. The bounds on what software we need are much wider. But
| certainly there is a limit there as well.
| falloutx wrote:
| Wait what? There are way less farmers than we had in the
| past. In many parts of the world, every member of the family
| was working on the farm, and now only 1 person can do the
| work of 5-10 people.
| DoctorOetker wrote:
| the comment was obviously intended to make you think: yes
| there are fewer _human_ farmers, and more _mechanical_
| ones.
| fatherwavelet wrote:
| I think the better example is the mechanization of the loom
| created a huge amount of jobs in factories relative to the
| hand loom because the demand for clothing could not be met by
| the hand loom.
|
| The craftsman who were forced to go to the factory were not
| paid more or better off.
|
| There is not going to be more software engineers in the
| future than there is now, at least not in what would be
| recognizable as software engineering today. I could see there
| being vastly more startups with founders as agent
| orchestrators and many more CTO jobs. There is no way there
| is many more 2026 version of software engineering jobs at S&P
| 500 companies in the future. That seems borderline delusional
| to me.
| felipeerias wrote:
| If AI tools make expert developers a lot more productive on
| large software projects, while empowering non-developers to
| create their own little programs and automations, I am not
| sure how that would increase the number of people with
| "software developer" as their full-time job.
| cryptonector wrote:
| Right! Sysadmins got displaced, but many became developers.
| DoctorOetker wrote:
| this works for small increments in skill or small shifts in
| adjacent skills.
|
| imagine being an engineer educated in multiple instruction
| sets: when compilers arrive on the scene it sure makes their
| job easier, but that does not retroactively change their
| education to suddenly have all the requisite mathematics and
| domain knowledge of say algorithms and data structures.
|
| what is euphemistically described as a "remaining need for
| people to design, debug and resolve unexpected behaviors" is
| basically a lie by omission: the advent of AI does not
| _automatically_ mean previously representative human workers
| suddenly will know higher level knowledge in order to do
| that. it takes education to achieve that, no trivial amount
| of chatbotting will enable displaced human workers to attain
| that higher level of consciousness. perhaps it can be
| attained by designing software that uploads AI skills to
| humans...
| AstroBen wrote:
| > lowers the barrier to entry, way more people try to build
| things, and then those same people need actual developers when
| they hit the edges of what the tool can do
|
| I was imagining companies expanding the features they wanted
| and was skeptical that would be close to enough, but this makes
| way more sense
| jjmarr wrote:
| The remaining developers also got a big pay bump.
| azan_ wrote:
| > The pattern that gets missed in these discussions: every "no-
| code will replace developers" wave actually creates more
| developer jobs, not fewer.
|
| Doesn't mean it will happen this time (i.e. if AI truly becomes
| what was promised) and actually it's not likely it will!
| eks391 wrote:
| I felt like the article had a good argument for why the AI
| hype will similarly be unsuccessful at erasing developers.
|
| > AI changes how developers work rather than eliminating the
| need for their judgment. The complexity remains. Someone must
| understand the business problem, evaluate whether the
| generated code solves it correctly, consider security
| implications, ensure it integrates properly with existing
| systems, and maintain it as requirements evolve.
|
| What is your rebuttal to this argument leading to the idea
| that developers do need to fear for their job security?
| azan_ wrote:
| > evaluate whether the generated code solves it correctly,
| consider security implications, ensure it integrates
| properly with existing systems, and maintain it as
| requirements evolve
|
| I think you are basing your reasoning on the current
| generation of models. But if future generation will be able
| to do everything you've listed above, what work will be
| there left for developers? I'm not saying that we will ever
| get such models, just that when they appear, they will
| actually displace developers and not create more jobs for
| them. The business problem will be specified by business
| people, and even if they get it wrong it won't matter
| because iteration will be quick and cheap.
|
| > What is your rebuttal to this argument leading to the
| idea that developers do need to fear for their job
| security?
|
| The entire argument is based on assumption that models
| won't get better and will never be able to do things you've
| listed! But once they become capable of these things - what
| work will be there for developers?
| allreduce wrote:
| > if AI truly becomes what was promised
|
| I mean they are promising AGI.
|
| Of course in that case it will not happen this time. However,
| in that case software dev getting automated would concern me
| less than the risk of getting turned into some manner of
| office supply.
|
| Imo as long as we do NOT have AGI, software-focused
| professional will stay a viable career path. Someone will
| have to design software systems on some level of abstraction.
| m463 wrote:
| I think there's a parallel universe with things like system
| administration. I remember people not valuing windows sysadmins
| (as opposed to unix), because all the stuff was gui-based. lol.
| dijit wrote:
| I've watched this pattern play out in systems administration over
| two decades. The pitch is always the same: higher abstractions
| will democratise specialist work. SREs are "fundamentally
| different" from sysadmins, Kubernetes "abstracts away
| complexity."
|
| In practice, I see expensive reinvention. Developers debug
| database corruption after pod restarts without understanding
| filesystem semantics. They recreate monitoring strategies and
| networking patterns on top of CNI because they never learned the
| fundamentals these abstractions are built on. They're not
| learning faster: they're relearning the same operational lessons
| at orders of magnitude higher cost, now mediated through layers
| of YAML.
|
| Each wave of "democratisation" doesn't eliminate specialists. It
| creates new specialists who must learn both the abstraction _and_
| what it 's abstracting. We've made expertise more expensive to
| acquire, not unnecessary.
|
| Excel proves the rule. It's objectively terrible: 30% of genomics
| papers contain gene name errors from autocorrect, JP Morgan lost
| $6bn from formula errors, Public Health England lost 16,000 COVID
| cases hitting row limits. Yet it succeeded at democratisation by
| accepting catastrophic failures no proper system would tolerate.
|
| The pattern repeats because we want Excel's accessibility with
| engineering reliability. You can't have both. Either accept
| disasters for democratisation, or accept that expertise remains
| required.
| walterbell wrote:
| _> accept disasters for democratisation_
|
| Will insurance policy coverage and premiums change when using
| non-deterministic software?
| aleph_minus_one wrote:
| Rather: Barely any insurance company will likely be willing
| to insure this because of the high unpredictability and high
| costs in case of disasters.
| krackers wrote:
| All abstractions are leaky abstractions. E.g. C is a leaky
| abstraction because what you type isn't actually what gets
| emitted (try the same code in two different compilers and one
| might vectorize your loop while the other doesn't).
| chis wrote:
| If Kubernetes didn't in any way reduce labor, then the 95% of
| large corporations that adopted it must all be idiots? I find
| that kinda hard to believe. It seems more likely that
| Kubernetes has been adopted alongside increased scale, such
| that sysadmin jobs have just moved up to new levels of
| complexity.
|
| It seems like in the early 2000s every tiny company needed a
| sysadmin, to manage the physical hardware, manage the DB,
| custom deployment scripts. That particular job is just gone
| now.
| dijit wrote:
| You're absolutely right that sysadmin jobs moved up to new
| levels of complexity rather than disappeared. That's exactly
| my point.
|
| Kubernetes didn't democratise operations, it created a new
| tier of specialists. But what I find interesting is that a
| lot of that adoption wasn't driven by necessity. Studies show
| 60% of hiring managers admit technology trends influence
| their job postings, whilst 82% of developers believe using
| trending tech makes them more attractive to employers. This
| creates a vicious cycle: companies adopt Kubernetes partly
| because they're afraid they won't be able to hire without it,
| developers learn Kubernetes to stay employable, which
| reinforces the hiring pressure.
|
| I've watched small companies with a few hundred users spin up
| full K8s clusters when they could run on a handful of VMs.
| Not because they needed the scale, but because "serious
| startups use Kubernetes." Then they spend six months
| debugging networking instead of shipping features. The
| abstraction didn't eliminate expertise, it forced them to
| learn both Kubernetes and the underlying systems when things
| inevitably break.
|
| The early 2000s sysadmin managing physical hardware is gone.
| They've been replaced by SREs who need to understand
| networking, storage, scheduling, plus the Kubernetes control
| plane, YAML semantics, and operator patterns. We didn't
| reduce the expertise required, we added layers on top of it.
| Which is fine for companies operating at genuine scale, but
| most of that 95% aren't Netflix.
| stoneforger wrote:
| All this is driven by numbers. The bigger you are, the more
| money they give you to burn. No one is really working
| solving problems, it's 99% managing complexity driven by
| shifting goalposts. Noone wants to really build to solve a
| problem, it's a giant financial circle jerk, everybody
| wants to sell and rinse and repeat z line must go up. Noone
| says stop because at 400mph hitting the breaks will get you
| killed.
| vbezhenar wrote:
| Kubernetes enabled qualities small companies didn't dream
| before.
|
| I can implement zero downtime upgrades easily with
| Kubernetes. No more late-day upgrades and late-night debug
| sessions because something went wrong, I can commit any time
| of the day and I can be sure that upgrade will work.
|
| My infrastructure is self-healing. No more crashed app
| server.
|
| Some engineering tasks are standardized and outsourced to the
| professional hoster by using managed serviced. I don't need
| to manage operating system updates and some component updates
| (including Kubernetes).
|
| My infrastructure can be easily scaled horizontally. Both up
| and down.
|
| I can commit changes to git to apply them or I can easily
| revert them. I know the whole history perfectly well.
|
| I would need to reinvent half of Kubernetes before, to enable
| all of that. I guess big companies just did that. I never had
| resources for that. So my deployments were not good. They
| didn't scale, they crashed, they required frequent manual
| interventions, downtimes were frequent. Kubernetes and other
| modern approaches allowed small companies to enjoy things
| they couldn't do before. At the expense of slightly higher
| devops learning curve.
| dvcoolarun wrote:
| A few observations from the current tech + services market:
|
| Service-led companies are doing relatively better right now.
| Lower costs, smaller teams, and a lot of "good enough" duct-tape
| solutions are shipping fast.
|
| Fewer developers are needed to deliver the same output. Mature
| frameworks, cloud, and AI have quietly changed the baseline
| productivity.
|
| And yet, these companies still struggle to hire and retain
| people. Not because talent doesn't exist, but because they want
| people who are immediately useful, adaptable, and can operate in
| messy environments.
|
| Retention is hard when work is rushed, ownership is limited, and
| growth paths are unclear. People leave as soon as they find
| slightly better clarity or stability.
|
| On the economy: it doesn't feel like a crash, more like a slow
| grind. Capital is cautious. Hiring is defensive. Every role needs
| justification.
|
| In this environment, it's a good time for "hackers" -- not
| security hackers, but people who can glue systems together, work
| with constraints, ship fast, and move without perfect
| information.
|
| Comfort-driven careers are struggling. Leverage-driven careers
| are compounding.
|
| Curious to see how others are experiencing this shift.
| dangus wrote:
| Let's not forget that we are just now recovering from the
| market corrections of the pandemic. Pandemic level tech
| industry hiring was insane and many of those companies who
| later held layoffs were just sending the growth line back to
| where it should be.
|
| I think pressure to ship is always there. I don't know if
| that's intensifying or not. I can understand where managers and
| executives think AI = magical work faster juice, but I imagine
| those expectations will hit their correction point at some
| time.
| relaxing wrote:
| > Service-led companies are doing relatively better right now
|
| who
| rectang wrote:
| Can semi-technical people replace developers if those semi-
| technical people accept that the price of avoiding developers is
| a commitment to minimizing total system complexity?
|
| Of course semi-technical people can troubleshoot, it's part of
| nearly every job. (Some are better at it than others.)
|
| But how many semi-technical people can design a system that
| facilitates troubleshooting? Even among my engineering
| acquaintances, there are plenty who cannot.
| mattgreenrocks wrote:
| Remains to be seen for production settings.
|
| My guess is no. I've seen people talk about understanding the
| output of their vibe coding sessions as "nerdy," implying
| they're above that. Refusing the vet AI output is the kiss of
| death to velocity.
| rectang wrote:
| > _Refusing the vet AI output is the kiss of death to
| velocity._
|
| The usual rejoinder I've seen is that AI can just rewrite
| your whole system when complexity explodes. But I see at
| least two problems with that.
|
| AI is impressively good at extracting intent from a ball of
| mud with tons of _accidental_ complexity, and I think we can
| expect it to continue improving. But when a system has a lot
| of _inherent_ complexity, and it 's poorly specified, the
| task is harder.
|
| The second is that small, incremental, reversible changes are
| the most reliable way to evolve a system, and AI doesn't
| repeal that principle. The more churn, the more bugs -- minor
| and major.
| devsda wrote:
| > The usual rejoinder I've seen is that AI can just rewrite
| your whole system when complexity explodes.
|
| Live and even offline data transformation and data
| migration without issues are still difficult problems to
| solve even for humans. It requires meticulous planning and
| execution.
|
| A rewrite has to either discard the previous data or
| transform or keep the data layer intact across versions
| which means more and more tangled spaghetti accumulated
| over rewrites.
| ilaksh wrote:
| I think that programming as a job has already changed. Because it
| is hard for most people to tell the difference between someone
| who actually has programming skills and experience versus someone
| who has some technical ingenuity but has only ever used AI to
| program for them.
|
| Now the expectation from some executives or high level managers
| is that managers and employees will create custom software for
| their own departments with minimal software development costs.
| They can do this using AI tools, often with minimal or no help
| from software engineers.
|
| Its not quite the equivalent of having software developed
| entirely by software engineers, but it can be a significant step
| up from what you typically get from Excel.
|
| I have a pretty radical view that the leading edge of this stuff
| has been moving much faster than most people realize:
|
| 2024: AI-enhanced workflows automating specific tasks
|
| 2025: manually designed/instructed tool calling agents completing
| complex tasks
|
| 2026: the AI Employee emerges -- robust memory, voice interface,
| multiple tasks, computer and browser use. They manage their own
| instructions, tools and context
|
| 2027: Autonomous AI Companies become viable. AI CEO creates and
| manages objectives and AI employees
|
| Note that we have had the AI Employee and AI Organization for
| awhile in different somewhat weak forms. But in the next 18
| months or so as the model and tooling abilities continue to
| improve, they will probably be viable for a growing number of
| business roles and businesses.
| gedy wrote:
| It might just be companies I have worked for in past 25 years,
| but engineers were virtually always the ones to make sense of
| whatever vague idea product and UX were trying to make. It's not
| just code monkey follow the mockup stuff. AI code tools don't
| really solve that.
| FrankRay78 wrote:
| Even the upfront solutioning is being disrupted though:
|
| I Built A Team of AI Agents To Perform Business Analysis
|
| https://bettersoftware.uk/2026/01/17/i-built-a-team-of-ai-ag...
| falloutx wrote:
| This is very accurate to my experience. Product & management
| dont understand basics and anyone who ever had a manager/pm,
| you know you had to explain to them the same thing multiple
| times. Product Managers also struggle to align among themselves
| and they dont care about future velocity, just current
| velocity. Then you have programmers who have to basically
| connect all the things and make sure it doesn't break too much.
| arvindh-manian wrote:
| I'm reminded of this:
| https://www.astralcodexten.com/p/heuristics-that-almost-alwa...
| zkmon wrote:
| The real reason is, expectations and requirements increased
| whenever tools helped more productivity or solved problems. This
| kept complexity growing and the work flowing. Just because you
| use cars instead of horses, it doesn't mean you get more free
| time.
| BiraIgnacio wrote:
| "This time is different"
|
| - Me, the last time it wasn't different
| _pdp_ wrote:
| I was skeptical until 3-4 months ago, but my recent experience
| has been entirely different.
|
| For context: we're the creators of ChatBotKit and have been
| deploying AI agents since the early days (about 2 years ago).
| These days, there's no doubt our systems are self-improving. I
| don't mean to hype this (judge for yourself from my skepticism on
| Reddit) but we're certainly at a stage where the code is writing
| the code, and the quality has increased dramatically. It didn't
| collapse as I was expecting.
|
| What I don't know is why this is happening. Is it our experience,
| the architecture of our codebase, or just better models? The last
| one certainly plays a huge role, but there are also layers of
| foundation that now make everything easier. It's a framework, so
| adding new plugins is much easier than writing the whole
| framework from scratch.
|
| What does this mean for hiring? It's painfully obvious to me that
| we can do more with less, and that's not what I was hoping for
| just a year ago. As someone who's been tinkering with technology
| and programming since age 12, I thought developers would morph
| into something else. But right now, I'm thinking that as systems
| advance, programming will become less of an issue--unless you
| want to rebuild things from scratch, but AI models can do that
| too, arguably faster and better.
|
| It is hard to convey that kind of experience.
|
| I am wondering if others are seeing it too.
| akhil08agrawal wrote:
| I'm seeing it too, but there's a distinction I think matters:
| AI isn't replacing the thinking, it's shifting where the
| bottleneck is. You mention systems are self-improving and code
| quality has increased dramatically. But the constraint isn't
| execution anymore. It's judgment at scale. When AI collapses
| build time from weeks to hours, the new bottleneck becomes
| staying current with what's actually changing. You need to know
| what competitors shipped, what research dropped, what patterns
| are emerging across 50+ sources continuously. Generic ChatGPT
| can't do that. It doesn't know what YOU care about. It starts
| from scratch every time. The real question is how do you build
| personal AI that learns YOUR priorities and filters the noise?
| That's where the leverage is now.
|
| Excited for the future :)
| monus wrote:
| Agreed. I don't know if it will create or eliminate jobs but
| this is certainly another level from what we've seen before.
|
| Since last 2 months, calling LLMs even internet-level invention
| is underserving.
|
| You can see the sentiment shift happening last months from all
| prominent experienced devs to.
| rmitsch wrote:
| Yeah, the latest wave of Opus 4.5, Codex 5.2, Gemini Pro 3
| rendered a lot of my skepticism redundant as well. While I
| generally agree with the Jevon's paradox line of reasoning, I
| have to acknowledge it's difficult to make any reasonable
| prediction on technology that's moving at such immense speed.
|
| I expected the LLM's would have hit a scaling wall by now,
| and I was wrong. Perhaps that'll still happen. If not,
| regardless of whether it'll ultimately create or eliminate
| more jobs, it'll destabilize the job market.
| skybrian wrote:
| My guess: projects "learn" every time we improve documentation,
| add static analysis, write tests, make the API's clearer, and
| so on. Once newly started agents onboard by reading AGENTS.md,
| they're a bit "smarter" than before.
|
| Maybe there's a threshold where improvements become easy,
| depending on the LLM and the project?
|
| As a hobbyist programmer, I feel like I've been promoted to
| pointy-haired boss.
| akhil08agrawal wrote:
| This resonates with what I'm experiencing, but I think the
| article misses the real shift happening now.
|
| The conversation shouldn't be "will AI replace developers". It
| should be "how do humans stay competitive as AI gets 10x better
| every 18 months?"
|
| I watched Claude Code build a feature in 30 minutes that used to
| take weeks. That moment crystallised something: you don't compete
| WITH AI. You need YOUR personal AI.
|
| Here's what I mean: Frontier teams at Anthropic/OpenAI have
| 20-person research teams monitoring everything 24/7. They're 2-4
| weeks ahead today. By 2027? 16+ weeks ahead. This "frontier gap"
| is exponential.
|
| The real problem isn't tools or abstraction. It's information
| overload at scale. When AI collapses execution time, the
| bottleneck shifts to judgment. And good judgment requires staying
| current across 50+ sources (Twitter, Reddit, arXiv, Discord, HN).
|
| Generic ChatGPT is commodity. What matters is: does your AI know
| YOUR priorities? Does it learn YOUR judgment patterns? Does it
| filter information through YOUR lens?
|
| The article is right that tools don't eliminate complexity. But
| personal AI doesn't eliminate complexity. It amplifies YOUR
| ability to handle complexity at frontier speed.
|
| The question isn't about replacement. It's about levelling the
| playing field. And frankly we all are figuring out on how will
| this shape out in the future. And if you have any solution that
| can help me level up, please hit me up.
| teaearlgraycold wrote:
| What feature is it that Claude Code built in 30 minutes?
| pirates wrote:
| For some reason everyone that says things like this never
| follow up with anything concrete, don't share prompts or
| snippets, etc.
| ako wrote:
| This project is completely built using claude code:
| https://github.com/ako/backing-tracks Most of the features
| take less than 30 minutes.
| teaearlgraycold wrote:
| I've seen first hand people talk big about how they used
| LLMs on a project and it's clear they've only done the
| first 80%. Yeah they're good tools. But they also enable
| laziness.
| bflesch wrote:
| > And good judgment requires staying current across 50+ sources
| (Twitter, Reddit, arXiv, Discord, HN).
|
| Your mention of the hellhole that is today's twitter as the
| first item in your list of sources to follow for achieving
| "good judgement" made it easy for me to recognize that in fact
| you have very bad judgement.
| JohnCClarke wrote:
| Consider what happened to painters after the invention of
| photography (~1830s). At first the technology was very limited
| and no threat at all to portrait and landscape painters.
|
| By the 1860s artists were feeling the heat and responded by
| inventing all the "isms" - starting with impressionism. That's
| kept them employed so far, but who knows whether they'll be able
| to co-exist with whatever diffusion models become in 30 years.
| EEBio wrote:
| But the 18th century artist who did portraits and wedding
| paintings is the today's (wedding) photographer.
|
| Does it take less money to commission a single wedding photo
| rather than a wedding painting? Yes. But many more people
| commission them and usually in tens to hundreds, together with
| videos, etc.
|
| An 18th century wedding painter wasn't in the business of
| paintings, but in the business of capturing memories and we do
| that today on much larger scale, more often and in a lot of
| different ways.
|
| I'd also argue more landscape painters exist today than ever.
| bflesch wrote:
| I can't take these kind of comments serious at all. You're
| totally off topic and offer a platitude comparing apples to
| oranges.
| submeta wrote:
| What I'm seeing is that seniors need fewer juniors, not because
| seniors are being replaced, but because managers believe they can
| get the same output with fewer people. Agentic coding tools
| reinforce that belief by offloading the most time-consuming but
| low-complexity work. Tests, boilerplate, CRUD, glue code,
| migrations, and similar tasks. Work that isn't conceptually hard,
| just expensive in hours.
|
| So yes, the market shifts, but mostly at the junior end. Fewer
| entry-level hires, higher expectations for those who are hired,
| and more leverage given to experienced developers who can
| supervise, correct, and integrate what these tools produce.
|
| What these systems cannot replace is senior judgment. You still
| need humans to make strategic decisions about architecture,
| business alignment, go or no-go calls, long-term maintenance
| costs, risk assessment, and deciding what not to build. That is
| not a coding problem. It is a systems, organizational, and
| economic problem.
|
| Agentic coding is good at execution within a frame. Seniors are
| valuable because they define the frame, understand the
| implications, and are accountable for the outcome. Until these
| systems can reason about incentives, constraints, and second-
| order effects across technical and business domains, they are not
| replacing seniors. They are amplifying them.
|
| The real change is not "AI replaces developers." It is that the
| bar for being useful as a developer keeps moving up.
| zozbot234 wrote:
| Is this a real article or just AI-generated text? This whole text
| has a lot of very weird phrasing in it, also it's so strange how
| it just seems to keep trudging on and on without ever getting to
| the point. Actual human-written articles are not like this.
| cryptonector wrote:
| > Yet demand for software far exceeds our ability to create it.
|
| In particular the demand for software tools grows faster than our
| ability to satisfy it. More demand exists than the people who
| would do the demanding can imagine. Many people who are not
| software engineers can now write themselves micro software tools
| using LLMs -- this ranges from home makers to professionals of
| every kind. But the larger systems that require architecting,
| designing, building, and maintaining will continue to require
| some developers -- fewer, perhaps, but perhaps also such systems
| will proliferate.
| jwsteigerwalt wrote:
| Nothing says it like this quote: "quickly discovered that
| readable syntax didn't eliminate the complexity of logic, data
| structures, or system design"
| jackfranklyn wrote:
| The pattern I've noticed building tooling for accountants:
| automation rarely removes jobs, it changes what the job looks
| like.
|
| The bookkeepers I work with used to spend hours on manual data
| entry. Now they spend that time on client advisory work. The
| total workload stayed the same - the composition shifted toward
| higher-value tasks.
|
| Same dynamic played out with spreadsheets in the 80s. Didn't
| eliminate accountants - it created new categories of work and
| raised expectations for what one person could handle.
|
| The interesting question isn't whether developers will be
| replaced but whether the new tool-augmented developer role will
| pay less. Early signs suggest it might - if LLMs commoditise the
| coding part, the premium shifts to understanding problems and
| systems thinking.
| Rumple22Stilk wrote:
| Machine learning is nothing like integer programming. It is an
| emulation of biological learning, it is designed explicitly to
| tackle the same problems human minds excel at. It is an
| organism in direct competition with human beings. Nothing can
| be more dangerous than downplaying this.
| blutoot wrote:
| It's simple -- the more high-minded and snobbish the developer
| class will be (thus extracting the highest salaries in the world)
| and as long as they will continue to maintain this unreal amount
| of gatekeeping, the more the non-developer community (especially
| those at the leadership-level) will continue to revel at the
| prospect of eliminating developers from the value chain.
| -warren wrote:
| I think you're onto something. Replace "developers" with
| "doctors" I that statement and you've described healthcare in
| the mid 1900s. Replace with "masons" and we describe the
| medieval times. There is always a specialized class
| runningmike wrote:
| " AI: The Latest Chapter in a Long Story" More the current
| chapter. Curious about the next one!
| throwjjj wrote:
| You shouldn't ask developers about this.
|
| You should ask the business owners. They are hiring fewer
| developers and looking to cut more.
| austin-cheney wrote:
| We could have replaced tons of developers if only employers were
| selective in their hiring and invested in training. Instead there
| are a ton of hardly marginal developers in employment.
|
| Case in point: web frameworks as mentioned in the article. These
| frameworks do not exist to increase productivity for either the
| developer or the employer. They exist to mitigate training and
| lower the bar so the employer has a wider pool of candidates to
| select from.
| gkoberger wrote:
| I disagree. A good framework makes code more maintainable, and
| makes it so you can focus on what's important or unique to your
| product. It certainly makes you faster.
| amelius wrote:
| How much tech debt has AI paid off actually?
| yearolinuxdsktp wrote:
| Who remembers Model-Driven Architecture and code generation from
| UML?
|
| Nothing can replace code, because code is design[1]. Low-code
| came about as a solution to the insane clickfest of no-code. And
| what is low-code? It's code over a boilerplate-free
| appropriately-high level of abstraction.
|
| This reminds me of the 1st chapter of the Clean Architecture
| book[2], pages 5 and 6, which shows a chart of engineering staff
| growing from tens to 1200 and yet the product line count (as a
| simple estimate of features) asymptotically stops growing, barely
| growing in lines of code from 300 staff to 1200 staff.
|
| As companies grow and throw more staff at the problem, software
| architecture is often neglected, dramatically slowing development
| (due to massive overhead required to implement features).
|
| Some companies decided that the answer is to optimize for hiring
| lots of junior engineers to write dumbed down code full of
| boilerplate (e.g. Go).
|
| The hard part is staying on top of the technical (architectural
| and design) debt to make sure that feature development is
| efficient. That is the hard job and the true value of a software
| architect, not writing design documents.
|
| [1]
| https://www.developerdotstar.com/mag/articles/reeves_origina... A
| timeless article from 1992, pre-UML, but references precursors
| like Booch and object diagrams, as well as CASE tools [2] You can
| read it here in Amazon sample chapter:
| https://read.amazon.com/sample/0134494164?clientId=share
___________________________________________________________________
(page generated 2026-01-17 23:00 UTC)