Software design, building and maintenance has changed forever because of real-time generated, impromptu software using AI language models. The true impact on the software industry and its ecosystem, product quality and customer experience cannot be overstated. This shift is as important as the introduction of APIs, UI design and apps, only more so.
Quick recap: in our podcast It’s Just A Model, episode Tolerances, my cohost Ron Kersic and I talked about the first glances of the change Google made to its search result makeup. Now parts of the results will be like little interactive blocks, ready to play around with, like little answer machines, or little tools to work with, talk to and interact with.
These little interactive blocks are generated on the spot and although they look like fully-fledged pieces of software with hours of development time, design rounds and maintenance pipelines, they are in fact throwaway items. This new behavior of throwing away the software after a single use got us to the stunning comparison with Fast Fashion.
Indeed, after the first fully fledged vibecoded prototypes, to working products and now these real time rendered, throw away widgets we moved into the age of Fast Fashion Software.
What you want, when you want it, wherever you want it
Let’s approach this Fast Fashion Software change from the perspective of the end user. What did really change? Well, we get what we want, when we want it. That’s it.
The precursor, the LLM with a chat interface, gave us a nice preview. We wanted an answer, we asked the question and we got exactly that. Instant gratification, but also with an answer that was perceived as being as value as a sketch on sticky note, rather than a fully realized storyboard.
With the Google widgets and the integrated AI in Apples newest OS, we get more than a static piece of text, we get an interface, made for you and the purpose of your specific need. Whether it’s a holiday to-do app, a mortgage calculator, a pun generator, or an interface to interview a dead poet, Google and many others will follow this pattern.
This break with conventions not only happened in search, but also in many office applications and integrated in operating systems like Apple’s iOS. No more need to go to the search results, because you just got your answer in a personalized friendly interface.
Did Google and Apple as front runners create huge software design teams to think of and create all these bespoke pieces of software? No. Because the shift to create this new experience is even more impactful than the experience itself. The biggest shift is in how we make software.
We went from slowly building reliable, maintainable and safe code to vibe code. From requirements, user stories and fixed designs to intent, context and generated interactions. From software as something that is built to last, to software as something that can appear for a while, do its job and disappear again.
AI-generated code, images and texts are often throwaway products. Not because we decided so, but because this is the way AI currently works best. The classical approach to making software, iteration, does not apply to most pieces of AI-generated software in the same way, because it’s too expensive. You need humans to check, correct, test and document. The answer is as liberating as scary: just regenerate everything altogether.
This approach also means a different way to think about the product, experience, or service you’re building. You’re not micro-managing features, but taking the entire experience, perceived value and branding in regard. You hone your world building skills every time you visit the next incarnation of your prose-build-world, in which your product will live.
The software life cycle: from architecture to fast fashion
As a world builder, language is important, so it’s good to take a look what changes in the language of building software. From the onset, software terminology is riddled with references to building architecture: scaffolding, blueprint, stack, platform, facade, structure. The reason for this usage is that the commonalities between building software and building actual buildings are vast.
For both architecture and software, builders are aware of context, efficiency of time and resources, building to last, safety and being “up to code” and being able to maintain and improve your product. The most recognized pattern in language and behaviour is to make no mistakes while building it and building it once well, because building it again is too costly.
Not only did we appropriate architectural language in the building software ecosystem, we also changed, or rather codified our behavior because of the words and what they mean to us in the real world. Some words imply fast change, some words are about decoration, some words describe maintenance and some words imply security. It shaped how we think about software.

