[HN Gopher] Has the cost of building software dropped 90%?
___________________________________________________________________
Has the cost of building software dropped 90%?
Author : martinald
Score : 97 points
Date : 2025-12-08 19:00 UTC (3 hours ago)
(HTM) web link (martinalderson.com)
(TXT) w3m dump (martinalderson.com)
| mwkaufma wrote:
| Feels almost too on-the-nose to write "Betteridge's Law of
| Headlines" but the answer is obviously no. Look no further than
| the farce of their made-up "graph" of cost over time with no
| units or evidence.
| more_corn wrote:
| Ask someone who builds software for a fee. Are you able to do 90%
| more? Fire 9/10 engineers? Produce 90% faster?
|
| No, no, and no.
| recursive wrote:
| It's even worse. If the cost drops by 90%, the corresponding
| productivity increase should be 900%, not 90%.
| bdangubic wrote:
| 90% more - nope. 35-55% more, just about on average. I am
| 30-year in though, not sure what these numbers are for junior
| devs
| nottorp wrote:
| https://arstechnica.com/ai/2025/07/study-finds-ai-tools-
| made...
|
| They thought they were faster too.
|
| Yes, I know, AGI is just around the corner, we just need to
| wait more because "agents" are improving every day.
|
| In the mean time, LLMs are kinda useful instead of web
| searches, mostly because search is both full of spam and the
| search providers are toxic.
| bdangubic wrote:
| I am just talking about personal point-of-view, wasn't
| interviewed by Arstechnica or others that live off
| clickbait
| recursive wrote:
| Did I miss something or is there actually no evidence provided
| that costs have dropped?
| isoprophlex wrote:
| Well... evidence, but there's obviously a graph with a line
| going places!
| TheRoque wrote:
| Especially if you factor-in the fact that the AI companies are
| losing money for now, and that it's not sustainable.
| djmips wrote:
| Yeah, when does the other shoe drops and after being addicted
| to AI coding we suddenly have the rug pulled on price.
| BigHatLogan wrote:
| Good write-up. I don't disagree with any of his points, but does
| anybody here have practical suggestions on how to move forward
| and think about one's career? I've been a frontend (with a little
| full stack) for a few years now, and much of the modern landscape
| concerns me, specifically with how I should be positioning
| myself.
|
| I hear vague suggestions like "get better at the business domain"
| and other things like that. I'm not discounting any of that, but
| what does this actually mean or look like in your day-to-day
| life? I'm working at a mid-sized company right now. I use Cursor
| and some other tools, but I can't help but wonder if I'm still
| falling behind or doing something wrong.
|
| Does anybody have any thoughts or suggestions on this? The
| landscape and horizon just seems so foggy to me right now.
| isoprophlex wrote:
| Sheep farming sounds nice. Or making wooden furniture.
| Something physical.
| martinald wrote:
| Author here, thanks for your kind words!
|
| I think it's about looking at what you're building and
| proactively suggesting/prototyping what else could be useful
| for the business. This does get tricky in large corps where
| things are often quite siloed, but can you think "one step
| ahead" of the product requirements and build that as well?
|
| I think regardless if you build it, it's a good exercise to run
| on any project - what would you think to build next, and what
| does the business actually want. If you are getting closer on
| those requests in your head then I think it's a positive sign
| you are understanding the domain.
| BigHatLogan wrote:
| I think you're right about trying to stay one step ahead of
| product requirements. Maybe my issue here is that I'm looking
| for another "path" where one might not exist, at least not a
| concretely defined one. From childhood to now, things were
| set in front of me and I just sort of did them, but now it
| feels like we're entering a real fog of war.
|
| It would be helpful, as you suggest, to start shifting away
| from "I code based on concrete specs" to "I discover
| solutions for the business."
|
| Thanks for the reply (and for the original essay). It has
| given me a lot to chew on.
| catigula wrote:
| Nobody knows the answer.
|
| Answers I see are typically "be a product manager" or "start
| your own business" which obviously 95% of developers
| can't/don't want to do.
| embedding-shape wrote:
| Don't chase specific technologies, especially not ones driven
| by for-profit companies. Chase ideas, become great in one slice
| of the industry, and the very least you can always fall back on
| that. Once established within a domain, you can always try to
| branch out, and feel a lot more comfortable doing so.
|
| Ultimately, software is for doing _something_ , and that
| something can be a whole range of things. If you become really
| good at just a slice of that, things get a lot easier
| regardless of the general state of the industry.
| BigHatLogan wrote:
| Thanks for the response. When you say "one slice of the
| industry", is the suggestion to understand the core business
| of whatever I'm building instead of being the "specs to code"
| person? I guess this is where the advice starts to become
| fuzzy and vague for me.
| colonCapitalDee wrote:
| Blind leading the blind, but my thinking is this:
|
| 1. Use the tools to their fullest extend, push boundaries and
| figure out what works and what doesn't
|
| 2. Be more than your tools
|
| As long as you + LLM is significantly more valuable than just
| an LLM, you'll be employed. I don't know how "practical" this
| advice is, because it's basically what you're already doing,
| but it's how I'm thinking about it.
| ares623 wrote:
| Realistically, someone else + LLM at -10% compensation will
| be employed
| ubercow13 wrote:
| Then why wasn't someone else employed at -10% compensation
| instead of you before LLMs?
| bitwize wrote:
| Let's say LLMs add 50 "skill points" to your output.
| Developer A is at 60 skill points in terms of coding
| ability, developer B is at 40. The differential between
| them looks large. Now add LLMs. Developer A is at 110
| skill points, developer B is at 90. Same difference, but
| now it doesn't look as large.
|
| The (perceived, alleged) augmentation by LLMs makes
| individual differences in developer skill seem less
| important. From the business's perspective, you are not
| getting much less by hiring a less skilled developer vs.
| hiring a more skilled one, even if both of them would be
| using LLMs on the job.
|
| Obviously, real life is more complicated than this, but
| that's a rough idea of what the CEO and the shareholders
| are grappling with from a talent acquisition standpoint.
| MrPapz wrote:
| My suggestion would be to move to a higher level of
| abstraction, change the way which you view the system.
|
| Maybe becoming full stack? Maybe understanding the industry a
| little deeper? Maybe analyzing your company's competitors
| better? That would increase your value for the business (a bit
| of overlap with product management though). Assuming you can
| now deliver the expected tech part more easily, that's what I'd
| do.
|
| As for me, I've moved to a permanent product management
| position.
| nick486 wrote:
| Its always been foggy. Even without AI, you were always at risk
| of having your field disrupted by some tech you didn't see
| coming.
|
| AI will probably replace the bottom ~30-70%(depends who you
| ask) of dev jobs. Dont get caught in the dead zone when the
| bottom falls out.
|
| Exactly how we'll train good devs in the future, if we don't
| give them a financially stable environment environment to learn
| in while they're bad, is an open question.
| ronald_petty wrote:
| Great question, hard to quickly answer.
|
| My .02$. Show you can tackle harder problems. That includes
| knowing which problems matter. That happens with learning a
| "domain", versus just learning a tool (e.g. web development) in
| a domain.
|
| Change is scary, but thats because most aren't willing to
| change. Part of the "scare" is the fear of lost investment
| (e.g. pick wrong major or career). I can appreciate that, but
| with a little flexibility, that investment can be repurposed
| quicker today that in pre-2022 thanks to AI.
|
| AI is just another tool, treat it like a partner not a
| replacement. That can also include learning a domain. Ask AI
| how a given process works, its history, regulations, etc. Go
| confirm what it says. Have it break it down. We now can learn
| faster than ever before. Trust but verify.
|
| You are using Cursor, that shows a willingness to try new
| things. Now try to move faster than before, go deeper into the
| challenges. That is always going to be valued.
| samdoesnothing wrote:
| Also blind leading the blind here but I see two paths.
|
| 1) Specialize in product engineering, which means taking on
| more business responsibility. Maybe it means building your own
| products, or maybe it means trying to get yourself in a more
| customer-facing or managerial role? Im not very sure. Probably
| do this if you think AI will be replacing most programmers.
|
| 2) Specialize in hard programming problems that AI can't do.
| Frontend is probably most at risk, low level systems
| programming least at risk. Learn Rust or C/C++, or maybe
| backend (C#\Java\Go) if you don't want to transition all the
| way to low level systems stuff.
|
| That being said I don't think AI is really going to replace us
| anytime soon.
| dclnbrght wrote:
| https://news.ycombinator.com/item?id=46197349
| andrewstuart wrote:
| If you're quicker then competition heats up management wants more
| done, efficiencies are soon forgotten and new expectations and
| baselines set.
| foxglacier wrote:
| Sure but that's the good of it. Lower labor cost = more
| productivity. The customer wins in the end because the
| equivalent product is cheaper or a better product costs the
| same. Businesses and employees still have to compete against
| each other so things won't get easier for them in the long
| term.
| Draiken wrote:
| Except this is capitalism, so any improvements will go
| disproportionately to the owners. This narrative of
| improvements for customers has been repeated for decades and
| it keeps being wrong.
|
| More stock buybacks and subscriptions!
| AngryData wrote:
| The customer only wins if the customer is the one using the
| tools directly, otherwise it leaves all the power in the
| hands of businesses who's only real goal is maximum profits.
| And without already possessing domain knowledge to be able to
| guide, judge, and correct AI along the way, its existence
| will be of limited use to consumers and business will not
| feel much pressure to make anything cheaper, it just leaves
| more margin to funnel to the top.
| qwertyastronaut wrote:
| I don't know if it's 90%, but I'm shipping in 2 days things that
| took 2-4 weeks before.
|
| Opus 4.5 in particular has been a profound shift. I'm not sure
| how software dev as a career survives this. I have nearly 0
| reason to hire a developer for my company because I just write a
| spec and Claude does it in one shot.
|
| It's honestly scary, and I hope my company doesn't fail because
| as a developer I'm fucked. But... statistically my business will
| fail.
|
| I think in a few years there will only be a handful of software
| companies--the ones who already have control of distribution.
| Products can be cloned in a few weeks now; not long until it's a
| few minutes. I used to see a new competitor once every six
| months. Now I see a new competitor every few hours.
| martinald wrote:
| Agreed. Opus 4.5 does feel like a real shift and I have had
| exactly your experience. I've shipped stuff that would have
| taken me weeks in days. And really to a much higher quality
| standard - test suites would have been far smaller if I'd built
| manually. And probably everything in MVP Bootstrap CSS.
| bdangubic wrote:
| this is roughly same for me
| llmslave wrote:
| Yeah, I really think software engineering is over. Not right
| now, but Opus 4.5 is incredible, it wont be long before 5 and
| 5.5 are released.
|
| They wont automate everything, but the bar for being able to
| produce working software will plummet.
| throwaway31131 wrote:
| Just out of curiosity, what software product were you making in
| two weeks before using AI? Or maybe I'm misunderstanding your
| use of shipping.
| LPisGood wrote:
| I feel like I have have heard this exact statement about model
| FooBar X.Y about a half dozen times over the last couple of
| years.
| IceDane wrote:
| I'd love to hear what sort of software you are building.
| neilv wrote:
| Copying GPL code, with global search&replace of the brand names,
| has always lowered the cost of software 'development'
| dramatically.
| bdangubic wrote:
| I would love to see where I can find a full test coverage to
| paste in for an internal too that I can search&replace on to
| get it working...
| JohnMakin wrote:
| This article mentions cost to ship, but ignores that the largest
| cost of any software project isn't consumed by how long it takes
| to get to market, but by maintenance and addition of new
| features. How is agentic coding doing there? I've only seen huge,
| unmaintainable messes so far.
| bdangubic wrote:
| one year in, AI slop > Human-written slop
| JohnMakin wrote:
| I am highly skeptical of this claim.
| bdangubic wrote:
| personal experience, not general claim. I am 30-years in
| the industry and have seen _a lot_ of human-written code...
| bdangubic wrote:
| there are many millions of people writing code... that's
| way too many to get any good quality. you might get lucky
| and get involved with codebase which does not make you
| dizzy (or outright sick) but most of us are not _that_
| lucky
| martinald wrote:
| Agreed. I think a core problem is many developers (on HN)
| don't realise how "bad" so much human written code is.
|
| I've seen unbelievably complex logistics logic coded
| in... WordPress templates and plugins to take a random
| example. Actually virtually impossible to figure out -
| but AI can actually extract all the logic pretty well
| now.
| jimbokun wrote:
| Does this mean the AI slop is higher quality or that there's
| more of it?
| p2detar wrote:
| While this is true, I think some fields like game development
| may not always have this problem. If your goal is to release a
| non-upgradable game - fps, arcade, single-player titles,
| maintenance may be much less important than shipping.
|
| edit: typos
| liampulles wrote:
| I think that is an applicable domain, but the problem is that
| every gamer I know who is not in the tech industry is
| vehemently opposed to AI.
| emodendroket wrote:
| Well, they just love complaining. You won't find many who
| profess to like DLC, yet that sells.
| krupan wrote:
| I'm trying to understand where this kind of thinking comes
| from. I'm not trying to belittle you, I sincerely want to
| know: Are you aware that everyone writing software has the
| goal of releasing software so perfect it never needs an
| upgrade? Are you aware that we've all learned that that's
| impossible?
| tehjoker wrote:
| this was basically true until consoles started getting an
| online element. the up-front testing was more serious
| compared to the complexity of the games. there were still
| bugs, but there was no way to upgrade short of a recall.
| pjc50 wrote:
| Nobody wants to ship that! They want perpetually upgraded
| live service games instead, because that's recurring revenue.
| an0malous wrote:
| Then why is all my software slower, buggier, and with a worse UX?
| HumblyTossed wrote:
| Right? Past couple years software quality has taken a shit.
| paoaoaks wrote:
| > written an entire unit/integration test suite in a few hours
|
| It's often hard to ground how "good" blog writers are, but
| tidbits like this make it easy to disregard the author's
| opinions. I've worked in many codebases where the test writers
| share the authors sentiment. They are awful and the tests are at
| best useless and often harmful.
|
| Getting to this point in your career without understanding how to
| write effective tests is a major red flag.
| p1necone wrote:
| I've used llms to _help_ me write large sets of test cases, but
| it requires a lot of iteration and the mistakes it makes are
| both very common and _insidious_.
|
| Stuff like reimplementing large amounts of the code inside the
| tests because testing the actual code is "too hard", spending
| inordinate amounts of time covering every single edge case on
| some tiny bit of input processing unrelated to the main
| business logic, mocking out the code under test, changing
| failing tests to match obviously incorrect behavior...
| basically all the mistakes you expect to see totally green devs
| who don't understand the purpose of tests making.
|
| It saves a shitload of time setting up all the scaffolding and
| whatnot, but unless they very carefully reviewed and either
| manually edited or iterated a lot with the LLM I would be
| almost certain the tests were garbage given my experiences.
|
| (This is with fairly current models too btw - mostly sonnet 4
| and 4.5, also in fairness to the LLM a shocking proportion of
| tests written by real people that I've read are also unhelpful
| garbage, I can't imagine the training data is of great quality)
| IceDane wrote:
| But we have 500% code coverage?!?!
| debo_ wrote:
| > I'm sure every organisation has hundreds if not thousands of
| Excel sheets tracking important business processes that would be
| far better off as a SaaS app.
|
| Far better off for who? People constantly dismiss spreadsheets,
| but in many cases, they are more powerful, more easily used by
| the people who have the domain knowledge required to properly
| implement calculations or workflow, and are more or less
| universally accessible.
| nesarkvechnep wrote:
| I'm yet to see a spreadsheet workflow successfully replaced by
| something else.
| crubier wrote:
| Streamlit apps or similar are doing a great job at this where
| I'm at.
|
| As simple to build and deploy as Excel, but with the right
| data types, the right UI, the right access and version
| control, the right programming language that LLMs understand,
| the right SW ecosystem and packages, etc.
| SauntSolaire wrote:
| Are they actually as simply to deploy as Excel? My guess
| would be that most streamlit apps never make it further
| than the computer they're written on.
| tehjoker wrote:
| maybe the strategy in those cases is to augment the core
| spreadsheet with tools that can unit test it and broadcast
| changes etc
| esafak wrote:
| Programming in a spreadsheet is an anti-pattern. Does anyone
| review your workflow? Write tests for it? Use a real
| programming language; a notebook at least.
| martinald wrote:
| Author here. Of course not everything needs to be a web app.
| But I'm meaning a lot of core sheets I see in businesses need
| more structure round them.
|
| Especially for collaboration, access controls, etc. Not to
| mention they could do with unit testing.
| tonyarkles wrote:
| Counterpoint: if a small part of the process is getting
| tweaked, how responsive can the team responsible for these
| apps be? That's the killer feature of spreadsheets for
| business processes: the accountants can change the accounting
| spreadsheets, the shipping and receiving people can change
| theirs, and there's no team in the way to act as a
| bottleneck.
|
| That's also the reason that so-called "Shadow IT" exists.
| Teams will do whatever they need to do to get their jobs
| done, whether or not IT is going to be helpful in that
| effort.
| chasd00 wrote:
| i've seen many attempts to turn a widely used spreadsheet
| into a webapp. Eventually, it becomes an attempt to re-
| implement spreadsheets. The first time something changes
| and the user says "well in Excel i would just do this..."
| the dev team is off chasing existing features of excel for
| eternity and the users are pissed because it takes so long
| and is buggy, meanwhile, excel is right there ready and
| waiting.
| LPisGood wrote:
| I have never heard of shadow IT. What is that?
| analog31 wrote:
| It's when the users start taking care of IT issues
| themselves. Maybe the name comes from the Shadow Cabinet
| in England?
|
| Where it might not be obvious is that IT in this context
| is not just pulling wires and approving tickets, but is
| "information technology" in the broader sense of using
| computers to solve problems. This could mean creating
| custom apps, databases, etc. A huge amount of this goes
| on in most businesses. Solutions can range from trivial
| to massive and mission-critical.
| _puk wrote:
| It's where you have processes etc set up to manage your
| IT infra, but these very processes often make it
| impossible / too time consuming to use anything.
|
| The team that needs it ends up managing things itself
| without central IT support (or visibility, or security
| etc..)
|
| Think being given a locked down laptop and no admin
| access. Either get IT to give you admin access or buy
| another laptop that isn't visible to IT and let's you
| install whatever you need to get your job done.
|
| The latter is often quicker and easier.
| swatcoder wrote:
| It's rare than a third-party SaaS can approximate one of
| these "core sheets" and most of the exceptions have already
| been explored over the last several decades years.
|
| You have to remember that an SaaS, just like shrink-wrap
| software, reflects _someone else_ 's model of of a process or
| workflow and the model and implementation evolve per the
| timeline/agenda of its publisher.
|
| For certain parts of certain workflows, where there's a
| highly normative and robust industry standard, like invoicing
| or accounting or inventory tracking, that compromise is
| worthwhile and we've had both shrink-wrap and SaaS products
| servicing those needs for a very very long time. We see churn
| in which application is most popular and what it's interface
| and pricing look like, but the domains being served have
| mostly been constant (mostly only growing as new business
| lines/fashions emerge and mature).
|
| Most of the stuff that remains in a "core sheet" could
| benefit from the attention of a practiced engineer who could
| make it more reliable and robust, but almost always reflects
| that the represented business process is somehow peculiar to
| the organization. As Access and FoxPro and VBA and Zapier and
| so many tools have done before, LLM coding assistants and
| software building tools offer some promise in shaking some of
| these up by letting orgs convert their "core sheets" to
| "internal applications".
|
| But that's not an opportunity for SaaS entrepreneurs. It's an
| opportunity for LLM experts to try to come in and pitch
| _private_ , bespoke software solutions for a better deal than
| whatever the Access guy had promised 20 years ago. Because of
| the long-term maintenance challenges that still plague code
| that's too LLM-colored, I wouldn't want to _be_ that expert
| pitching that work, but it 's an opportunity for some
| ambitious folks for sure.
| ASalazarMX wrote:
| > a lot of core sheets I see in businesses need more
| structure round them
|
| We had this decades ago, it was called dBase, but FoxPro
| (pre-Microsoft) was great too. Visual For Pro or MS Access
| were a brutal downgrade of every good aspect of it.
|
| Imagine if today some startup offered a full-stack(TM)
| platform that included IDE, a language with SQL-like
| features, visual UI designer, database; generated small
| standalone binarires, was performant, and was smaller than
| most web homepages.
|
| There are modern options, like Servoy or Lianja, but they're
| too "cloudy" to be considered equivalents.
|
| Edit: seems like there's OpenXava too, but that is Java-
| based, too hardcore for non-professional programmers IMO. The
| beauty of xBase was that even a highschooler could whip out a
| decent business application if the requirements were modest.
| robotresearcher wrote:
| Spreadsheets are an incredible tool. They were a key innovation
| in the history of applications. I love them and use them.
|
| But it's very hard to have a large conventional cell-formula
| spreadsheet that is correct. The programming model / UI are
| closely coupled, so it's hard to see what's going on once your
| sheet is above some fairly low complexity. And many workplaces
| have monstrous sheets that run important things, curated
| lovingly (?) for many years. I bet many or most of them have
| significant errors.
| ASalazarMX wrote:
| It's astounding how useful and intuitive they are, but my
| biggest gripe is how easy is for anyone to mess calculations,
| say, SUM(<RANGE>), by simply adding one row/column/cell.
|
| I use Google Worksheets frequently to track new things that
| fit into lists/tables, and giving someone else editor access
| without them knowing a few worksheet nuances means I have to
| recheck and correct them every month or two.
| robotresearcher wrote:
| Does anyone make a sanity checker for Excel or Sheets that
| notices things like that? Would be _incredibly_ helpful!
| jimbokun wrote:
| Better security. Better availability. Less chance of losing
| data.
|
| Assuming the SaaS is implemented competently, of course.
| Otherwise there's not much advantage.
| on_the_train wrote:
| Ai saves me like an hour per month tops. I still don't understand
| the hype. It's a solution in search of a problem. It can't solve
| the hard coding problems. And it doesn't say when it can't solve
| the essay ones either. It's less valuable than resharper. So the
| business value is maybe $10 a month. That can't finance this
| industry.
| averageRoyalty wrote:
| I read these sort of comments every so often and I do not
| understand them. You are in a sea of people telling you that
| they are developing software much quicker which ticks the
| required boxes. I understand that for some reason this isn't
| the case for your work flow, but obviously it has a lot more
| value for others.
|
| If you are a chairmaker and everyone gains access to a machine
| that can spit out all the chair components but sometimes only
| spits out 3 legs or makes a mistake on the backs, you might
| find it pointless. Maybe it can't do all the nice artisan
| styles you can do. But you can be confident others will take
| advantage of this chair machine, work around the issues and
| drive the price down from $20 per chair to $2 per chair. In 24
| months, you won't be able to sell enough of your chairs any
| more.
| throwaway31131 wrote:
| Maybe, or maybe the size of the chair market grows because
| with $2 chairs more buyers enter. The high end is roughly
| unaffected because they were never going to buy a low end
| chair.
| on_the_train wrote:
| > You are in a sea of people telling you that they are
| developing software much quicker which ticks the required
| boxes
|
| But that's exactly not the case. Everyone is wondering what
| tf this is supposed to be for. People are vehemently against
| this tech, and yet it gets shoved down our throats although
| it's prohibitively expensive.
|
| Coding should be among the easiest problems to tackle, yet
| none of the big models can write basic "real" code. They
| break when things get more complex than pong. And they can't
| even write a single proper function with modern c++
| templating stuff for example.
| Agingcoder wrote:
| They can actually - I thought they couldn't , but the
| latest ones can, much to my surprise.
|
| I changed my mind after playing with cursor 2 ( cursor 1
| had lasted all of 10 mins), which actually wrote a full
| blown app with documentation, tests , coverage, ci/cd, etc.
| I was able to have it find a bug I encountered when using
| the app - it literally ran the code, inserted extra logs,
| grepped the logs , found the bug and fixed it.
| margorczynski wrote:
| > Coding should be among the easiest problems to tackle,
| yet none of the big models can write basic "real" code.
| They break when things get more complex than pong. And they
| can't even write a single proper function with modern c++
| templating stuff for example.
|
| This is simply false and ignorant
| pton_xd wrote:
| > And they can't even write a single proper function with
| modern c++ templating stuff for example.
|
| That's just not true. ChatGPT 4 could explain template
| concepts lucidly but would always bungle the
| implementation. Recent models are generally very strong at
| generating templated code, even if its quite complex.
|
| If you really get out into the weeds with things like ADL
| edge cases or static initialization issues they'll still go
| off the rails and start suggesting nonsense.
| nine_k wrote:
| Had the cost of building custom software dropped 90%, we would be
| seeing a flurry of low-cost, decent-quality SaaS offering all
| over the marketplace, possibly undercutting some established
| players.
|
| From where I sit, right now, this does not seem to be the case.
|
| This is as if writing down the code is not the biggest problem,
| or the biggest time sink, of building software.
| martinald wrote:
| It is happening though internally in businesses I've worked
| with. A few of them are starting to replace SaaS tools with
| custom built internal tooling. I suspect this pattern is
| happening everywhere to a varying level.
|
| Often these SaaS tools are expensive, aren't actually that
| complicated (or if they are complicated, the bit they need
| isn't) and have limitations.
|
| For example, a company I know recently got told their v1 API
| they relied on on some back office SaaS tool was being
| deprecated. V2 of the API didn't have the same features.
|
| Result = dev spends a week or two rebuilding that tool. It's
| shipped and in production now. It would have taken similar
| amount of time to work around the API deprecation.
| lossolo wrote:
| > It is happening though internally in businesses I've worked
| with
|
| How many samples do you have?
|
| Which industries are they from?
|
| Which SaaS products were they using, exactly and which
| features?
|
| > ...a company I know recently got told their v1 API they
| relied on on some back office SaaS tool was being deprecated.
| V2 of the API didn't have the same features ... dev spends a
| week or two rebuilding that tool
|
| Was that SaaS the equivalent of the left-pad Node.js module?
| wongarsu wrote:
| Lots of companies make good money selling the equivalent of
| leftpad for confluence or jira. Anecdotally, that's exactly
| the kind of stuff that gets replaced with homegrown AI-
| built solutions at our company
| hobs wrote:
| I helped a company that is build averse move off of
| Fivetran to Debezium and some of their own internal tooling
| for the same workload they are paying 40k less a month
| (yeah they just raised their prices again).
|
| Now, that's not exactly the same thing, but their paucity
| of skills made them terrified to do something like this
| before, they had little confidence they could pull it off
| and their exec team would just scoff and tell them to work
| on other revenue generating activities.
|
| Now the confidence of Claude is hard to shake off of them
| which is not exactly the way I wanted the pendulum to
| swing, but its almost 500k yearly back in their pockets.
| dismantlethesun wrote:
| I'm not the OP, but I do have an annectote.
|
| We've got an backend pipeline that does image processing.
| At every step of the pipeline, it would make copies of
| small (less than 10MB) files from an S3 storage source, do
| a task, then copy the results back up to the storage
| source.
|
| Originally, it was using AWS but years ago it was decided
| that AWS was not cost effective so we turned to another
| partner OVH and Backblaze.
|
| Unfortunately, the reliability and throughput of both of
| them isn't as consistent as AWS and this has been a
| constant headache.
|
| We were going to go back to AWS or find a new partner, but
| I nominated we use NFS. So we build nothing, pay nothing,
| get POSIX semantics back, and speed has gone up 3x. At
| peak, we only copy 40GB of files per day, so it was never
| really necessary to use S3 except that our servers were
| distributed and that was the only way anyone previously
| could think to give each server the same storage source.
|
| While this isn't exactly what the OP and you are talking
| about, I think it illustrates a fact: SaaS software was
| seen as the hammer to all nails, giving you solutions and
| externalizing problems and accountability.
|
| Now that either the industry has matured, building in-house
| is easier, or cost centers need to be reduced, SaaS is
| going be re-evaluated under the context of 'do we really
| need it'?
|
| I think the answer to many people is going to be no, you
| don't need enterprise level solutions at all levels of your
| company, especially if you're not anywhere near the Fortune
| 1000.
| neom wrote:
| I'm a consultant so I see lots of businesses, it's
| happening in all of them. I'm not seeing people rip out
| tools for custom builds to be clear, I just see people
| solving today problems with custom apps.
| nugger wrote:
| I don't understand the timelines here at all.
| renewiltord wrote:
| I know of at least two multi-billion corps that are moving to
| internal ETL tools instead of 5tran now because the cost to
| maintain internally is much lower and you can customize for
| cheap. SaaS as a model is at risk without something tying
| someone down.
| thot_experiment wrote:
| To be fair, writing a SaaS software is like an order, perhaps
| two orders of magnitude more effort than writing software that
| runs on a computer and does the thing you want. There's a ton
| of stuff that SaaS is used for now that's basically trivial and
| literally all the "engineering" effort is spent on ensuring
| vendor lock in and retaining control of the software so that
| you can force people to keep paying you.
| layer8 wrote:
| We should also get a flurry of low-cost, decent-quality
| native local-first software, but I don't see any.
| paulddraper wrote:
| > Had the cost of building custom software dropped 90%, we
| would be seeing a flurry of low-cost, decent-quality SaaS
| offering all over the marketplace, possibly undercutting some
| established players.
|
| _NODS HEAD VIGOROUSLY_
|
| Last 12 months: Docusign down 37%, Adobe down 38%, Atlassian
| down 41%, Asana down 41%, Monday.com down 44%, Hubspot down
| 49%. Eventbrite being bought for pennies.
|
| They are being replaced by newer, smaller, cheaper, sometimes
| internal solutions.
| BobbyJo wrote:
| Stock prices down or revenue down? The former would do very
| little to support your point.
| hagbarth wrote:
| Revenue is all up. And as far as I can see beating
| expectations.
| xnx wrote:
| > Had the cost of building custom software dropped 90%
|
| It definitely has for me. I'm creating toolS and utilities
| every week easily that I never would've attempted in the past.
|
| > This is as if writing down the code is not the biggest
| problem, or the biggest time sink, of building software.
|
| Lots of people can think logically and organize a process flow,
| but don't know all the ridiculous code incantations (and worse
| development and hosting environment details) to turn their
| plans into tools.
|
| It's trivial to one-shot all kinds of impressive toys in Gemini
| now, but it's going to be an even bigger deal when Google adds
| some type of persistent data storage. It will be like the
| rebirth of a fully modern Microsoft Access.
| kenjackson wrote:
| It has dropped by maybe MORE than 90%. My sons school recently
| asked me to build some tools for them -- I did this over a
| decade ago for them, for free. I did it again using AI tools
| (different problem though) and I had it mostly done in 30
| minutes (after I got the credentials set up properly -- that
| took up more time than the main coding part). This was probably
| several days of work for me in the past.
| TheRoque wrote:
| But in the past, you knew the codebase very well, and it was
| trivial to implement a fix and upgrade the software. Can the
| same be done with LLMs ? Well from what I see, it depends on
| your luck. But if the LLMs can't help you, then you gotta
| read the whole codebase that you've never read before and you
| quickly lose the initial benefits. I don't doubt someday
| we'll get there though.
| emodendroket wrote:
| They're better than one might expect at diagnosing issues
| from the error output or even just screenshots.
| kenjackson wrote:
| I've hit this in little bursts, but one thing I've found is
| that LLMs are really good at reasoning about their own code
| and helping me understand how to diagnose and make fixes.
|
| I recently found some assembly source for some old C64
| games and used an LLM to walk me through it (purely
| recreational). It was so good at it. If I was teaching a
| software engineering class, I'd have students use LLMs to
| do analysis of large code bases. One of the things we did
| in grad school was to go through gcc and contribute
| something to it. Man, that code was so complex and
| compilers are one of my specialties (at the time). I think
| having an LLM with me would have made the task 100x easier.
| devin wrote:
| Does that mean you don't think you learned anything
| valuable through the experience of working through this
| complexity yourself?
|
| I'm not advocating for everyone to do all of their math
| on paper or something, but when I look back on the times
| I learned the most, it involved a level of focus and
| dedication that LLMs simply do not require. In fact, I
| think their default settings may unfortunately lead you
| toward shallow patterns of thought.
| jazzyjackson wrote:
| If I haven't looked at my own code in 6 months it might as
| well have been written by someone else.
| kenjackson wrote:
| The most brilliant programmer I know is me three years
| ago. I look at code I wrote and I'm literally wondering
| "how did I figure out how to do that -- that makes no
| sense, but exactly what is needed!"
| bloppe wrote:
| "Building software" is a bit too general, though. I believe
| "Building little web apps for my son's school" has gotten at
| least 10x easier. But the needle has not moved much on
| building something like Notion, or Superhuman, or Vercel, or
| <insert name of any non-trivial project with more than 1000
| man-hours of dev work>.
|
| Even with perfect prompt engineering, context rot catches up
| to you eventually. Maybe a fundamental architecture
| breakthrough will change this, but I'm not holding my breath.
| codegeek wrote:
| The keyword is "building". Yes costs may have dropped 90% just
| to build software. But there are 1000 other things that comes
| after it to run a successful software for months let alone
| years.
|
| - Maintenance, Security
|
| - Upgrades and patches
|
| - Hosting and ability to maintain uptime with traffic
|
| - Support and dealing with customer complexities
|
| - New requirements/features
|
| - Most importantly, ability to blame someone else (at least for
| management). Politics plays a part. If you build a tool in-
| house and it fails, you are on the chopping block. If you buy,
| you at least can say "Hey everyone else bought it too and I
| shouldn't be fired for that".
|
| Customers pay for all of the above when they buy a SAAS
| subscription. AI may come for most of the above at some point
| but not yet. I say give it 3-5 years to see how it all pans
| out.
| socketcluster wrote:
| Good point but this is missing the most critical thing that
| AI does not improve; exposure.
|
| The market is now essentially controlled by algorithms. I
| predict there will be amazing software... Which will end up
| ignored by the markets completely until their features are
| copied by big tech and nobody will know where the idea
| originated.
|
| Building is absolutely worthless in the context of a
| monopolized marketplace.
| klntsky wrote:
| People vibe one-off solutions for themselves all the time. They
| just don't have the desire to productionalize them. Frankly,
| product knowledge is something LLMs are not that good at
| jayd16 wrote:
| I mean, we have had the tech to crank out some little app for a
| long time. The point of the Saas used to be that you had a neck
| to strangle when things went south. I guess these days that's
| just impossible anyhow and the prices aren't worth it so we're
| rediscovering that software can be made instead of bought?
|
| There have been a lot of little blogs about "home cooking"
| style apps that you make for yourself. Maybe AI is the
| microwave meal version.
| phantasmish wrote:
| Something weird happened to software after the 90s or so.
|
| You had all these small-by-modern-standards teams (though
| sometimes in large companies) putting out desktop applications,
| sometimes on multiple platforms, with shitloads of features. On
| fairly tight schedules. To address markets that are itty-bitty
| by modern standards.
|
| Now people are like "We'll need (3x the personnel) and (2x the
| time) and you can forget about native, it's webshit or else you
| can double those figures... for one platform. What's that? Your
| TAM is only (the size of the entire home PC market circa 1995)?
| Oh forget about it then, you'll never get funded"
|
| It _seems like_ we've gotten far _less_ efficient.
|
| I'm skeptical this problem has to do with code-writing, and so
| am skeptical that LLMs are going to even get us back to our
| former baseline.
| mattgreenrocks wrote:
| Yep. Software construction was branded a team sport. Hence,
| social coding, tool quality being considered more important
| (good thing for sure), and, arguably, less emphasis on
| individual skill and agency.
|
| This was in service of a time when tech was the great
| equalizer, powered by ZIRP. It also dovetailed perfectly with
| middle managers needing more reports in fast growing tech
| companies. Perhaps the pendulum is swinging back from the
| overly collective focus we had during the 2010s.
| zahlman wrote:
| > Had the cost of building custom software dropped 90%, we
| would be seeing a flurry of low-cost, decent-quality SaaS
| offering all over the marketplace, possibly undercutting some
| established players.
|
| Don't forget the second-order effect of clients deciding they
| could do it in-house.
| PaulHoule wrote:
| In fact that is where AI could win. An in house system only
| needs to serve the needs of one customer whereas the SAAS has
| to be built for the imagined needs of many customers --- when
| you're lucky you can "build one to throw away" and not throw
| it away.
| socketcluster wrote:
| This is assuming the marketplace works perfectly... Which is an
| incorrect assumption. Reality is that the marketplace is highly
| controlled by algorithms. New platforms will struggle to get
| exposure... No exposure, no credibility, no word of mouth, no
| users, catch 22... You think the big players will allow small
| SaaS projects to gain traction on their platforms? Have you see
| how centralized the Internet is these days?
|
| My bet is if there were a lot of great apps being built, even
| excellent quality, nobody would even hear about them. The big
| players would copy them before anyone even found out about
| them.
| bdavid21wnec wrote:
| I keep seeing articles like these popup. I am in the industry but
| not in the "AI" industry. What I have no concept of, is the
| current subsidized, VC funded, anywhere close to what the final
| product will be? I always fall back to the Uber paradox. Yes it
| was great at first, now it's 3x what it cost and has only given
| cabs pricing power. This was good for consumers to start but now
| it's just another part of the k shaped economy. So is that
| ultimately where AI goes? Top percent can afford a high monthly
| subscription and the not so fortunate get there free 5 minutes
| per month
| martinald wrote:
| But even if that did happen, the open source models are
| excellent and cost virtually nothing?
|
| Like I prefer Opus 4.5 and Gemini 3 to the open weights models,
| but if Anthropic or Google upped the pricing 10x then everyone
| would switch to the open weights models.
|
| Arguably you could say that the Chinese labs may stop releasing
| them, true, but even if all model development stopped today
| then they'd still be extremely useful and a decent competitor.
| bdavid21wnec wrote:
| Again I'm not in the "AI" industry so I don't fully
| understand the economics and don't run open models locally.
|
| What's the cost to run this stuff locally, what type of
| hardware is required. When you say virtually nothing, do you
| mean that's because you already have a 2k laptop or gpu?
|
| Again I am only asking because I don't know. Would these
| local models run OK on my 2016 Mac Pro intel or do I need to
| upgrade to the latest M4 chip with 32GB memory for it to work
| correctly?
| criemen wrote:
| The large open-weights models aren't really usable for
| local running (even with current hardware), but multiple
| providers compete on running inference for you, so it's
| reasonable to assume that there is and will be a
| functioning marketplace.
| e10jc wrote:
| I totally agree with you. I am working on a new platform right
| now for a niche industry. Maybe theres $10m ARR to make total in
| the industry. Last year, it wouldn't be worth the effort to
| raise, hire a PM, a few devs, QA, etc. But for a solo dev like
| myself with AI, it definitely is worth it now.
| jdmoreira wrote:
| I must be holding wrong then because I do use Claude Code all the
| time and I do think its quite impressive... still I cant see
| where the productivity gains go nor am I even sure they exist
| (they might, I just cant tell for sure!)
| hurturue wrote:
| if you back and forth with the model, and discuss/approve every
| change it does, that's the problem.
|
| you need to give it a bigish thing so it can work 15 min on it.
| and in those 15 min you prepare the next one(s)
| jdmoreira wrote:
| Sure. But am I supposed to still understand that code at some
| point? Am I supposed to ask other team members to review and
| approve that code as if I had written it?
|
| I'm still trying to ship quality work by the same standards I
| had 3 or 5 years ago.
| azov wrote:
| If the cost of building software dropped so much - where is that
| software?..
|
| Was there an explosion of useful features in any software product
| you use? A jump in quality? Anything tangible an end user can
| see?..
| atmavatar wrote:
| > Has the cost of building software just dropped 90%?
|
| I believe Betteridge's law of headlines [1] applies here:
|
| _No._
|
| 1.
| https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
| zackmorris wrote:
| *90% so far..
|
| I've only been working with AI for a couple of months, but IMHO
| it's over. The Internet Age which ran 30 years from roughly
| 1995-2025 has ended and we've entered the AI Age (maybe the last
| age).
|
| I know people with little programming experience who have already
| passed me in productivity, and I've been doing this since the
| 80s. And that trend is only going to accelerate and intensify.
|
| The main point that people are having a hard time seeing,
| probably due to denial, is that once problem solving is solved at
| any level with AI, then it's solved at all levels. We're lost in
| the details of LLMs, NNs, etc, but not seeing the big picture.
| That if AI can work through a todo list, then it can write a todo
| list. It can check if a todo list is done. It can work
| recursively at any level of the problem solving hierarchy and in
| parallel. It can come up with new ideas creatively with stable
| diffusion. It can learn and it can teach. And most importantly,
| it can evolve.
|
| Based on the context I have before me, I predict that at the end
| of 2026 (coinciding with the election) America and probably the
| world will enter a massive recession, likely bigger than the
| Housing Bubble popping. Definitely bigger than the Dot Bomb.
| Where too many bad decisions compounded for too many decades
| converge to throw away most of the quality of life gains that
| humanity has made since WWII, forcing us to start over. I'll just
| call it the Great Dumbpression.
|
| If something like UBI is the eventual goal for humankind, or soft
| versions of that such as democratic socialism, it's on the other
| side of a bottleneck. One where 1000 billionaires and a few
| trillionaires effectively own the world, while everyone else
| scratches out a subsistence income under neofeudalism. One where
| as much food gets thrown away as what the world consumes, and a
| billion people go hungry. One where some people have more than
| they could use in countless lifetimes, including the option to
| cheat death, while everyone else faces their own mortality.
|
| "AI was the answer to Earth's problems" could be the opening line
| of a novel. But I've heard this story too many times. In those
| stories, the next 10 years don't go as planned. Once we enter the
| Singularity and the rate of technological progress goes
| exponential, it becomes impossible to predict the future. Meaning
| that a lot of fringe and unthinkable timelines become highly
| likely. It's basically the Great Filter in the Drake equation and
| Fermi paradox.
|
| This is a little hard for me to come to terms with after a
| lifetime of little or no progress in the areas of tech that I
| care about. I remember in the late 90s when people were talking
| about AI and couldn't find a use for it, so it had no funding.
| The best they could come up with was predicting the stock market,
| auditing, genetics, stuff like that. Who knew that AI would take
| off because of self-help, adult material and parody? But I guess
| we should have known. Every other form of information technology
| followed those trends.
|
| Because of that lack of real tech as labor-saving devices to help
| us get real work done, there's been an explosion of phantom tech
| that increases our burden through distraction and makes our
| work/life balance even less healthy as underemployment. This is
| why AI will inevitably be recruited to demand an increase in
| productivity from us for the same income, not decrease our share
| of the workload.
|
| What keeps me going is that I've always been wrong about the
| future. Maybe one of those timelines sees a great democratization
| of tech, where even the poorest people have access to free
| problem solving tech that allows them to build assistants that
| increase their leverage enough to escape poverty without money.
| In effect making (late-stage) capitalism irrelevent.
|
| If the rate of increasing equity is faster than the rate of
| increasing excess, then we have a small window of time to catch
| up before we enter a Long Now of suffering, where wealth
| inequality approaches an asymptote making life performative,
| pageantry for the masses who must please an emperor with no
| clothes.
|
| In a recent interview with Mel Robbins in episode 715 of Real
| Time, Bill Maher said "my book would be called: It's Not Gonna Be
| That" about the future not being what we think it is. I can't
| find a video, but he describes it starting around the 19:00 mark:
|
| https://podcasts.musixmatch.com/podcast/real-time-with-bill-...
|
| Our best hope for the future is that we're wrong about it.
| keybored wrote:
| It's over. I've been writing FUD manually since the 60's. But
| people fresh out of FB troll boot camp are already rolling it
| out 99% faster than me.
| SoftTalker wrote:
| Where are the billions of dollars spent on GPUs and new data
| centers accounted for in this estimation?
| bdavid21wnec wrote:
| Ya completely agree, these companies will eventually push these
| costs to the consumer, might be in 1-2yrs, but it will
| eventually happen and though regulatory capture make it harder
| and harder to run local AI models because of "security"
| reasons.
| tschellenbach wrote:
| It depends. For AI to work for large projects (did a post on this
| forever ago in AI terms. https://getstream.io/blog/cursor-ai-
| large-projects/)
|
| But you need: a staff level engineer to guide it, great
| standardization and testing best practices. And yes in that
| situation you can go 10-50x faster. Many teams/products are not
| in that environment though.
| andybak wrote:
| I work on a big ball of open source spaghetti and AI has become
| invaluable in helping me navigate my way through it. Even when
| it's wrong - it gives me valuable clues.
| Agingcoder wrote:
| > One objection I hear a lot is that LLMs are only good at
| greenfield projects. I'd push back hard on this. I've spent
| plenty of time trying to understand 3-year-old+ codebases where
| everyone who wrote it has left.
|
| Where I am, 3 year old is greenfield, and old and large is 20
| years old and has 8million lines of nasty c++. I'll have to wait
| a bit more I think ...
| devnull3 wrote:
| I think the cost of prototyping has definitely gone down.
|
| Developing production grade software which you want to people to
| rely on and pay for it is not gone down so much. The "weak" link
| is still human.
|
| Debugging complex production issues needs intimate knowledge of
| the code. Not gonna happen in next 3-4 years atleast.
| vb-8448 wrote:
| It's not just about "building" ... who is going to maintain all
| this new sub-par code pushed to production every day?
|
| Who is going to patch all bugs, edge cases and security
| vulnerabilities?
| soco wrote:
| The theory goes very simple, you tell the agent to patch the
| bug. Now the practice though...
| fullstackwife wrote:
| yeah, in practice: would you like to onboard a Boeing 747
| where some of the bugs were patched by some agents,
|
| what is the percentage risk of malfunction you are going to
| accept as a passenger?
| emodendroket wrote:
| No. But most software products are nowhere near that
| sensitive and very few of them are developed with the level
| of caution and rigor appropriate for a safety-critical
| component.
| TuringNYC wrote:
| >> yeah, in practice: would you like to onboard a Boeing
| 747 where some of the bugs were patched by some agents,
|
| In this case, the traditional human process hasn't gone
| well either.
| dboreham wrote:
| The bugs were mostly caused by MBAs, who one assumes will
| remain.
| geon wrote:
| It is working great as long as it is adhered to and
| budgeted.
| fullstackwife wrote:
| human process is the understanding that the mistakes will
| make people die
| Havoc wrote:
| You are a senior expert. SENIOR EXPERT :D
|
| [0] https://www.youtube.com/shorts/64TNGvCoegE
| sdoering wrote:
| I happily got rid of a legacy application (lost the pitch,
| another agency now must deal with the shit) I inherited as a
| somewhat technically savvy person about a year ago.
|
| It was built by real people. Not a single line of AI slop in
| it. It was the most fragile crap I had ever the misfortune to
| witness. Even in my wildest vibe coding a prototype moments I
| was not able to get the AI to produce that amount of anti
| patterns, bad shit and code that would have had Hitchcock
| running.
|
| I think we would be shocked to see what kind of human slop out
| there is running in production. The scale might change, but at
| least in this example, if I had rebuilt the app purely by vibe
| coding the code quality and the security of the code would
| actually have improved. Even with the lowest vibe coding effort
| thinkable.
|
| I am not in any way condoning (is this the right word) bad
| practices, or shipping vibe code into prod without very, very
| thorough review. Far from it. I am just trying to provide a
| counter point to the narrative, that at least in the medium
| sized business I got to know in my time consulting/working in
| agencies, I have seen quite a metric ton of slop, that would
| make coding agents shiver.
| geon wrote:
| The argument isn't that all slop is AI, but that all AI is
| slop.
| baq wrote:
| Turns out building enterprise software has more in common
| with generating slop than not.
| vb-8448 wrote:
| AI doesn't overcome the limits of the one who is giving the
| input, like in pre-ai era SW, if the input sucks the output
| sucks.
|
| What changed is the speed: AI and vibe coding just gave a
| turboboost to all you described. The amount of code will go
| parabolic (maybe it's already parabolic) and, in the mid-
| term, we will need even more swe/sre/devops/security/ecc to
| keep up.
| neom wrote:
| DigitalOcean version 1 was a duck taped together mash of
| bash, chron jobs and perl, 2 people out of 12 understood it,
| 1 knew how to operate it. It worked, but it was insane, like
| really, really insane. 0% chance the original chatgpt would
| have written something as bad as DO v1.
| mountainriver wrote:
| I hear this argument all the time but it seems to leave out
| code reviews
| sublinear wrote:
| Perhaps the cost will drop over time, but it will be because
| writing code is becoming more accessible. It's not just because
| of AI, but the natural progress of education and literacy on the
| topic that would have happened anyway.
|
| What I see are salaries stagnating and opportunity for new niche
| roles or roles being redefined to have more technical
| responsibility. Is this not the future we all expected before AI
| hype anyway? People need to relax and refocus on what matters.
| cloogshicer wrote:
| > I've had Claude Code write an entire unit/integration test
| suite in a few hours (300+ tests)
|
| I'd love to see someone do this, or a similar task, live on
| stream. I always feel like an idiot when I read things like this
| because despite using Claude Code a lot I've _never_ been able to
| get anything of that magnitude out of it that wasn 't
| slop/completely unusable, to the point where I started to
| question if I hadn't been faster writing everything by hand.
|
| Claiming that software is now 90% cheaper feels absurd to me and
| I'd love to understand better where this completely different
| worldview comes from. Am I using the tools incorrectly? Different
| domains/languages/ecosystems?
| nonameiguess wrote:
| I don't really build software any more and have moved into other
| parts of the business. But I'm still a huge user of software and
| I'd just echo all the other comments asking if it's so easy to
| get all these great tools built and shipped, where are they? I
| can see that YouTube is flooded with auto-generated content. I
| can see that blogspam has skyrocketed beyond belief. I can see
| that the number of phishing texts and voicemails I get every day
| has gone through the roof. I don't see any flood of new CNCF
| incubating projects. I don't see that holy grail entire OS
| comparable to Linux but written in Rust. I don't see the other
| holy grail new web browser that can compete with Firefox, Chrome,
| and Safari. It's possible people are shipping more of the
| stripped down Jira clones designed for a team of ten that gets 60
| customers and stops receiving updates after 2 years but that's
| not the kind of software that would be visible to me.
|
| If you're replacing spreadsheets with a single-purpose web UI
| with proper access control and concurrent editing that doesn't
| need Sharepoint or Google Workspaces, fine, but if you're telling
| me that's going to revolutionize the entire industry and economy
| and justify trillions of dollars in new data centers, I don't
| think so. I think you need to actually compete with Sharepoint
| and Google Workspaces. Supposedly, Google and Microsoft claim to
| be using LLMs internally more than ever, but they're publicly
| traded companies. If it's having some huge impact, surely we'll
| see their margins skyrocket when they have no more labor costs,
| right?
| Normal_gaussian wrote:
| > I've had Claude Code write an entire unit/integration test
| suite in a few hours (300+ tests) for a fairly complex internal
| tool. This would take me, or many developers I know and respect,
| days to write by hand.
|
| I'm not sure about this. The tests I've gotten out in a few hours
| are the kind I'd approve if another dev sent then but haven't
| really ended up finding meaningful issues.
| kace91 wrote:
| Have you noticed how it's never "I got this awesome code!"?
| It's always "I got good code, trust me".
|
| People say their prompts are good, awesome code is being
| generated, it solved a month's worth of work in a minute.
| Nobody comes with receipts.
| dboreham wrote:
| I keep seeing posts like this so I decided to video record
| all my LLM coding sessions and post them on YouTube. Early
| days, I only had the idea on Saturday.
| Aeolun wrote:
| I find I get better tests if I use agents to generate tests.
| martinald wrote:
| Just to be clear, they weren't stupid 'is 1+1=2' type tests.
|
| I had the agent scan the UX of the app being built, find all
| the common flows and save them to a markdown file.
|
| I then asked the agent to find edge cases for them and come up
| with tests for those scenarios. I then set off parallel
| subagents to develop the the test suite.
|
| It found some really interesting edge cases running them - so
| even if they never failed again there is value there.
|
| I do realise in hindsight it makes it sound like the tests were
| just a load of nonsense. I was blown away with how well Claude
| Code + Opus 4.5 + 6 parallel subagents handled this.
| blauditore wrote:
| These kind of future prediction posts keep coming, and I'm tired
| of them. Reality is always more boring, less extreme, and slower
| at changing, because there are too many factors involved, and the
| authors never account for everything.
|
| Maybe we should collect all of these predictions, then go back in
| 5-10 years and see if anyone was actually right.
| bitwize wrote:
| Maybe I'm holding it wrong, but I don't _actually_ see the huge
| productivity gains from LLM-assisted software development. Work
| is leaning on us to use AI--not requiring it yet, but we 're at
| DEFCON 3, borderline 2 (DEFCON 1 being a Shopify situation). My
| team's experience is that it needs LOTS of handholding and manual
| fixing to produce even something basic that's remotely fit for
| production use.
|
| I closed a comment from ~2.5y ago
| (https://news.ycombinator.com/item?id=36594800) with this
| sentence: "I'm not sure that incorporating LLMs into programming
| is (yet) not just an infinite generator of messes for humans to
| clean up." My experience with it is convincing me that that's
| just what it is. When the bills come due, the VC money dries up,
| and the AI providers start jacking up their prices... there's
| probably going to be a boom market for humans to clean up AI
| messes.
| rmnclmnt wrote:
| Can we also take into account the mental cost associates with
| building software? Because how I see it, managing output from
| agents is way more exhausting than doing it ourself.
|
| And obviously the cost of not upskilling in intricate technical
| details as much as before (aka staying at the high level
| perspective) will have to be paid at some point
| MangoToupe wrote:
| No. Not unless your business wasn't competitive to begin with
| dclnbrght wrote:
| Domain knowledge is the moat, we need to rethink career planning
| https://news.ycombinator.com/item?id=46197349
| criemen wrote:
| > This takes a fairly large mindset shift, but the hard work is
| the conceptual thinking, not the typing.
|
| But the hard work always was the conceptual thinking? At least at
| and beyond the Senior level, for me it was always the thinking
| that's the hard work, not converting the thoughts into code.
| liampulles wrote:
| I contracted briefly on a post-LLM-boom Excel modernization
| project (which ended up being consulting mainly, because I had to
| spend all my time explaining key considerations for a long-
| running software project that would fit their domain).
|
| The company had already tried to push 2 poor data analysts who
| kind of new Python into the role of vibe coding a Python desktop
| application that they would then distribute to users. In the best
| case scenario, these people would have vibe coded an application
| where the state was held in the UI, with no concept of
| architectural seperation and no prospects of understanding what
| the code was doing a couple months from inception (except through
| the lens of AI sycophancy), all packaged as a desktop application
| which would generate excel spreadsheets that they would then send
| to each other via Email (for some reason, this is what they
| wanted - probably because it is what they know).
|
| You can't blame the business for this, because there are no
| technical people in these orgs. They were very smart people in
| this case, doing high-end consultancy work themselves, but they
| are not technical. If I tried to do vibe chemistry, I'm sure it
| would be equally disastrous.
|
| The only thing vibe coding unlocks for these orgs by themselves
| is to run headfirst into an application which does horrendous
| things with customer data. It doesn't free up time for me as the
| experienced dev to bring the cost down, because again, there is
| so much work needed to bring these orgs to the point where they
| can actually run and own an internal piece of software that I'm
| not doing much coding anyway.
| henning wrote:
| By making up numbers and not supplying any evidence, you can come
| to any conclusion you like! Then you get to draw a graph with no
| units on it. Finally, you can say things that are objectively
| false like "These assertions are rapidly becoming completely
| false".
| bob1029 wrote:
| In context of B2B SaaS products that require a high degree of
| customization per client, I think there could be an argument for
| this figure.
|
| The biggest bottleneck I have seen is converting the requirements
| into code fast enough to prove to the customer that they didn't
| give us the right/sufficient requirements. Up until recently, you
| had to avoid spending time on code if you thought the
| requirements were bad. Throwing away 2+ weeks of work on
| ambiguity is a terrible time.
|
| Today, you could hypothetically get lucky on a single prompt and
| be ~99% of the way there in one shot. Even if that other 1% sucks
| to clean up, imagine if it was enough to get the final polished
| requirements out of the customer. You could crap out an 80%
| prototype in the time it takes you to complete one daily standup
| call. Is the fact that it's only 80% there bad? I don't think so
| in this context. Handing a customer something that almost works
| is much more productive than fucking around with design documents
| and ensuring requirements are perfectly polished to developer
| preferences. A slightly wrong thing gets you the exact answer a
| lot faster than nothing at all.
| sharpy wrote:
| I think AI can be really powerful tool. I am more productive with
| it than not, but a lot of my time interacting with AI is
| reviewing its code, finding problems with it (I always find some
| issues with it), and telling it what to do differently multiple
| times, and eventually giving up, and fixing up the code by hand.
| But it definitely has reduced average time it takes me to
| implement features. But I also worry that not everyone would be
| responsible and check/fix AI generated code.
| CobrastanJorji wrote:
| Man, that's a big title. I can't wait to see the data on how the
| cost has dropped so far.
|
| > AI Agents however in my mind massively reduce...
|
| Nevermind. It's a vibe 90%.
| marcosdumay wrote:
| That. I was expecting some overview of the last couple of
| decades in a "There's no Silver Bullet" fashion.
|
| Instead it's some guy that claims it takes a team to make CI/CD
| for something he can vibe-code in a day, and that agentic code
| totally solves the complexity problems caused by too much
| React.
| mlhpdx wrote:
| If software actually is 90% cheaper to build in 2026 there will
| be 10x the simple apps and abandonware to follow. Throwaway
| software like throwaway phones. It'll be weird.
| krupan wrote:
| I love how LLMs have made everyone forget how hard it is to
| verify software correctness and how hard it is to maintain
| existing software. There is endless gushing about how quickly
| LLMs can write code. Whenever I point out the LLMs make a lot of
| mistakes people just wave their hands and say software is easy to
| validate. The huge QA departments at all software shops would beg
| to disagree, along with the CVE database, the zero day brokers,
| etc. But you know, whatever, they're just boomers right?
| simonw wrote:
| The cost of writing _simple_ code has dropped 90%.
|
| If you can reduce a problem to a point where it can be solved by
| simple code you can get the rest of the solution very quickly.
|
| Reducing a problem to a point where it can be solved with simple
| code takes a lot of skill and experience and is generally still
| quite a time-consuming process.
| mountainriver wrote:
| I've found they are able to compose well, let it build small
| components and stitch them together
| loandbehold wrote:
| Most of software work is maintaining "legacy" code, that is
| older systems that have been around for a long time and get a
| lot of use. I find Claude Code in particular is great at
| grokking old code bases and making changes to it. I work on one
| of those old code bases and my productivity increased 10x
| mostly due to Claude Code's ability to research large code
| bases, make sense of it, answer questions and making careful
| surgical changes to it. It also helps testing code which is
| huge productivity boost. It's not about it's ability to churn
| out lots of code quickly: it's an extra set of eyes/brain that
| works much faster that human developer.
| gcanyon wrote:
| > The cost of writing _simple_ code has dropped 90%.
|
| Need to add, "...and what 'simple' means is getting broader by
| the day."
| dzonga wrote:
| pretty decent article - but what it misses is most of these
| agents are trained on bad code - which is open source.
|
| so what does this mean in practice? for people working on
| proprietary systems (cost will never go down) - the code is not
| on github, maybe hosted on an internal VCS - bitbucket etc. the
| agents were never trained on that code - yeah they might help
| with docs (but are they using the latest docs?)
|
| for others - the agents spit bad code, make assumptions that
| don't exist, call api's that don't exist or have been deprecated
| ?
|
| each of those you need an experienced builder who has 1.
| technical know-how 2. domain expertise ? so has the cost of
| experienced builder(s) gone down ? I don't think so - I think it
| has gone up
|
| what people are vibecoding out there - is mostly tools / apps
| that deal in closed systems (never really interact with the
| outside world), scripts were ai can infer based on what was done
| before etc but are these people building anything new ?
|
| I have also noticed there's a huge conflation with regards to -
| cost & complexity. zirp drove people to build software on very
| complex abstractions eg kubernetes, nextjs, microservices etc -
| hence people thought they needed huge armies of people etc.
| however we also know the inverse is true that most software can
| be built by teams of 1-3 people. we have countless proof of this.
|
| so people think to reduce cost is to use a.i agents instead of
| addressing the problem head-on - built software in a simpler
| manner. will ai help - yeah but not to the extent of what is
| being sold or written daily.
| simonw wrote:
| The idea that LLMs were trained on miscellaneous scraped low
| quality code may have been true a year ago, but I suspect it is
| no longer true today
|
| All of the major model vendors are competing on how well their
| models can code. The key to getting better code out of the
| model is improving the quality of the code that it is trained
| on.
|
| Filtering training data for high quality code is easier than
| filtering for high quality data if other types.
|
| My strong hunch is that the quality of code being used to train
| current frontier models is way higher than it was a year ago.
| Tepix wrote:
| > these agents are trained on bad code - which is open source.
|
| This is doubtful and not what I've seen in over 30 years in the
| industry. People who are ashamed of their source code don't
| make it Open Source. In general, Open Source will be higher
| quality than closed source.
|
| Sure, these days you will need to avoid github repositories
| made by students for their homework assignments. I don't think
| that's a problem.
| samlinnfer wrote:
| The cost of writing software had dropped by 90% since outsourcing
| was invented and all the software jobs have moved to India was I
| was told 15 years ago.
| lisbbb wrote:
| This article was more of an advertisement for...something than
| any meaningful commentary.
|
| How good are tests written by AI, really? The junk "coverage"
| unit tests sure, but well thought out integration tests? No way.
| Testing code is difficult, some AI slop isn't going to make that
| easier because someone has to know the code and the
| infrastructure it is going in to and reason about all of it.
| xdc0 wrote:
| Betteridge's law proven correct once again. The answer to the
| headline is: no. Perhaps it will be true in the future, nobody
| knows.
|
| I'm skeptical the extent to which people publishing articles like
| this use AI to build non-trivial software, and by non-trivial I
| mean _imperfect_ codebases that have existed for a few years,
| battle tested, with scars from hotfixes to deal with fires and
| compromises to handle weird edge cases/workarounds and especially
| a codebase where many developers have contributed to it over
| time.
|
| Just this morning I was using Gemini 3 Pro working on some
| trivial feature, I asked it about how to go about solving an
| issue and it completely hallucinated a solution suggesting to use
| a non-existing function that was supposedly exposed by a library.
| This situation has been the norm in my experience for years now
| and, while this has improved over time, it's still very, very
| common occurrence. If it can't get these use cases down to an
| acceptable successful degree, I just don't see how much I can
| trust it to take the reins and do it all with an agentic
| approach.
|
| And this is just a pure usability perspective. If we consider the
| economics aspect, none of the AI services are profitable, they
| are all heavily subsidized by investor cash. Is it sustainable
| long term? Today it seems as if there is an infinite amount of
| cash but my bet is that this will give in before the cost of
| building software drops by 90%.
| CobrastanJorji wrote:
| I love the hand drawn chart. Apparently "Open Source" was
| invented around 2005, which significantly reduced development
| cost, then AWS was invented in 2011 or so and made development
| even cheaper, but then, oh no, in 2018 "complexity" happened and
| development became harder!
| zqna wrote:
| In 2018 We had kubernetes, which improved the development speed
| another 300%!
| jcelerier wrote:
| I don't read this as when open-source was invented, but when it
| _happened_ for the corporate world. In 2002 it was a very
| reasonable choice for $BIG_COMPANY to use a proprietary web
| server, e.g. IIS. In 2008 that would have been really be weird.
| alex-ross wrote:
| The cost of building "something" has dropped 90%. The cost of
| building "something good" has maybe dropped 30%.
|
| The gap between a demo and a product is still enormous.
| rudedogg wrote:
| The author teaches AI workshops. Nothing wrong with that, but I
| think it should be disclosed here. A lot of money is riding on
| LLMs being financially successful which explains a lot of the
| hype.
| hoppp wrote:
| The cost of training agents is in the billions so Im not sure the
| cost dropped, it just shifted and now the cost distribution is
| different
| hjaveed wrote:
| the cost of creating a great product and amount of time it takes
| to get infront of the customers has still not reduced
| codyb wrote:
| Writing a giant unit test suite being the primary example that
| stuck out to me from that article really doesn't give a lot of
| credence to the question?
|
| And yet, the conclusion seems to be as if the answer is yes?
|
| Until AI can work organizationally as opposed to individually
| it'll necessarily be restricted in its abilities to produce gains
| beyond relatively marginal improvements (Saved 20 hours of
| developer time on unit tests) for a project that took X
| weeks/months/years to work it's way through Y number of people.
|
| So sure, simple projects, simple asks, unit tests, projects
| handled by small teams of close knit coworkers who know the
| system in and out and already have the experience to
| differentiate between good code and bad? I could see that being
| reduced by 90%.
|
| But, it doesn't seem to have done much for organizational
| efficiency here at BigCo and unit tests are pretty much the very
| tip of a project's iceberg here. I know a lot of people are using
| the AI agents, and I know a lot of people who aren't, and I worry
| for the younger engineers who I'm not sure have the chops to
| distinguish between good, bad, and irrelevant and thus leave in
| clearly extraneous code, and paragraphs in their documents. And
| as for the senior engineers with the chops, they seem to do okay
| with it although I can certainly tell you they're not doing ten
| times more than they were four years ago.
___________________________________________________________________
(page generated 2025-12-08 23:00 UTC)