From Frameworks to Prompts: Rethinking Reusable Software in the Age of AI
andre
There was a time, not so very long ago, when building software meant assembling it by hand from reusable parts. If you wanted to launch a shopping website, you did not begin with a blank text editor and a prayer. You reached for a framework. You configured a catalogue module, bolted on a shopping cart, wired up a checkout pipeline, and spent a wearying number of evenings squinting at documentation for payment gateway integrations. Behind the customer-facing storefront sat an equally demanding apparatus: order queues, label printing, returns handling, customer history, discount engines, promotional rules. The list of concerns was long, and each one needed attention before a single sale could be completed.
Frameworks existed to absorb that burden, and they did so reasonably well for a while. Their fundamental weakness, though, was one of scope. A framework designed by experienced engineers with the best of intentions will almost inevitably try to serve every plausible user. The consequence is bloat. Consider the gulf between two shopping sites. One might resemble a marketplace on the scale of Amazon or eBay, hosting millions of product types from countless independent sellers, each with distinct ratings, fulfilment preferences, and order workflows. The other might sell a single handcrafted item, or perhaps a digital subscription, from one person working out of a spare room. A single codebase expected to accommodate both extremes will be riddled with conditional branches, configuration toggles, and abstraction layers that exist solely to paper over the incompatibility of those use cases. The result is software that is technically comprehensive yet intuitively hostile. You spend more time disabling features you do not need than enabling the ones you do.
By 2026 the calculus has shifted. AI-assisted development has made even moderately complex software tasks accessible to people who would previously have needed a team and a six-month timeline. Standing up a shopping website is no longer an engineering moonshot; it is a Tuesday afternoon. The temptation, then, is to discard the old frameworks entirely. Why wrestle with an over-engineered, half-maintained codebase when you can open a chat interface, describe what you want, and watch functioning code materialise in minutes?
The temptation is understandable, and the reality is messier. AI can produce remarkable output, but it cannot read your mind. You must articulate what you want, and articulation is where most people falter. The picture in your head is vivid: you can see the layout, feel the checkout flow, sense the tone of the confirmation email. Translating that mental image into precise, unambiguous prose is a different skill altogether, and one that many otherwise capable people have never had to develop. Even seasoned developers sometimes find themselves stuck, circling a description that never quite captures the behaviour they intended.
Beyond the difficulty of expression lies a subtler problem. If you have never built a shopping system before, you will not know what you do not know. Payment reconciliation edge cases. Fraud screening hooks. The unglamorous machinery of back-office order management. Accessibility requirements. Tax calculation across jurisdictions. Frameworks, for all their clumsiness, encoded decades of accumulated awareness about these concerns. They shipped the boring answers so you did not have to think of the questions. Strip the framework away and hand the task to a general-purpose AI, and you may well end up with a polished storefront sitting atop a system that quietly forgets to handle partial refunds.
The answer is not to return to the old model, nor to abandon structure altogether. What makes more sense is to replace the monolithic framework with a curated set of generalised AI instructions, sometimes called AI skills, tailored to a particular domain. Instead of shipping thousands of lines of configurable code that tries to anticipate every requirement, you ship a body of guidance that helps the AI and the user jointly discover what is actually needed. The instructions prompt the user to consider payment flows, returns policies, back-office tooling, and customer support channels, but they do so conversationally, adapting to the specific shape of the project rather than forcing it into a predetermined architecture.
This approach captures something genuinely useful from both worlds. The user is not locked into a rigid, ageing framework that handles eighty percent of the job competently and makes the remaining twenty percent a source of ongoing misery. Nor is the user cast adrift, expected to independently conceive of every subsystem a commercial website requires. The AI skills act as a knowledgeable collaborator, surfacing the mundane but essential tasks that a first-time builder would overlook, while leaving the actual implementation free to be as simple or as elaborate as the project demands.
None of this is particularly radical. Major AI companies already publish skill sets for common tasks, and third-party developers have produced thousands more. What I am proposing is a shift in how we think about those artefacts. For years, the unit of software reuse was the library, the module, the framework: a concrete artefact you imported, configured, and extended. In many domains that model still holds. Nobody should rewrite a graphics rendering engine or a cryptographic primitive every time they start a new project, and general-purpose libraries remain as valuable as ever. But for application-level tasks where the requirements are well understood in the aggregate yet highly variable in the specifics, where a custom solution is desirable but not prohibitively complex to generate, AI skills offer a leaner and more flexible substitute for the traditional framework. They preserve the institutional knowledge without calcifying it into code that even its original authors struggle to follow.
The frameworks had a good run. They carried an entire generation of software from conception to production, and they did it before any machine could write a line of code on your behalf. But their era was shaped by scarcity: scarcity of developer hours, scarcity of domain knowledge, scarcity of patience. Those scarcities are easing. What remains is the need to build things that fit, precisely and without excess, the problem in front of you. A well-crafted set of instructions handed to a capable AI gets you closer to that fit than any amount of configurable boilerplate ever did. The framework is not dead. It has simply learned to speak.