But now, our perception changes and our language seems to lag behind, holding us back. Because from the first inklings of vibe coding to current-day full agentic AI marketing departments that autonomously generate on-brand messaging, we get a convergence of two trends in AI-generated products: “good enough” and “cost per try”. With that convergence it’s easy to produce throwaway software, again and again. Code reviews, version control and commenting in the code became meaningless over night. These things are captured somewhere else and need different words, or became obsolete.
Not only did we appropriate architectural language in the building software ecosystem, we also changed, or rather codified our behavior because of the words and what they mean to us in the real world.
In the recent past we regenerated code in our AI enhanced IDE’s to get the quality to the right level, but nowadays we can just generate a brand-new, custom, one shot, personal and cheap product every time. Software in many ways has become a single-use product: introducing once again: Fast Fashion Software.
Fast Fashion Software changes the ecosystem
The comparison of AI-generated software and fast fashion is particularly apt. High-end fashion is built to manufacture to verifiable value. That means educated people, taught in a multi year master-apprentice construction, doing artisan tasks, in a costly space, working with durable materials and with custom machines. In fast fashion the people are reduced to cheap commodity. They are preferably moved out of the process as much as possible to lower cost, materials are cheap and chosen to effect, rather durability, and machines are multipurpose, computer-aided and made for speed and volume.
The result of the fast fashion industry: clothing that is not only cheap in manufacturing, but also cheap in experience and perceived value. Some clothing is as cheap as the magazine it used to be advertised in. People act accordingly and disregard their clothing as if they are disposing of a fleeting expression, rather than a curated piece of their identity, life, or work. Throwing away fast fashion after minimal usage is a new, perhaps unintentional side effect of this industry.
As a side note: fast fashion is an industry we, as consumers, co-created, two behaviors that by constructive interference escalated to a exponentially horrifying industry. Perhaps this industry could take the next step and rather than creating heaps of plastic waste, it could change its materials to something that is built to throw away and can be recycled. Perhaps in parts, or at the least as mulch.
Fast fashion is at a crossroads. The fashion industry should decide what pieces of clothing, or pieces of the clothing, should be made to last, to feel safe, to be conducive to health and well being and to be mendable when we grow to other needs. Other pieces of fashion are facade, temporary interface, expression or adornment.
Software development is at a similar crossroads. Some software should be built to last, is foundational, needs to be secure, needs to be stored and documented to be maintained, needs to operate at scale, needs to be optimized and should not be re-imagined with every use, or even while using the software. Some software can have a long lifecycle with code that is compatible with being maintainable, scrutinized, transparent, secured, scaled.
Other code can be thrown away, because we don’t care for its long-term quality in the same way. If it breaks, or falls apart, it does not impact our life, mood, task or moment in time. It can be generated again. Or better: it can be re-imagined again, from a more precise intent, with a better understanding of context, quality, security and reliability.
The fast fashion software paradigm is about the ecosystem, so it’s bigger than just the coder’s perspective. The usual questions are too narrow: will AI replace developers, will AI code be good enough, will maintenance disappear? Those are relevant questions, but they are only part of the story.
The whole ecosystem of making software starts to move with the fast fashion software paradigm.
A digital product organization used to be built around creating products, features and content. Product managers defined roadmaps, designers made screens and flows, developers built and maintained code, testers checked quality, architects guarded structure, brand people guarded recognition and marketeers guarded commerce. All these roles were connected to the production of software as a relatively stable product.
With AI-generated software, the center of gravity moves toward the world in which the software is allowed to appear. Growing generative software is about world building as a strategic exercise. Brand, design systems, commercial intent, software architecture, security standards, reliability thresholds, data access and maintenance rules become less like documents around the product, and more like the actual production environment.
A brand is not only a logo, tone of voice or visual layer anymore. It becomes part of how generated software behaves. How it helps, how it explains, how it sells, how it refuses, how it handles uncertainty.
Growing generative software is about world building as a strategic exercise
A design system is not a collection of components. It’s a extraction of a design philosophy, the brand and usability sensibilities and still follow accessibility, usability and visual standards. Design is also strongly connected to brand, software architecture, platform choices and informed by commercial needs. It’s a system that communicates across machine and personnel.
Commerce is not just a funnel, a product page or a campaign. It becomes a bespoke generated interaction in a specific moment, informed by the rules about trust, pressure, responsibility and relevance. Just like software architecture is not only the structure of a built product, but a comprehensive guide on what to generate, connected platforms, exposed and used data, what external services are incorporated and what should never be improvised.
Maintenance also changes. Not every generated artifact deserves a backlog, documentation, refactoring and a roadmap. Some software components needs to be maintained for years. Other parts of the software needs to be regenerated tomorrow. Some software should disappear when the task is done.
This change in the way how products are build also changes the team, their roles and skills. We don’t need a team that makes features, but a team that creates the conditions for consistent and functional software to appear. A team that can do world building: defining the rules, behaviours, limitations, qualities and intentions of the product world.
We need a team that creates the conditions for consistent and functional software to appear
The craft does not disappear. It moves. It moves from building the thing to knowing, defining and maintaining the world that builds the thing.
Pace layering and fast fashion software, guess what?
If we take the perspective of pace layering we have traveled a long way, real fast. From its inception we regarded software as immovable architecture, to slightly movable and maintainable, to rapidly and iteratively improvable. And right now? Now we can just re-imagine some software, at a whim, in its entirety, each and every time we want to, because for some pieces of software it truly doesn’t seem to matter how much it changes.

But did all software move to the fashion layer? No. The perceived smartness, personality and malleability of the interface to most fundamental software has changed and like in the mashup era we can now combine more relevance from said fundamental platforms, located at the commerce and infrastructural layers.
The latter category, according to my podcast partner Ron Kersic, are CRM software, currency interchanges, operating systems, identity systems, healthcare systems, or the fundamental pieces of software that change slowly and are such an important part of our lives.
Such fundamental software is important because it doesn’t change too fast, and because we rely on its quality, speed and safety. We also still think we need a human in command until AI-generated software has grown from “good enough” to reliable and increasingly better. This might take a moment, if only because of our human nature.
Fast Fashion Software changed the software-building ecosystem because it weakened the old relationship between software and permanence.
For decades, software quality was tied to maintainability, stability, documentation at scale and accountability of change. Good software was software that could survive: extended, patched, scaled, secured and understood by the next team. AI-generated software changes that equation. If code can be generated quickly, cheaply and well enough for the task at hand, not every piece of software needs to be maintained. Some of it can simply be regenerated, re-imagined or thrown away.
Quality, in that sense, becomes more contextual and more honest. For foundational systems, quality still lives in reliability, safety and long-term maintainability. For Fast Fashion Software, quality lives more in relevance, immediacy, usefulness and replace-ability.
The software-ecosystem has changed because software now has two clocks: the slow clock of infrastructure and the fast clock of fashion.
The winners will be those who know which clock they are building for.