[HN Gopher] The rise of industrial software
___________________________________________________________________
The rise of industrial software
Author : chrisloy
Score : 198 points
Date : 2025-12-31 09:09 UTC (13 hours ago)
(HTM) web link (chrisloy.dev)
(TXT) w3m dump (chrisloy.dev)
| memoriuaysj wrote:
| Steve Yegge called it "factory farmed code"
| moffkalast wrote:
| Those GPUs live in horrible conditions, they pack so many in a
| rack they can't even move and they barely get enough cooling to
| survive. Abominable /s
| memoriuaysj wrote:
| https://www.reddit.com/media?url=https%3A%2F%2Fi.redd.it%2Fr.
| ..
| philipallstar wrote:
| These damn articles. Software moved into an industrial revolution
| when you could write in a high level language, and not in
| assembly. This has _already happened_.
| jamesdhutton wrote:
| The article makes this very point. From the article: "software
| has been industrialising for a long time: through reusable
| components (open source code), portability (containerisation,
| the cloud), democratisation (low-code / no-code tools),
| interoperability (API standards, package managers) and many
| other ways"
| baq wrote:
| You either see what codex and opus are capable of and
| extrapolate the trendline or you don't; the author clearly saw
| and extrapolated.
|
| Not that I disagree: I'm on record agreeing with the article
| months ago. Folks in labs probably seen it coming for years.
|
| Yes we've seen major improvements in software development
| velocity - libraries, OSes, containers, portable bytecodes -
| but I'm afraid we've seen nothing yet. Claude Code and Codex
| are just glimpses into the future.
| ReptileMan wrote:
| And if we extrapolate 5% economic growth per year we will
| consume all the energy in our light cone in 1000 years.
| nchmy wrote:
| Economic growth is not directly proportional to energy
| consumption. A major feature of any useful tool is that it
| (often dramatically) reduces energy consumption.
| ReptileMan wrote:
| Economic growth tracks almost 100% with energy
| consumption. The earth at night map is quite telling on
| the matter.
| nchmy wrote:
| Newsflash! Less happens while people are asleep!
|
| Correlation doesnt say anything about the
| sensitivity/scaling. (i recognize that my original
| comment didnt quite make this point, though the
| correlation is definitely not 100%, so that point does
| still stand)
|
| can you note the difference between the earth being lit
| by torches, candles, kerosene lamps and incandescent
| bulbs, versus LED lights? LED isnt glowing harder, it
| just wastes less energy.
|
| A rocket stove, or any efficient furnace, can extract
| vastly more energy from the same fuel source than an open
| fire. I assume combustion engines have had significant
| efficiency improvements since first introduced. And
| electric engines are almost completely efficient -
| especially when fed by efficient, clean/renewable source.
|
| How about the computing power of a smartphone versus a
| supercomputer from 1980?
|
| What is more energy efficient, a carpenter working with
| crude stones or with sharp chisels?
|
| and we can, of course, put aside whether any measurement
| of economic value is actually accurate/useful... A
| natural disaster is technically good for many economic
| measures, since the destruction doesn't get measured and
| the wealth invested in rebuilding just counts as economic
| activity
|
| And, Of course, then there's creeptocurrencies which use
| an immense amount of energy to do something that was
| previously trivial. And worse, when it is used in place
| of cash. But even there, some are more efficient than
| others - not that anyone who uses them actually cares.
| ReptileMan wrote:
| Facts are that you can absolutely tell how developed a
| region is by looking from above. And that there hasn't
| been a year in which the humanity has used less energy
| than the previous one and grown.
| nchmy wrote:
| Evidently you are not here to communicate in good faith.
| Take care
| K0balt wrote:
| Huh. Your statement was probably hyperbole? But just back
| of the napkin:
|
| If we use about 20 TW today, in a thousand years of 5%
| growth we'd be at about 3x10^34. I think the sun is around
| 3.8x10^26 watts? That gives us about 8x10^7 suns worth of
| energy consumption in 1000 years.
|
| If we figure 0.004 stars per cubic light-year, we end up in
| that ballpark in a thousand years of uniform spherical
| expansion at C.
|
| But that assumes millions ( billions?) of probes traveling
| outward starting soon, and no acceleration or deceleration
| or development time... so I think your claim is likely
| true, in any practical sense of the idea.
|
| Time to short the market lol.
| baq wrote:
| of course, but no need to look that far into the future -
| 400 years at 2.3% pa is enough to boil oceans.
|
| AI capabilities are growing exponentially thanks to
| exponential compute/energy consumption, but also thanks to
| algorithmic improvements. we've got a proof that human-
| level intelligence can run at 20W of power, so we've got
| plenty of room to offset the currently-missing compute.
| elzbardico wrote:
| If we extrapolated the rise in the standards of living of a
| Detroit Black blue-collar factory worker in Detroit from
| the early 60s to our current days, most of them should own
| 64ft yachts by now.
| anthk wrote:
| Portable bytecodes predate Windows and Macintosh, and maybe
| DOS too. (The Z Machine).
| anthk wrote:
| Partially, but no. First:
|
| - Other input that a deck of cards. Terminals and teletypes
| were a revolution.
|
| - Assembly was much better than hardware switches.
|
| - Also, a proper keyboard input against some "monitor" software
| was zillions better than, again, a deck of cards/hardware
| toggles. When you can have a basic line basic editor and dump
| your changes in a paper tape or print your output you have now
| live editing instead of suffering batch jobs.
| bolangi wrote:
| This thought-provoking essay does not consider one crucial aspect
| of software: the cost of a user developing a facility with a
| given software product. Historically monopolistic software
| producers can force these costs to be borne because the user has
| no alternative to upgrading to the latest version of, for
| example, Windows, or gmail, or the latest version of the github
| GUI. A signficant portion of the open source / free software
| movement is software providing stable interfaces (including for
| the user) so that resources otherwise spent on compulsory
| retraining to use the latest version of something proprietary,
| can be invested in configuring existing resources to better suit
| the user's problem domain. For example, programs like mutt or
| vim, or my latest discovery, talon.
| Etheryte wrote:
| I don't think the division line runs on the open-source
| software front here. Windows has historically offered some of
| the most stable APIs, meanwhile there's plenty of examples of
| popular open-source software with a lot of breaking changes.
| xorcist wrote:
| The comment you replied to said "significant portion of" and
| I believe it is clear which portion that refers to: the
| culture around c, linux, vim and bash, not things like
| nodejs, java and (semi-open-source) elasticsearch which are
| culturally separate.
| npunt wrote:
| I've never found a term I liked for this particular concept at
| the intersection of education & business so I made one up a
| while back:
|
| A _Knowledge Pool_ is the reservoir of shared knowledge that a
| group of people have about a particular subject, tool, method,
| etc. In product strategy, knowledge pools represent another
| kind of moat, and a form of leverage that can be used to grow
| or maintain market share.
|
| Usage: Resources are better spent on other things besides
| draining the knowledge pool with yet another new interface to
| learn and spending time and money filling it up again with
| retraining.
| bsenftner wrote:
| The formal term that business people use is "institutional
| knowledge".
| RyanHamilton wrote:
| The term is Institutional knowledge. "An organization's
| collective memory, encompassing the unique expertise,
| experiences, processes, and cultural insights built over time
| by its members, acting as a vital asset that guides
| operations, decision-making, and continuity, often residing
| in seasoned employees' tacit understanding but also in
| documented procedures and data. It includes deep technical
| skills..."
| motbus3 wrote:
| I'm not through yet but I don't know.
|
| As a developer for almost 30 years now, if I think where most of
| my code went, I would say, quantitatively, to the bin.
|
| I processed much data, dumps and logs over the years. I collected
| statistical information, mapped flows, created models of the
| things I needed to understand. And this was long before any "big
| data" thing.
|
| Nothing changed with AI. I keep doing the same things, but maybe
| the output have colours.
| Lumocra wrote:
| That holds true for a tailor, even expensive clothing items
| eventually wear out and get thrown away. They are cared for
| better, repaired a few times, but in the end, disposed of. I'd
| say that analogy holds up for 'traditionally' created software
| vs. AI-created software. Handmade clothes vs. fast fashion.
| samiv wrote:
| Heh...I've worked for 25 years and basically I'm yet to put
| code into production. Mostly projects that were cancelled or
| scrubbed either during development or shortly after or just
| downright never used since they were POC/prototypes.
|
| I think I've overall just had just 2 or 3 projects where anyone
| has actually even tried the thing I've been working on.
| weslleyskah wrote:
| This scares me to death.
|
| This is why you need to find emotional significance for your
| life (traveling, family, art, etc...) outside of this
| claustrophobic work.
| jungturk wrote:
| The code was just created to support some broader goal, which
| it presumably did much of the time. The value of those goals
| is where the meaning comes from.
|
| A chef reflecting on their life would hardly lament that
| every meal they'd ever crafted ended up in the bin (or the
| toilet).
| bgwalter wrote:
| Another AI entrepreneur who writes a long article about
| inevitability, lists some downsides in order to remain credible
| but all in all just uses neurolinguistic programming on the
| reader so that the reader, too, will think the the "AI"
| revolution is inevitable.
| motbus3 wrote:
| Tldr; initially I thought we might be onto something, but now,
| I don't see much of a revolution.
|
| I won't put intention into the text because I did not check any
| other posts from the same guy.
|
| That said, I think this revolution is not revolutionary yet.
| Not sure if it will be, but maybe?
|
| What is happening os that companies are going back to "normal"
| number of people in software development. Before it was because
| of adoption to custom software, later because of labour
| shortage, then we had a boom because people caught up into it
| as a viable career but then it started scaling down again
| because one developer can (technically) do more with AI.
|
| There are huge red flags with "fully automated" software
| development that are not being fixed but for those outside of
| the expertise area, doesn't seem relevant. With newer
| restrictions related to cost and hardware, AI will be even a
| worse option unless there is some sort of magic that fixes
| everything related to how it does code.
|
| The economy (all around the world) is bonkers right now.
| Honestly, I saw some Jr Devs earning 6 fig salaries (in USD)
| and doing less than what me and my friends did when we were Jr.
| There is inflation and all, but the numbers does not seem to
| add.
|
| Part of it all is a re- normalisation but part of it is
| certainly a lack of understanding of software and/or//
| engineering.
|
| Current tools, and I include even those kiro, anti-gravity and
| whatever, do not solve my problems, just make my work faster.
| Easier to look for code, find data and read through blocks of
| code I don't see in a while. Writing code not so much better.
| If it is simple and easy it certainly can do, but for anything
| more complex it seems that it is faster and more reliable to do
| myself (and probably cheaper)
| constantcrying wrote:
| I think the idea is interesting, but immensely flawed.
|
| The following is just disingenuous:
|
| >industrialisation of printing processes led to paperback genre
| fiction
|
| >industrialisation of agriculture led to ultraprocessed junk food
|
| >industrialisation of digital image sensors led to user-generated
| video
|
| Industrialization of printing was the necessary precondition for
| mass literacy and mass education. The industrialization of
| agriculture also ended hunger in all parts of the world which are
| able to practice it and even allows for export of food into
| countries which aren't (Without it most of humanity would still
| be plowing fields in order not to starve). The digital image
| sensor allows for accurate representations of the world around
| us.
|
| The framing here is that industrialization degrades quality and
| makes products into disposable waste. While there is some truth
| to that, I think it is pretty undeniable that there are massive
| benefits which came with it. Mass produced products often are of
| superior quality and superior longevity and often are the only
| way in which certain products can be made available to large
| parts of the population.
|
| >This is not because producers are careless, but because once
| production is cheap enough, junk is what maximises volume,
| margin, and reach.
|
| This just is not true and goes against all available evidence, as
| well as basic economics.
|
| >For example, prior to industrialisation, clothing was largely
| produced by specialised artisans, often coordinated through
| guilds and manual labour, with resources gathered locally, and
| the expertise for creating durable fabrics accumulated over
| years, and frequently passed down in family lines.
| Industrialisation changed that completely, with raw materials
| being shipped intercontinentally, fabrics mass produced in
| factories, clothes assembled by machinery, all leading to today's
| world of fast, disposable, exploitative fashion.
|
| This is just pure fiction. The author is comparing the highest
| quality goods at one point in time, who people took immense care
| of, with the lowest quality stuff people buy today, which is not
| even close to the mean clothing people buy. The truth is that
| fabrics have become far better and far more durable and
| versatile. The products have become better, but what _has_
| changed is the attitude of people towards their clothing.
|
| Lastly, the author is ignoring the basic economics which separate
| software from physical goods. Physical goods need to be produced,
| which is almost always the most expensive part. This is not the
| case for software, distributing software millions of times is not
| expensive and only a minuscule part of the total costs. For
| fabrics industrialization has meant that development costs
| increased immensely, but per unit production costs fell sharply.
| What we are seeing with software is a slashing of development
| costs.
| PaulRobinson wrote:
| I agree with you on all of this, and found myself wondering if
| the author had actually studied the Industrial Revolution at
| all.
|
| The Industrial Revolution created a flywheel: you built
| machines that could build lots of things better and for less
| cost than before, including the parts to make better machines
| that could build things even better and for less cost than
| before, including the parts to make better machines... and on
| and on.
|
| The key part to industrialisation in the 19th-century framing,
| is that you have in-built iterative improvement: by driving
| down cost, you increase demand (the author covers this), which
| _increases investment in driving down costs_ , which increases
| demand, and so on.
|
| Critically, this flywheel has exponential outputs, not linear.
| The author shows Jevons paradox, and the curve is right there -
| note the lack of straight line.
|
| I'm not sure we're seeing this in AI software generation yet.
|
| Costs are shifting in people's minds, from developer salaries
| to spending on tokens, so there's a feeling of cost reduction,
| but that's because a great deal of that seems to be heavily
| subsidised today.
|
| It's also not clear that these AI tools are being used to
| produce exponentially better AI tools - despite the jump we saw
| ~GPT-3.5, quantitive improvement in output seems to remain
| linear as a function of cost, not exponential. Yet investment
| input seems to be exponential (this makes it feel more like a
| bubble).
|
| I'm not saying that industrialisation of the type the author
| refers to isn't possible (and I'd even say most
| industrialisation of software happened back in the 1960s/70s),
| or that the flywheel can't pick up with AI, just that we're not
| quite where they think it is.
|
| I'd also argue it's not a given that we're going to see the
| output of "industrialisation" drive us towards "junk" as a
| natural order of things - if anything we'll know it's not a
| junk bubble when we do in fact see the opposite, which is what
| optimists are betting on being just around the corner.
| huevosabio wrote:
| I've been thinking about this for a while, and largely agree that
| industralization of software development is what we are seeing.
| But the emphasis on low quality is misplaced.
|
| Take this for example:
|
| ``` Industrial systems reliably create economic pressure toward
| excess, low quality goods. ```
|
| Industrial systems allow for low quality goods, but also they
| deliver quality way beyond what can be achieved in artisanal
| production. A mass produced mid-tier car is going to be much
| better than your artisanal car.
|
| Scale allows you not only to produce more cheaply, but also to
| take quality control to the extreme.
| tosapple wrote:
| How does that apply to amish furniture?
| cinntaile wrote:
| Better along which dimensions? Most luxury cars are made the
| artisanal way.
| bluGill wrote:
| That doesn't make them better. It makes them exclusive since
| only a few could have one.
| cinntaile wrote:
| I still don't know what better means in this context, so I
| don't understand what your comment adds to the discussion?
| swiftcoder wrote:
| > but also they deliver quality way beyond what can be achieved
| in artisanal production
|
| I don't think this is true in general, although it may be in
| certain product categories. Hand-built supercars are still
| valued by the ultra-wealthy. Artisanal bakeries consistently
| make better pastries than anything mass produced... and so on
| nchmy wrote:
| Lol, I now see your comment already used the exact same
| examples that my sibling comment did
| nchmy wrote:
| I generally agree. Industrialization puts a decent floor on
| quality, at low cost. But it also has a ceiling.
|
| Perhaps an industrial car is better than _your_ or _my_
| artisanal car, but I 'm sure there's people who build cars by
| hand of very high quality (over the course of years). Likewise
| fine carpentry vs mass produced stuff vs ikea.
|
| Or I make sourdough bread and it would be very
| impractical/uncompetitive to start selling it unless I scaled
| up to make dozens, maybe hundreds, of loaves per day. But it's
| absolutely far better than any bread you can find on any
| supermarket shelf. It's also arguably better than most
| artisanal bakeries who have to follow a production process
| every day.
| pydry wrote:
| The difference between an artisinal car and a mass produced
| car is that the former can only be used by one person.
|
| This has never been true for "artisanal" software. It could
| be used by nobody or by millions. This is why the economic
| model OP proposes falls apart.
| the_sleaze_ wrote:
| Exactly. Breadmaker is only as good as the last loaf.
| Software only needs to be perfect once.
| ciconia wrote:
| Hmm, I'm not sure I see the value in "disposable software". In
| any commercial service people are looking for software solutions
| that are durable, dependable, extensible, maintainable. This is
| the exact opposite of disposable software.
|
| The whole premise of AI bringing democratization to software
| development and letting any layperson produce software signals a
| gross misunderstanding of how software development works and the
| requirements it should fulfill.
| cryptica wrote:
| Yes, software needs to be secure. If we accept the premise that
| software is going to be churned out in bulk, then the
| mechanisms for securing software must evolve rapidly... I don't
| see a world where there is custom software for everything but
| all insecure in different ways.
| swiftcoder wrote:
| Not only secure. It needs to be reliable (don't corrupt my
| data). It needs to be durable (I need to be able to access my
| data 10 years from now). etc.
| cryptica wrote:
| Yes, agreed. producing reliable software is one of these
| things which sounds trivial but is actually extremely
| difficult.
|
| With my last side project, I became frustrated with my non-
| technical founder because he would have a lot of vague
| ideas and in his mind, he was sure that he had a crystal
| clear vision of what he wanted... But it was like, every
| idea he had, I was finding massive logical holes in them
| and finding contradictions... Like he wanted a feature and
| some other feature but it was physically impossible to have
| both without making the UX terrible.
|
| And it wasn't just one time, it was constantly.
|
| He would get upset at me for pointing out the many hurdles
| ahead of time... When in fact he should have been thanking
| me for saving us from ramming our heads into one wall after
| another.
| speeder wrote:
| This only means you didn't interacted enough with IOT or
| junky viral games market...
| alexjurkiewicz wrote:
| I play several sports across several teams and leagues. Each
| league has their own system for delivering fixtures. Each team
| has its own system of communication.
|
| What I want is software that can glue these things together.
| Each week, announce the fixture and poll the team to see who
| will play.
|
| So far, the complete fragmentation of all these markets
| (fixtures, chat) has made software solutions uneconomic. Any
| solution's sales market is necessarily limited to a small
| handful of teams, and will quickly become outdated as fixtures
| move and teams evolve.
|
| I'm hopeful AI will let software solve problems like this,
| where disposable code is exactly what's needed.
| gnz11 wrote:
| That sounds more like a bureaucratic problem (access to data)
| than a software problem.
| empiko wrote:
| Not convinced. There is an obvious value in having more food or
| more products for almost anybody on Earth. I am not sure this is
| the case for software. Most people's needs are completely
| fulfilled with the amount and quality of software they already
| have.
| npodbielski wrote:
| But how about some silly software for just a giggle. Like
| 'write website that plays fart sound when you push button'?
| That can be a thing for the kids at school.
| tossandthrow wrote:
| > There is an obvious value in having more food or more
| products for almost anybody on Earth
|
| Quite the opposite is true. For a large proportion of people,
| they would increase both the amount of years they live and
| quality of life by eating less.
|
| I think the days where more product is always better lapse to
| an end - we just need to figure out how the economy should
| work.
| spiderfarmer wrote:
| "industrialisation of agriculture led to ultraprocessed junk
| food"
|
| The mass production of unprocessed food is not what led to the
| production of hyper processed food. That would be a strange
| market dynamic.
|
| Shareholder pressure, aggressive marketing and engineering for
| super-palatable foods are what led to hyper processed foods.
| fuzzfactor wrote:
| Shelf life is one of the major factors allowing treatment more
| similar to nonperishable commodities.
|
| I think some people do instinctively feel like all different
| kinds of software have different shelf lives or useful
| lifetimes for different reasons.
|
| But there's always so much noise it's not very easy to get the
| expiration date correct.
|
| Mass production is pretty much a given when it comes to
| commodities, and things like long shelf life are icing on the
| cake.
|
| The inversion comes when mass production makes the highly
| processed feed more affordable than the unprocessed. After both
| have scaled maximally, market forces mean more than the amount
| of labor that was put in.
|
| Strange indeed.
| zkmon wrote:
| A question that was not addressed in the article and contrasts
| software with industrialized products from the past is - who are
| the consumers of the software produced at industrial scale?
| Stitching of clothes by machines accelerated garment product only
| because there was demand and consumption tied to population. But
| software is not tied to population similar to food and clothes.
| It doesn't deprecate, it is not exclusively consumed by persons.
|
| Another common misconception is, it is now easier to compete with
| big products, as the cost of building those products will go
| down. Maybe you think you can build your own Office suite and
| compete with MS Office, or build a SAP with better features and
| quality. But what went into these software is not just code, but
| decades of feedback, tuning and fixing. The industrialization of
| software can not provide that.
| tossandthrow wrote:
| > but decades of feedback, tuning and fixing
|
| On the contrary, this is likely the reason why we can disrupt
| these large players.
|
| Experience from 2005 just don't hold that much value in 2025 in
| tech.
| swiftcoder wrote:
| > Experience from 2005 just don't hold that much value in
| 2025 in tech
|
| That would be why a significant portion of the world's
| critical systems still run on Windows XP, eh?
| tossandthrow wrote:
| No, that is likely because there is no economic benefit to
| do anything about it - definitely not UX concerns.
| zkmon wrote:
| Software was never coded in a big-bang one shot fashion. It
| evolves through years of interacting with the field. That
| evolution takes almost same time with AI or not. Remember a
| version release has many tasks that need to go at human
| speed.
| tossandthrow wrote:
| On that we agree.
|
| But taking out features are difficult - even when they have
| near to zero value.
|
| Why it sometimes make sense for new players to enter the
| market and start over - without the legacy.
|
| This is indeed one of the value propositions in the startup
| I work in.
| the_overseer wrote:
| It absolutely does. I cannot believe I am reading this on
| HN... Do you think the idea of a pointer changed? That you
| need locks when accessing variables when doing
| multithreading? That principles like "Be conservative in what
| you send, and liberal in what you accept" have changed? In
| fact, almost nothing changed from 2005 to now in any
| conceptual form.
| tossandthrow wrote:
| The short answer is that these things don't really exist
| anymore for most (business) applications when you stopped
| writing it in C.
|
| So the things you mention indeed is experience you need to
| get rid of as you move to other software stacks and other
| technologies.
| bodegajed wrote:
| code has no use-value. it is like being a baker in an island.
| the value comes from its user base.
| zkmon wrote:
| User base comes from the value you provide. Value comes from
| the product features. Features come from code. If code is
| easy, anyone with 10K bucks in their pocket can provide those
| features and product. The only thing missing is, is the
| product battle-tested? That fortunately remains out of reach
| for AI.
| jeltz wrote:
| I would say unfortunately out of reach since so far it
| seems AI will mostly fill out world with bad code which is
| not battle tested.
| perlgeek wrote:
| > who are the consumers of the software produced at industrial
| scale?
|
| Basically every company that does anything non-trivial could
| benefit from tailor-made software that supports their specific
| workflow. Many small companies don't have that, either they
| cannot afford their own development team, or they don't know
| that/how software could improve their workflow, or they are too
| risk-averse.
|
| Heck, even my small family of 4 persons could benefit from some
| custom software, but only in small ways, so it's not worth it
| for me to pursue it.
|
| Once we're at the point where a (potentially specialized) LLM
| can generate, securely operate and maintain software to run a
| small to medium-sized business, we'll probably find that there
| are far more places that could benefit from custom software.
|
| Usually if you introduce, say, an ERP system into a company
| that doesn't use one yet, you need to customize it _and_ change
| workflows in the company, and maybe even restructure it. If it
| were cheap enough to build a custom ERP system that caters to
| the existing workflows, that would be less disruptive and thus
| less risky.
| hnthrow0287345 wrote:
| >who are the consumers of the software produced at industrial
| scale?
|
| Games have a ton of demand for code that isn't readily
| shareable but also needs to be done quickly.
| ofalkaed wrote:
| Personally I think AI is going to turn software into a cottage
| industry, it will make custom software something the individual
| can afford. AI is a very long ways off from being able to allow
| the average person to create the software they want unless they
| are willing to put a great deal of time into it, but it is almost
| good enough that the programmer can take the average person's
| idea and execute it at an affordable price. Probably only a year
| or two from when a capable programmer will be able to offer any
| small buisness a completely customized POS setup for what the
| cost of a canned industrial offering today; I will design your
| website and build you a POS system tailored to your needs and
| completely integrated with the website, and for a little more I
| can throw in the accounting and tax software. A bright dishwasher
| realizing they can make things work better for their employer
| might be the next billionaire revolutionizing commerce and the
| small buisness.
|
| I have some programming ability and a lot of ideas but would
| happily hire someone to realize those ideas for me. The idea I
| have put the most time into, took me the better part of a year to
| sort out all the details of even with the help of AI, most
| programmers could have probably done it in a night and with AI
| could write the software in a few nights. I would have my
| software for an affordable price and they could stick it in their
| personal store so other could buy it. If I am productive with it
| and show its utility, they will sell more copies of it so they
| have an incentive to work with people like me and help me realize
| my ideas.
|
| Programming is going to become a service instead of an industry,
| the craft of programming will be for sale instead of software.
| elAhmo wrote:
| > and for a little more I can throw in the accounting and tax
| software
|
| As someone who has worked in two companies that raised millions
| of dollars and had hundred people tackling just half of this,
| tax software, you are in for a treat.
| ofalkaed wrote:
| Sure, that is still a ways off, but being able to hire a
| programmer to meet my personal modest software needs is
| almost there. Also, the needs of any company that required a
| hundred people and millions of dollars is very different from
| the needs of a small restaurant or the like; anyone with
| enough ambition to run a small restaurant can manage the
| accounting and taxes for that restaurant, the same can not be
| said for the sort of buisness you are describing. You are
| comparing an apple to an orange orchard.
|
| Edit: Just noticed I said "any buisness", that was supposed
| to be "any small buisness." Edited the original post as well.
| tosapple wrote:
| Business*, if your "tax-accounting" manager made THAT
| mistake with numbers you would be screwed.
| ofalkaed wrote:
| Occasionally when right clicking on a misspelled word to
| correct it, I bump the track pad and accidentally add the
| misspelled word to my dictionary. Business is one of
| those words I apparently did that with. I have never been
| able to figure out how to remove words from my
| dictionary, but honestly never looked that hard, for some
| ridiculous reason I think people will focus on what was
| said instead of looking for nits to pick despite all the
| evidence suggesting otherwise.
| tosapple wrote:
| I considered it may be a dictionary correction issue but
| i am sort've railing against the suggestion of current
| level LLMs being used for tax-software and POS design.
|
| Edit: And if I was using C or C++ above my lack of
| capitalization would either evoke an error too OR
| passably continue foward referencing the wrong variable
| and result in a similar error to your transposition.
| ofalkaed wrote:
| I said that was something which would happen in the
| future, as in not the current level LLMs. But this is
| what people will pay the programmer for, the programmer
| will (hopefully) know when and where the LLM can be used
| to offload the grunt work and where they should just skip
| the LLM and hand code it, those things the average person
| will not know, the full system and this applies to
| current level LLMs
| tosapple wrote:
| In the future, this will be all voice controlled making
| most of our user-interfaces and expenditures on adapting
| to this intermediate stage moot.
| ofalkaed wrote:
| I find it interesting but not surprising that this got
| downvoted. Sure my idea of the craft is different than the
| article's and of many people but if the craft only there if it
| is pure hand written code then it is a craft which the vast
| majority can not afford. I can pay a luthier a few thousand and
| get my dream guitar and would happily spend that sort of money
| on getting custom software but that is not going to happen if I
| insist on 100% handwritten code, just as getting my dream
| guitar would not happen if I insisted on the luthier only using
| hand tools.
| npodbielski wrote:
| If that is true we will live in a funny world when you will loose
| all your money because you where running some outdated, riddled
| with holes software written by LLM running on some old router old
| cheap camera. Or some software will stop working after an update
| because some fix was written by LLM and nobody checked that nor
| tested. Or they will 3 outages of big internet services in 2
| months.
|
| Oh wait. It is already a thing.
| Deukhoofd wrote:
| The industrial revolution was constrained by access to the means
| of production, leaving only those with capital able to actually
| produce, which lead to new economic situations.
|
| What are the constraints with LLMs? Will an Anthropic, Google,
| OpenAI, etc, constrain how much we can consume? What is the value
| of any piece of software if anyone can produce everything? The
| same applies to everything we're suddenly able to produce. What
| is the value of a book if anyone can generate one? What is the
| value of a piece of art, if it requires zero skill to generate
| it?
| Abh1Works wrote:
| But I think the important part of this is the reach that the
| Industrial Revolution had. Consumer facing software, or the
| endusers who were able to "benefit" from the Industrial
| Revolution, and individual needs for all of these mass produced
| goods.
|
| The important thing is that goods =/= software. I, as an end
| user, of software rarely need specialized software. I dont need
| an entire app generated on the spot to split the bill and
| remember the difference if I have the calculator.
|
| So, yes, we are industrializing software, but this reach that
| people talk about (I believe) will be severely limited.
| vincnetas wrote:
| i would say comparing making of software and working factory
| makes analogy mistake. complete software is analogy to running
| factory. making software is making of the factory. that is
| specialised tooling, layouts, supply chain etc. when you have all
| this your factory runs on industrial scale and produces things.
| like your software produces value when its completed and used by
| enduser.
| pharrington wrote:
| This is written by the same guy who proudly blogged about not
| knowing how computers work.
| [https://chrisloy.dev/post/2013/04/27/no-i-can't-fix-your-com...]
| choeger wrote:
| Thing is: Industrialization is about repeating manufacturing
| steps. You don't need to repeat anything for software. Software
| can be copied arbitrarily for no practical cost.
|
| The idea of automation creating a massive amount of software
| sounds ridiculous. Why would we need that? More Games? Can only
| be consumed at the pace of the player. Agents? Can be reused once
| they fulfill a task sufficently.
|
| We're probably going to see a huge amount of _customization_
| where existing software is adapted to a specific use case or user
| via LLMs, but why would anyone waste energy to re-create the same
| algorithms over and over again.
| willtemperley wrote:
| People re-create the same algorithms all the time for different
| languages or because of license incompatibility.
|
| I'm personally doing just that because I want an algorithm
| written in C++ in a LGPL library working in another language
| nuancebydefault wrote:
| In fact this is a counter argument to the point of the
| article. You're not making 'just more throwaway software' but
| instead building usable software while standing on the
| shoulders of existing algo's and libraries.
| willtemperley wrote:
| Well yes. To me industrial software is hardened algorithms,
| not throwaway slop like the author is arguing. LLMs are
| very good at porting existing algorithms and as you say
| it's about standing on the shoulders of giants. I couldn't
| write these from scratch but I can port and harden an algo
| with basic engineering practices.
|
| I like the article except the premise is wrong - industrial
| software will be high value and low cost as it will outlive
| the slop.
| pyrale wrote:
| > You don't need to repeat anything for software. Software can
| be copied arbitrarily for no practical cost.
|
| ...Or so think devs.
|
| People responsible for operating software, as well as people
| responsible for maintaining it, may have different opinions.
|
| Bugs must be fixed, underlying software/hardware changes and
| vulnerabilities get discovered, and so versions must be bumped.
| The surrounding ecosystem changes, and so, even if _your_
| particular stack doesn 't require new features, it must be
| adapted (a simple example: your react front breaks because the
| nginx proxy changed is subdirectory).
| alexjurkiewicz wrote:
| The "industrialisation" concept is an analogy to emphasize how
| the costs of production are plummeting. Don't get hung up
| pointing out how one aspect of software doesn't match the
| analogy.
| mgh95 wrote:
| > The "industrialisation" concept is an analogy to emphasize
| how the costs of production are plummeting. Don't get hung up
| pointing out how one aspect of software doesn't match the
| analogy.
|
| Are they, though? I am not aware of any indicators that
| software costs are precipitously declining. At least as far
| as I know, we aren't seeing complements of software
| developers (PMs, sales, other adjacent roles) growing rapidly
| indicating a corresponding supply increase. We aren't seeing
| companies like mcirosoft or salesforce or atlassian or any
| major software company reduce prices due to supply glut.
|
| So what are the indicators (beyond blog posts) this is having
| a macro effect?
| bwest87 wrote:
| But focusing on production cost is silly. The cost to
| consumers is what matters. Software is already free or dirt
| cheap because it can be served at zero marginal cost. There
| was only a market for cheap industrial clothes because tailor
| made clothes were expensive. This is not the case in software
| and that's why this whole industrialization analogy falls
| apart upon inspection
| pyrale wrote:
| The article kind of misses that cost has two axes : development
| cost and maintenance cost.
|
| low cost/low value software tagged as disposable usually means
| development cost was low, but maintenance cost is high ; and
| that's why you get rid of it.
|
| On the other hand, the difference between good and bad
| traditional software is that, while cost is always going to be
| high, you want maintenance cost to be low. This is what
| industrialization is about.
| yosefk wrote:
| You could say the same things about assemblers, compilers,
| garbage collection, higher level languages etc. In practice the
| effect has always been an increase in the height of a mountain of
| software that can be made before development grinds to a halt due
| to complexity. LLMs are no different
| physicles wrote:
| In my own experience (and from everything I've read), LLMs as
| they are today don't help us as an industry build a higher
| mountain of software because they don't help us deal with
| complexity -- they only help us build the mountain faster.
| dcre wrote:
| I see this response a lot but I think it's self-
| contradictory. Building faster, understanding faster,
| refactoring faster -- these do allow skilled developers to
| work on bigger things. When it takes you one minute instead
| of an hour to find the answer to a question about how
| something works, _of course_ that lets you build something
| more complex.
|
| Could you say more about what you think it would look like
| for LLMs to genuinely help us deal with complexity? I can
| think of some things: helping us write more and better tests,
| fewer bugs, helping us get to the right abstractions faster,
| helping us write glue code so more systems can talk to each
| other, helping us port things to one stack so we don't have
| to maintain polyglot piles of stuff (or conversely helping us
| not worry about picking and choosing the best stuff from
| every language ecosystem).
| WJW wrote:
| This essay, like so many others, mistakes the task of "building"
| software with the task of "writing" software. Anyone in the world
| can already get cheap, mass-produced software to do almost
| anything they want their computer to do. Compilers spit out new
| build of any program on demand within seconds, and you can
| usually get both source code and pre-compiled copies over the
| internet. The "industrial process" (as TFA puts it) of production
| and distribution is already handled perfectly well by CI/CD
| systems and CDNs.
|
| What software developers _actually_ do is closer to the role of
| an architect in construction or a design engineer in
| manufacturing. They design new blueprints for the compilers to
| churn out. Like any design job, this needs some actual taste and
| insight into the particular circumstances. That has always been
| the difficult part of commercial software production and LLMs
| generally don 't help with that.
|
| It's like thinking the greatest barrier to producing the next
| great Russian literary novel is not speaking Russian. That is
| merely the first and easiest barrier, but after learning the
| language you are still no Tolstoy.
| nchmy wrote:
| You're getting caught up on the technical meaning of terms
| rather than what the author actually wrote.
|
| Theyre explicitly saying that most software will no longer be
| artisianal - a great literary novel - and instead become
| industrialized - mass produced paperback garbage books. But
| also saying that good software, like literature, will continue
| to exist.
| bruce511 wrote:
| I guess two things can be true at the same time. And I think
| AI will likely matter a lot more than detractors think, and
| nowhere near as much as enthusiasts think.
|
| Perhaps a good analogy is the spreadsheet. It was a complete
| shift in the way that humans interacted with numbers. From
| accounting to engineering to home budgets - there are few
| people who haven't used a spreadsheet to "program" the
| computer at some point.
|
| It's a fantastic tool, but has limits. It's also fair to say
| people use (abuse) spreadsheets far beyond those limits. It's
| a fantastic tool for accounting, but real accounting systems
| exist for a reason.
|
| Similarly AI will allow lots more people to "program" their
| computer. But making the programing task go away just exposes
| limitations in other parts of the "development" process.
|
| To your analogy I don't think AI does mass-produced
| paperbacks. I think it is the equivalent of writing a novel
| for yourself. People don't sell spreadsheets, they use them.
| AI will allow people to write programs for themselves, just
| like digital cameras turned us all into photographers. But
| when we need it "done right" we'll still turn to people with
| honed skills.
| nchmy wrote:
| > your analogy I don't think AI does mass-produced
| paperbacks
|
| It's the article's analogy, not mine.
|
| And, are you really saying that people aren't regularly
| mass-vibing terrible software that others use...? That
| seems to be a primary use case...
|
| Though, yes, I'm sure it'll become more common for many
| people to vibe their own software - even if just tiny,
| temporary, fit-for-purpose things.
| bruce511 wrote:
| I think existing skilled programmers are leveraging AI to
| increase productivity.
|
| I think there are some people with limited, or no,
| programming experience who are vibe coding small apps out
| of nothing. But I think this is a tiny fraction of
| people. As much as the AI might write code, the tools
| used to do that, plus compile, distribute etc are still
| very developer focused.
|
| Sure, one day my pastor might be able to download and
| install some complete environment which allows him to
| create something.
|
| Maybe it'll design the database for him, plus install and
| maintain the local database server for him (or integrate
| with a cloud service.)
|
| Maybe it'll get all the necessary database and program
| security right.
|
| Maybe it'll integrate well with other systems, from email
| to text-import and export. Maybe that will all be
| maintainable as external services change.
|
| Maybe it'll be able to do support when the printing stops
| working, or it all needs to be moved to a new machine.
|
| Maybe this environment will be stable enough for the
| years and decades that the program will be used for.
| Maybe updating or adding to the program along the way
| won't break existing things.
|
| Maybe it'll work so well it can be distributed to others.
|
| All this without my pastor even needing to understand
| what a "variable" is.
|
| That day may come. But, as well as it might or might not
| write code today, we're a long long way from this future.
| Mass producing software is a lot more than writing code.
| yourapostasy wrote:
| We could have LLM's capable of doing all that for your
| pastor right now and it would still take time before
| these systems can effectively reason through
| troubleshooting this bespoke software. Right now the
| effectiveness of LLLM-powered troubleshooting software
| platforms relies upon the gravity induced by millions of
| programmers sharing experiences upon more or less the
| same platforms. Gigabytes to terabytes of text training
| data on all sorts of things that go bonkers on each
| platform.
|
| We are now undergoing a Cambrian explosion of bespoke
| software vibe coded by a non-technical audience, and each
| one brings with it new sets of failure modes only found
| in their operational phase. And compared to the current
| state, effectively zero training data to guide their
| troubleshooting response.
|
| Non-linearly increasing the surface area of software to
| debug, and inversely decreasing the training data to
| apply to that debugging activity will hopefully apply
| creative pressure upon AI research to come up with more
| powerful ways to debug all this code. As it stands now, I
| sure hope someone deep into AI research and praxis sees
| this and follows up with a comment here that prescribes
| the AI-assisted troubleshooting approach I'm missing that
| goes beyond "a more efficient Google and StackOverflow
| search".
|
| Also, the current approach is awesome for me to come up
| to speed on new applications of coding and new platforms
| I'm not familiar with. But for areas that I'm already
| fluent in and the areas my stakeholders especially want
| to see LLM-based amplification, either I'm doing
| something wrong or we're just not yet good at
| troubleshooting legacy code with them. There is some
| uncanny valley of reasoning I'm unable to bridge so far
| with the stuff I'm already familiar with.
| pydry wrote:
| This was already true before LLMs. "Artisinal software" was
| never the norm. The tsunami of crap just got a bit bigger.
|
| Unlike clothing, software always scaled. So, it's a bit
| wrongheaded to assume that the new economics would be more
| like the economics of clothing after mass production. An
| "artisanal" dress still only fits one person. "Artisanal"
| software has always served anywhere between zero people and
| millions.
|
| LLMs are not the spinning jenny. They are not an industrial
| revolution, even if the stock market valuations assume that
| they are.
| cryptica wrote:
| Agreed, software was always kind of mediocre. This is
| expected given the massive first mover advantage effect.
| Quality is irrelevant when speed to market is everything.
| pydry wrote:
| Unlike speed to market it doesnt manifest in an obvious
| way but I've watched several companies lose significant
| market share because they didnt appreciate software
| quality.
| WJW wrote:
| Yes, I read the article. I still think it's incorrect. Most
| software (especially by usage) is already not artisanal. You
| get the exact same browser, database server and
| (whatsapp/signal/telegram/whatever) messenger client as
| basically everyone else. Those are churned out by the
| millions from a common blueprint and designed by teams and
| teams of highly skilled specialists using specialized
| tooling, not so different from the latest iPhone or car.
|
| As such, the article's point fails right at the start when it
| tries to make the point that software production is not
| already industrial. It is. But if you look at actual
| industrial design processes, their equivalent of "writing the
| code" is relatively small. Quality assurance, compliance to
| various legal requirements, balancing different requirements
| for the product at hand, having endless meetings with
| customer representatives to figure out requirements in the
| first place, those are where most of the time goes and those
| are exactly the places where LLMs are not very good. So the
| part that is already fast will get faster and the slow part
| will stay slow. That is not a recipe for revolutionary
| progress.
| bsenftner wrote:
| I think the author of the post envisions more code
| authoring automation, more generated code/test/deployment,
| exponentially more. To the degree what we have now would be
| "quaint", as he says.
|
| Your point that most software uses the same browsers,
| databases, tooling and internal libraries is a weakness, a
| sameness that can be exploited by current AI, to push that
| automation capability much further. Hell, why even bother
| with any of the generated code and infrastructure being
| "human readable" anymore? (Of course, all kinds of reasons
| that is bad, but just watch that "innovation" get a
| marketing push and take off. Which would only mean we'd
| need viewing software to make whatever was generated
| readable - as if anyone would read to understand
| hundreds/millions of generated complex anything.)
| yobbo wrote:
| LLMs produce human readable output because they learn
| from human readable input. It's a feature. It allows it
| to be much less precise than byte code, for example,
| which wouldn't help at all.
| godelski wrote:
| > You get the exact same browser, database server and
| (whatsapp/signal/telegram/whatever) messenger client as
| basically everyone else.
|
| Hey! I'm going to passionately defend my choice over a
| really minor difference. I mean do you see how that app
| does their hamburger menu?! It makes the app utterly
| unusable!
|
| Maybe I'm exaggerating here but I've heard things pretty
| close in "chrome vs Firefox" and "signal vs ..." threads.
| People are really passionate about tiny details. Or at
| least they think that's that they're passionate about.
|
| Unfortunately I think what they don't realize is that
| passion often hinders that revolutionary progress you speak
| of. It just creates entrenched players and monopolies in
| domains where it should be near trivial to move (browsers
| are definitely trivial to jump ship)
| PaulHoule wrote:
| What he's missing is that there's always been a market for
| custom-built software by non-professionals. For instance,
| spreadsheets. Back in the 1970s engineers and accountants and
| people like that wrote simple programs for programmable
| calculators. Today it's Python.
|
| The most radical development in software tools I think, would
| be more tools for non-professional programmers to program
| small tools that put their skills on wheels. I did a lot of
| biz dev around something that encompassed "low code/no code"
| but a revolution there involves smoothing out 5-10 obstacles
| with a definite Ashby character that if you fool yourself
| that you can get away with ignoring the last 2 required
| requirements you get just another Wix that people will laugh
| at. For now, AI coding doesn't have that much to offer the
| non-professional programmer because a person without insight
| into the structure of programs, project management and a
| sense of what quality means will go in circles at best.
|
| I think the thinking in the article is completely backwards
| about the economics. I mean, the point of software is you can
| write it once and the cost to deploy a billion units is
| trivial in comparison. Sure, AI slop can put the "crap" in
| "app" but if you have any sense you don't go cruising the app
| store for trash but find out about best-of-breed products or
| products that are the thin edge of a long wedge (like the
| McDonald's app which is valuable because it has all the
| stores baacking it)
| ryukoposting wrote:
| Isn't this already the case? Your company doesn't build its
| own word processor, they license it from Microsoft, or they
| pay Google for G Suite, or whatever. Great books are sold in
| paperback, after all.
| layer8 wrote:
| "Garbage books" are mass-printed, but aren't mass-written in
| a mass production sense. Mass production is about producing
| fairly exact copies of something that was designed once. The
| design part has always remained more artisanal than
| industrial. It's only the production _based_ on the design
| (or manuscript) that is industrial.
|
| The difference with software is that software is design all
| the way down. It only needs to be written once, similar to
| how a mass-produced item needs only be designed once. The
| copying that corresponds to mass production is the deployment
| and execution of the software, not the writing of it.
| thisgetsit wrote:
| The syntactic representation will become that. End of day
| it's just math ops, state sync of memory and display. Even
| semantic objects like an OSs protected memory is a special
| case of access control that can be mathematically computed
| around. There is nothing important about special semantics.
|
| The user experience will be less constrained as the self
| arrangement of pixels improves and users do not run into
| designer constraints, usually due to lack of granularity some
| button widget or layout framework is capable of.
|
| "Artisanal" software engineers probably never were their own
| self selected identity.
|
| Have been writing code since the late 80s, when Windows and
| commercial Unix were too expansive and we all wrote shoddy
| but functional kernels. Who does that now? Most gigs these
| days are glue code to fetch/cache deps and template concrete
| config values for frameworks. Artisanal SaaS configuration is
| not artisanal software engineering.
|
| And because software engineers were their own worst enemy the
| last decade; living big as they ate others jobs and
| industries; hate for the industry has gone mainstream.
| Something politicians have to react to. Non-SWEs don't want
| to pay middle men to use their property. GenAI can get them
| to that place.
|
| As an art teacher once said; making things for money is not
| the practice of a craft. It's just capitalism. Anyone
| building SaaS apps through contemporary methods is a Subway
| sandwich artist, not the old timey well rounded farmer,
| hunter, who also bakes bread.
| weslleyskah wrote:
| > It's like thinking the greatest barrier to producing the next
| great Russian literary novel is not speaking Russian. That is
| merely the first and easiest barrier, but after learning the
| language you are still no Tolstoy.
|
| And what do you feel is the role of universities? Certainly not
| just to learn the language right? I'm going through a computer
| engineering degree and sometimes I feel completely lost with an
| urge to give up on everything, even though I am still
| interested in technology.
| estimator7292 wrote:
| One can go to school to learn the literary arts. Many do. A
| _lot_ of authors do not.
|
| A _lot_ of engineers and programmers did not go to school.
| furyofantares wrote:
| > It's like thinking the greatest barrier to producing the next
| great Russian literary novel is not speaking Russian.
|
| The article is very clearly not saying anything like that. It's
| saying the greatest barrier to making throwaway comments on
| Russian social media is not speaking Russian.
|
| Roughly the entire article is about LLMs making it much cheaper
| to make low quality software. It's not about masterpieces.
|
| And I think it's generally true of all forms of generative AI,
| what these things excel at the most is producing things that
| weren't valuable enough to produce before. Throwaway scripts
| for some task you'd just have done manually before is a really
| positive example that probably many here are familiar with.
|
| But making stuff that wasn't worth making before isn't
| necessarily good! In some cases it is, but it really sucks if
| we have garbage blog posts and readmes and PRs flooding our
| communication channels because it's suddenly cheaper to produce
| than whatever minimal value someone gets out of hoisting it on
| us.
| duxup wrote:
| I also wonder about the process.
|
| I've worked for a lot of people involved in the process happily
| request their software get turned into spaghetti. Often because
| some business process "can't" be changed, but mostly because
| decision makers do not know / understand what they're asking in
| a larger scheme of things.
|
| A good engineer can help mitigate that, but only so much. So
| you end up with industrial sludge to some extent anyway if
| people in the process are not thoughtful.
| lifeisstillgood wrote:
| I have for a long time been saying software is a new form of
| literacy - and I really need to finish writing the book !
| dustinboss wrote:
| "Technical debt is the pollution of the digital world, invisible
| until it chokes the systems that depend on it." Such a great
| line.
| skydhash wrote:
| And also false. Good programmers are always aware of the debt.
| It's just not easily quantifiable as part of it can only be
| estimated when a change request has been made. And truly known
| when implementing the change.
|
| It's always a choice between taking more time today to reduce
| the cost of changes in the future, or get result fast and be
| less flexible later. Experience is all about keeping the cost
| of changes constant over time.
| dustinboss wrote:
| We can both be aware of the debt and still get choked by it.
| It's what makes pollution such a great metaphor. We know
| we're creating it -- even try to mitigate it -- but it still
| keeps growing.
| skydhash wrote:
| Tech debt grows only when you don't care. We have codebases
| that are old enough to drive where the debt is not growing
| at all. You got there by the code being a good
| representation of the domain requirements in the technical
| space. If the domain don't change much (they rarely do),
| you don't have to do much work in the technical space. And
| if the latter change (platform and library updates), it's
| gradual enough that you can spread the cost over time.
|
| You got tech debt when rushing to implement stuff while
| having an incomplete representation of the problem. And
| then trying to patch the wrong solution instead of
| correcting it.
| MORPHOICES wrote:
| What I've been pondering is the nature of what makes the user
| interface of some software "industrial" versus "complicated." ~
|
| "The difference I return to again and again isn't tech depth.
| It's constraints."
|
| "Rough framework I'm using lately:"
|
| Consumer software aims at maximizing joy.
|
| "Enterprise software is all about coordination."
|
| "Industrial software operates in a environment of the real-world
| "mess", yet its
|
| "Industrial stuff appears to be more concerned with:
| a.
|
| failure modes
|
| long-term maintenance
|
| predictable behavior vs cleverness
|
| But as soon as software is involved with physical processes, the
| tolerance for ambiguity narrows quickly.
|
| Curious how others see it:
|
| What's your mental line between enterprise and industrial? What
| constraints have affected your designing? "Nice abstractions."
| Any instances where these failed the test of reality?
| alexjurkiewicz wrote:
| The article isn't talking talking about "industrial" in
| relation to user interfaces. It isn't talking about user
| interfaces at all.
|
| Your consumer/enterprise/industrial framework is orthogonal to
| the articles focus: how AI is massively reducing the cost of
| software.
| djantje wrote:
| It is just going to be even more less important software.
|
| There is a difference between writing for mainstream software and
| someone's idea/hope for the future.
|
| Software that is valued high enough will be owned and maintained.
|
| Like most things in our world, I think ownership/stewardship is
| like money and world hunger, a social issue/question.
| xorcist wrote:
| Too many articles are written comparing LLMs to high-level
| languages. Sure, if you squint enough, both has to do with
| computers. But that comparison misses everything that is
| important about LLMs.
|
| High-level languages are about higher abstractions for
| deterministic processes. LLMs are not necessarily higher
| abstractions but instead about non-deterministic processes, a
| fundamentally different thing altogether.
| tgv wrote:
| Perhaps you mean reliability rather than
| determinism/reproduceability?
| torginus wrote:
| So many fallacies here, imprecise, reaching arguments, attempts
| at creating moral panic, insistence that most people create poor
| quality garbage code, in start contrast to the poster, the
| difference between his bespoke excellence, and the dreck produced
| by the soulless masses is gracefully omitted.
|
| First the core of the argument that 'Industrialization' produces
| low quality slop is not true - industrialization is about
| precisely controlled and repeatable processes. A table cut by a
| CNC router is likely dimensionally more accurate than one cut by
| hand, in fact many of the industrial processes and machines have
| trickled back into the toolboxes of master craftsmen, where they
| increased productivity and quality.
|
| Second, from my experience of working at large enterprises, and
| smaller teams, the 80-20 rule definitely holds - there's always a
| core team of a handful of people who lay down the foundations,
| and design and architect most of the code, with the rest usually
| fixing bugs, or making bullet point features.
|
| I'm not saying the people who fall into the 80% don't contribute,
| or somehow are lesser devs, but they're mostly not well-
| positioned in the org to make major contributions, and another
| invariable aspect is that as features are added and complexity
| grows, along with legacy code, the effort needed to make a
| change, or understand and fix a bug grows superlinearly, meaning
| the 'last 10%' often takes as much or more effort than what came
| before.
|
| This is hardly an original observation, and in today's ever-
| ongoing iteration environment, what counts as the last 10% is
| hard to define, but most modern software development is highly
| incremental, often is focused on building unneeded features, or
| sidegrade redesigns.
| eitally wrote:
| I spent 15 years writing literal industrial software
| (manufacturing, test, and quality systems for a global high-tech
| manufacturing company, parts of which operated in regulated
| industries).
|
| One of the things that happened around 2010, when we decided to
| effect a massive corporate change away from both legacy and
| proprietary platforms (on the one hand, away from AIX & Progress,
| and on the other hand, away from .Net/SQL Server), was a set of
| necessary decisions about the fundamental architecture of
| systems, and which -- if any -- third party libraries we would
| use to accelerate software development going forward.
|
| On the back end side (mission critical OLTP & data input screens
| moving from Progress 4GL to Java+PostgreSQL) it was fairly
| straightforward: pick lean options and as few external tools as
| possible in order to ensure the dev team all completely
| understand the codebase, even if it made developing new features
| more time consuming sometimes.
|
| On the front end, though, where the system config was done, as
| well as all the reporting and business analytics, it was less
| straightforward. There were multiple camps in the team, with some
| devs wanting to lean on 3rd party stuff as much as possible,
| others wanting to go all-in on TDD and using 3rd party frameworks
| and libraries only for UI items (stuff like Telerik, jQuery,
| etc), and a few having strong opinions about one thing but not
| others.
|
| What I found was that in an organization with primarily junior
| engineers, many of which were offshore, the best approach was not
| to focus on ideally "crafted" code (I literally ran a test with a
| senior architect once where he & I documented the business
| requirements completely and he translated the reqs into
| functional tests, then handed over the tests to the offshore team
| to write code to pass. They didn't even mostly know what the code
| was for or what the overall system did, but they were competent
| enough to write code to pass tests. This ensured the senior
| architect received _something_ that helped him string everything
| together, but it also meant we ended up with a really convoluted
| codebase that was challenging to holistically interpret if you
| hadn 't been on the team from the beginning. I had another
| architect, who was a lead in one of the offshore teams, who felt
| very strongly that code should be as simple as possible:
| descriptive naming, single function classes, etc. I let him run
| with his paradigm on a different project, to see what would
| happen. In his case, he didn't focus on TDD and instead just on
| clearly written requirements docs. But his developers had a mix
| of talents & experience and the checked-in code was all over the
| place. Because of how atomically abstract everything was, almost
| nobody understood how pieces of the system interrelated.
|
| Both of these experiments led to a set of conclusions and
| approach as we moved forward: clearly written business
| requirements, followed by technical specifications, are critical,
| and so is a set of coding standards the whole group understands
| and has confidence to follow. We setup an XP system to coach
| junior devs who were less experienced, ran regular show & tell
| sessions where individuals could talk about their work, and moved
| from a waterfall planning process to an iterative model. All of
| this sounds like common sense now that it's been standard in the
| tech industry for an entire generation, but it was _not_ obvious
| or accepted in IT "Enterprise Apps" departments in low margin
| industries until far more recently.
|
| I left that role in 2015 to join a hyperscaler, and only recently
| (this year) have moved back to a product company, but what I've
| noticed now is that the collaborative nature of software
| engineering has never been better ... but we're back to a point
| where many engineers don't fully understand what they're doing,
| either because there's a heavy reliance on code they didn't write
| (common 3P libraries) or because of the compartmentalization of
| product orgs where small teams don't always know what other teams
| are doing, or why. The more recent adoption of LLM-accelerated
| development means even fewer individuals can explain resultant
| codebases. While software development may be faster than ever, I
| fear as an industry we're moving back toward the era of the early
| naughts when the graybeard artisans had mostly retired and their
| replacements were fumbling around trying to figure out how to do
| things faster & cheaper and decidedly un-artisanally.
| japhyr wrote:
| > Previous industrial revolutions externalised their costs onto
| environments that seemed infinite until they weren't. Software
| ecosystems are no different: dependency chains, maintenance
| burdens, security surfaces that compound as output scales.
| Technical debt is the pollution of the digital world, invisible
| until it chokes the systems that depend on it. In an era of mass
| automation, we may find that the hardest problem is not
| production, but stewardship. Who maintains the software that no
| one owns?
|
| This whole article was interesting, but I really like the
| conclusion. I think the comparison to the externalized costs of
| industrialization, which we are finally facing without any easy
| out, is a good one to make. We've been on the same path for a
| long time in the software world, as evidenced by the persistent
| relevance of that one XKCD comic.
|
| There's always going to be work to do in our field. How appealing
| that work is, and how we're treated as we do that work, is a wide
| open question.
| sriku wrote:
| I find it hard to think of code as being the output of
| programming. I keep re-reading Naur's "Programming as theory
| building" paper and it still feels relevant and closer to how the
| activity feels to me, AI or no AI.
|
| https://pages.cs.wisc.edu/~remzi/Naur.pdf
| sriku wrote:
| The frame set by the OP completely out me off and dissuaded me
| from reading the rest of the article beyond the first
| paragraph. Didn't feel like much throught was given to what was
| being said.
| physicsguy wrote:
| I've just done my first almost fully vibe coded hobby project
| from start to near completion, a village history website with a
| taxonomy, and it's taken so much poking and prodding and cajoling
| to get the software to do exactly what I want it to do. Having
| built plenty of production stuff, I know what I want it to look
| like and the data model was really clear, yet even trying every
| trick in the book to constrain them, I just found the LLMs went
| off and did totally random things, particularly as the project
| got further from the start.
|
| Maybe there'll be an enormous leap again but I just don't quite
| see the jump to how this gets you to 'industrial' software. It
| made it a lot faster, don't get me wrong, but you still needed
| the captain driving the ship.
| Havoc wrote:
| > you still needed the captain driving the ship.
|
| The question is more what becomes of all the rowers when you're
| switching from captain + 100 rowers to captain + steam engine
|
| They're not all going to get their own boat and captain hat
| kj4211cash wrote:
| But were there ever 100 "rowers"? In this case, the commenter
| would have developed the website him- or herself instead of
| using AI. And it would have taken a little longer but
| probably been higher quality. In my experience, most
| developers are already capable captains and most of their job
| is "captaining." One of their main complaints is managers who
| treat them like rowers. AI just shifts what it means to
| captain?
| godelski wrote:
| Honestly I just wonder if everyone is burnt out so they
| still want to do their side projects but don't have much
| energy left over for the passion they had before. So the
| bar for "good enough" just lowers
| gverrilla wrote:
| They could do a revolution. 100 rowers vs 1 captain - easy.
| Labor vs capital.
| why_is_it_good wrote:
| You mean murder, before capital understands its critics are
| as moraly bankrupt as capital itself, and deploys killbots?
| physicsguy wrote:
| Right but in this case, what might have taken me 2-3 days
| initially took me a day still with many many frustrating "no,
| I said I don't want you to edit that file in that way"
| moments. So it's faster but annoying.
|
| To me it feels like when doing it's like when you're pair
| programming (which is quite intense anyway) with a
| frustrating newby who can program but misses the big picture
| no matter how many times you try. It works better for certain
| types of software - web it's great, I have had much worse
| results when doing data pipeline stuff at work.
| applied_heat wrote:
| >They're not all going to get their own boat and captain hat
|
| Why not? Anyone can load up Claude code and start trial and
| erroring until they get something that works and has similar
| reliability to accepted software ... what is the stat about 1
| bug per 10 lines of code on average?
|
| I am meeting a lot of non coders telling me about their
| projects they are getting AI to do for them, stuff to help
| land title something or other, stuff to work on avalanche
| forecast, whatever their area of expertise they are unchained
| and writing programs using AI that they couldn't before.
|
| Everyone is the captain now
| onion2k wrote:
| _Anyone can load up Claude code and start trial and
| erroring until they get something that works and has
| similar reliability to accepted software.._
|
| You still need to understand the code that AI is generating
| to fix the problems that you can't vibe a solution to. You
| still need to understand the process of developing software
| to know when something isn't working _even if it looks like
| it is_. You still need other people to trust the software
| that you created. None of those things comes naturally to
| vibe coders. They 're essentially teaching themselves
| software engineering in a very back-to-front way.
| applied_heat wrote:
| Everybody learned somehow. I wonder what % of programmers
| actually have relevant training and education in
| programming vs just taught themselves with online
| resources.
|
| Maybe the amateurs aren't going to be writing a new
| distributed database but CRUD apps must be easier than
| ever
| Ianjit wrote:
| The studies I have seen show that AI written software is
| 70% more buggy than human written code [1]. I am curious
| where you get your data on AI code having "a similar
| reliability to accepted software"?
|
| [1] https://www.coderabbit.ai/blog/state-of-ai-vs-human-
| code-gen...
| zx8080 wrote:
| > This website uses anonymous cookies to enhance the user
| experience.
|
| This sounds weird, or wrong. Does anonymous stats need cookies at
| all?
| te7447 wrote:
| If you want to track how many times users revisit the site, you
| could do that anonymously by setting a visit counter cookie,
| e.g. VISITS: 1, VISITS: 2, etc. This would track the user over
| different IPs, but since the cookie only has a counter, it
| doesn't tell you if two people with "VISITS: 2" set is the same
| user.
|
| That's the first example I can think of off the top of my head.
| zx8080 wrote:
| Sure. Buthow would it "enhance the user experience"?
| analog31 wrote:
| The first thing I noticed was the graph of cost vs quality, with
| two quadrants. And I realize software is a unique industry, but
| in many other industries there's a third quadrant: Higher quality
| at lower cost. Electronics is an example. Virtually nobody wants
| or even remembers artisanal electronics.
|
| In fact, getting out of the two quadrant mindset, and seeking the
| third, is part of the learning process for developing modern
| industrial products. And where I work, adjacent to a software
| development department, I think the devs are aware of this as
| well. They wanted to benefit from further automation -- the thing
| I think they're coping with is that it seems to be happening so
| quickly.
| mwkaufma wrote:
| "the dictionary defines 'industrial' as..." lol
| delegate wrote:
| I share the vision of the author.
|
| People use software for specific features, but most software have
| lots of features people never use or need. A lot of modern
| software is designed to handle lots of users, so they need to be
| scalable, deployable, etc.
|
| I don't need any of that. I just need the tool to do the thing I
| want it to do. I'm not thinking about end users, I just need to
| solve my specific problem. Sure there might be better pieces of
| software out there, which do more things. But the vibe coded
| thing works quite well for me and I can always fix it by
| prompting the model.
|
| For example, I've vibe coded a tool where I upload an audio file,
| the tool transcribes it and splits it into 'scenes' which I can
| sync to audio via a simple UI and then I can generate images for
| each scene. Then it exports the video. It's simple, a bit buggy,
| lacks some features, but it does the job.
|
| It would have taken me weeks to get to where I am now without
| having written one manual line of code.
|
| I need the generated videos, not the software. I might eventually
| turn it into a product which others can use, but I don't focus on
| that yet, I'm solving my problem. Which simplifies the software a
| lot.
|
| After I'm finished with this one, I might generate another one,
| now that I know exactly what I want it to do and what pitfalls to
| avoid. But yeah, the age of industrial software is upon us. We'll
| have to adapt.
| when_creaks wrote:
| The article makes reference to the Jevons paradox.
|
| This paper about LLM economics seems relevant:
|
| https://www.nber.org/papers/w34608
|
| Quote: "Fifth, we estimate preliminary short-run price
| elasticities just above one, suggesting limited scope for Jevons-
| Paradox effects"
| bwest87 wrote:
| One thing that has become clearer to me over the years is that
| reasoning by analogy (like this article does) sounds a lot
| smarter than it is. If you look from first principles, it's clear
| that physical goods and software don't share the same properties
| and thus the analogy falls apart.
|
| Physical goods like clothes or cars have _variable costs_. The
| marginal _unit_ always costs > 0, and thus the price to the
| consumer is always greater than zero. Industrialization lowered
| this variable cost, while simultaneously increasing production
| capacity, and thus enabled a new segment of "low cost, high
| volume" products, but it does not eliminate the variable cost.
| This variable cost (eg. the cost of a hand made suit) is the
| "umbrella" under which a low cost variant (factory made clothes)
| has space to enter the market.
|
| Digital goods have _zero_ marginal cost. Many digital goods do
| not cost anything at all _to the consumer_! Or they are as cheap
| as possible to actively maximize users because their costs are
| effectively fixed. What is the "low value / low cost" version of
| Google? or Netflix for that matter? This is non-sensical because
| there's no space for a low cost entrant to play in when the price
| is already free.
|
| In digital goods, consumers tend to choose on quality because
| price is just not that relevant of a dimension. You see this in
| the market structure of digital goods. They tend to be winner (or
| few) take all because the best good can serve everyone. That is a
| direct result of zero marginal cost.
|
| Even if you accept the premise that AI will make software
| "industrialized" and thus cheaper to produce, it doesn't change
| the fact that most software is already free or dirt cheap.
|
| The version of this that might make sense is software that is too
| expensive to make at all because the market size (eg. number of
| consumers * price they would pay) is less than the cost of the
| software developer / entrpreneurs time. But by definition those
| are small markets, and not anything like the huge markets that
| were enabled by physical good industrialization.
| gamblor956 wrote:
| Digital goods do have a marginal cost. It's a lot lower than
| with physical goods, but there _is_ a cost: at the very
| minimum, a digital good takes up storage space. A streamed
| digital good requires bandwidth and electricity (and in most of
| the world, both are metered resources).
|
| Also, most consumers don't choose on quality; they choose on
| price. This is why free mobile games became huge and paid
| mobile games are a dying breed. In the physical world, it's why
| shein and alibaba nearly became trillion-dollar companies.
| bwest87 wrote:
| Sure there is some minimal marginal cost, but it's so close
| to zero that it's usually negligible, and the incentive is to
| basically give it away and "monetize" something else. Your
| point about games actually just makes my original point.
| Software is already usually free or dirt cheap, which is why
| reducing the cost to make the software can't create some "low
| cost / low value" quadrant. Unless your talking about bespoke
| software that has such a small market size it isn't worth
| making today. I could maybe see that area opening up, but
| even that software would not fit the OP's description of
| software that "has no owner and is not meant to be
| maintained"
| LAC-Tech wrote:
| Its taken as a fait accompli that LLMs are more productive. But
| outside some initial scaffolding or code review... I just do not
| see it.
|
| I am not threatened by LLMs. I would like it if I could code
| purely in requirements. But every time I get frustrated and just
| do it myself, because I am faster.
| pvtmert wrote:
| In the _Will traditional software survive?_ section the author
| describes "Boutique-sofware" as the low-value high-cost software
| [1]. However, the examples in the following paragraphs are quite
| contrary to that statement.
|
| - Tailored suit: This is a high-cost and high-value thing. Both
| quality and fit are much better than fast-fashion.
|
| In the similar sense, maybe LLMs will produce the frameworks or
| libraries in the future. Akin to the "fabric" used by the
| tailors. But at the end, craftsmen or women are the ones
| architecting and stitching these together.
|
| Verbatim [1]: > Will traditional software
| survive? > Ultraprocessed foods are, of course, not the
| only game in town. There is a thriving and growing demand for
| healthy, sustainable production of foodstuffs, largely in
| response to the harmful effects of industrialisation. Is it
| possible that software might also resist mechanisation through
| the growth of an "organic software" movement? If we look at other
| sectors, we see that even those with the highest levels of
| industrialisation also still benefit from small-scale, human-led
| production as part of the spectrum of output. > For
| example, prior to industrialisation, clothing was largely
| produced by specialised artisans, often coordinated through
| guilds and manual labour, with resources gathered locally, and
| the expertise for creating durable fabrics accumulated over
| years, and frequently passed down in family lines.
| Industrialisation changed that completely, with raw materials
| being shipped intercontinentally, fabrics mass produced in
| factories, clothes assembled by machinery, all leading to today's
| world of fast, disposable, exploitative fashion. And yet
| handcrafted clothes still exist: from tailored suits to knitted
| scarves, a place still exists for small-scale, slow production of
| textile goods, for reasons ranging from customisation of fit,
| signalling of wealth, durability of product, up to enjoyment of
| the craft as a pastime.
___________________________________________________________________
(page generated 2025-12-31 23:00 UTC)