待翻译：AI artefacts are the new Access databases

AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。

If you have worked in IT for a while, you have probably at some point inherited an Access database, or certainly something that resembles one. It was built years ago by someone in Finance, HR, or some other operations part of the business. It started as a quick shim to keep track of something the pre-existing systems did not handle well. Then over time it gained some new forms, some reports, a little bit of Visual Basic, and before anybody paid too much attention, it became critical to running the business. Then the person who made it moved on. Nobody really understood how it worked. There was not any documentation. It just worked. And this thing persisted through waves of hires and changes in the business, and people just knew how to use it because of institutional knowledge. It lived on a shared drive somewhere with a filename that resembled Customer Database FINAL v6.accdb. Every few months it corrupted itself, stopped accepting new records, or produced a report that did not quite match Finance. When that happened, somebody from the IT team would be summoned to fix an application they never built, never approved, and until that morning probably did not even know existed. It is easy to look back and blame Microsoft Access, but I do not think Access itself is the problem. Access was brilliant. It gave regular folks the ability to solve real business problems they were encountering without having to wait for some IT project to happen six months later. It allowed someone who understood the work, a domain expert in that area, to turn the understanding they held into a useful application for other people to benefit from. The problem is not that people were building things with Access back then. The problem was that the cost of building that software suddenly fell, which on the surface of it sounds great, but the way organisations govern software stayed exactly the same. These small, business-area-scoped applications fell outside of the governance framework entirely. Right now, we are doing it again. Only this time, the things people can create go beyond storing some customer addresses and printing reports. They talk to APIs. They update larger production systems. They potentially communicate with customers, maybe even in real time. They handle approvals. They might move money. They form views on the fly from policy. And they are fundamentally making decisions on behalf of the business. We have been through this cycle before Access was one wave, but it was not the first and it obviously was not the last. This will be very familiar to anyone who has encountered Excel macros, SharePoint workflows, or low-code platforms such as Power Apps. Each time one of these waves arrived, it compounded the ability of individuals across the business to create more and more complex outcomes with less and less friction. Each wave lowered the barrier to creating software. Each created enormous value. Each also created a new category of mess for somebody else to clean up later. So, again, the tools are not the things failing here. They are the enablers. They succeeded so well that organisations could barely keep up with the volume of things being created. The debt became visible later. A department might save hundreds of hours using a clever spreadsheet, but five years later, when that spreadsheet has become mission-critical and the author has left the company, you have an exposed and crystallised risk. Building a database in a week instead of waiting a year for a corporate system change is a totally rational decision, and not a problem to criticise. So it is very easy to describe these things as failures of governance, but I actually think they are failures of scale. The organisation has a process for governing ten large applications. It does not have a process for governing ten thousand small ones. AI changes the economics again So here we are once again, talking about AI and how it changes the economics. It is not quite comparable to these prior examples. It is not a low-code platform. What it does do is change the cost of producing software by at least one, possibly more, orders of magnitude. An individual no longer needs to understand database design, or Excel formulas, or VB scripting, or even the conventions of a low-code workflow in a tool like Power Apps. They can describe what they want in ordinary language and have a working version appear in front of them. They can speak in their own language to their own tame developer, who works without complaint and outputs exactly the product they requested. It will not always be good. It will not always be safe. It might not be particularly well designed. But it will tick each of those categories just enough to solve the immediate problem in front of them. It is very plausible when you think about it. You have an individual who notices that someone in their team is copying the same information between three different systems every morning. In the old world, they might raise this as a request with an IT team, or flag it to their manager. Today, they can describe that problem to their AI assistant at the moment they notice it, and maybe fifteen minutes later they have something usable that solves it. By the end of the week, an entire department is relying on it and has removed that scheduled entry from their calendar that drove the manual workflow. It never got labelled as a project. It might have come under some larger corporate-branded initiative such as AI transformation, but it would not even make sense to call it a project. Projects make sense when delivery takes place over weeks to months and costs a material amount upfront. If a new system required a team of engineers, a six-month delivery timeline, and substantial CapEx investment, it makes sense to wrap it in governance. You need requirements, funding, milestones, and a clear decision to begin. You end up with steering committees. But what happens when the first working version takes fifteen to thirty minutes? It is not that the need for governance has disappeared. It is that the economics that allowed, and even forced, governance to sit in front of the process have disappeared. There is no way people would tolerate every AI-generated workflow or app going through an approval cycle. People will simply go around it, and you can totally understand why. It is the classic water-goes-around-the-rock problem. But you also cannot pretend these things are harmless just because they were quick to build. An automation that took twenty minutes to create can still delete a customer record. It can still email thousands of people incorrect information. It can still contain business logic that determines whether somebody gets paid their commission that month. I would actually argue that the effort required to build something has never really been a reliable measure of its importance, and I have written before about how easily a personal productivity win gets mistaken for an operational system. Right now, AI is making that gap simply impossible to ignore. Software has become disposable The other big change here is that software has become a disposable commodity. It sounds like hyperbole, or LinkedIn clickbait, to put it that way. But I find myself regularly talking right now about being absolutely fine, more okay than I ever have been, with disposable work to patch a short-term problem. For most of IT history, software was treated like an asset, partly because it was expensive to produce. You maintained it because rebuilding it would be costly. You documented it because a replacement team would need to understand it. You planned upgrades because the application was expected to survive for years. That assumption simply does not stand true anymore. It began to weaken when the SaaS model appeared on the scene, but it is completely shattered at this point. There are totally plausible scenarios now where a department might not even consider upgrading their existing internal application. They are just going to ask AI to create a new one. A workflow might exist for three weeks to support a temporary process and then be discarded. Several teams might independently generate slightly different solutions to exactly the same problem, because creating another one is easier than discovering and adapting the first to accommodate them. So I stand by it. Software is disposable now. With one hat on, that can feel very liberating. There are thousands of valuable ideas inside businesses today that are not worth turning into traditional software projects, and AI makes them all viable all of a sudden. But disposable does not mean consequence-free. A disposable paper cup is simple because nothing else depends on it. Software very quickly becomes connected to people, systems, data, and decisions. It might be easy to create, but the moment someone starts relying on it, it has got weight. It is now structurally load-bearing to the company. The code might be disposable. The consequences are not. The new technical debt is not the code Everyone tends to harp on about AI-generated software’s main risk being poor-quality code. There is definitely going to be plenty of poor-quality code out there. I have generated a substantial amount of it myself, frankly in the last twenty-four hours, given how accessible these tools are. I am just not convinced it is the biggest problem. Code can be reviewed and tested. Now it can just be regenerated. If you understand the problem, you ask the AI a more refined question. The hard questions now are different. Who owns it? Who knows it exists? What identity is it operating as? What permissions have you given it? What systems can it access? What data does it retain? What model is it using? What instructions was it given? What tools and connectors can it call? What happens when the person who created it leaves? What else depends on it? And who would know if it started behaving incorrectly? This new class of technical debt has nothing to do with code. It is more about AI prompts, agent definitions, tool permissions, workflow connections, embedded policies, and undocumented assumptions. It is the gap between what an AI agent is technically capable of doing and what everyone believes it is supposed to do. In some cases, the source code may well be the least interesting part of the system. The business logic will be spread across all of these natural-language instructions, examples, knowledge sources, model behaviour, and the permissions granted to a collection of tools. That is a totally different class of problem to reason about than a badly written Visual Basic macro, and it is why I think the enterprise AI fight is really about the harness — the connectors, identity model, and governance around the model — rather than the model itself. Shadow AI will not look like Shadow IT In some ways this problem resembles the classic shadow IT problem. Shadow IT generally appears because a central IT team cannot move quickly enough to respond to demand. People would buy their own SaaS tools, create spreadsheets, and build databases because the official route was too slow, too expensive, or too disconnected from reality. Shadow AI emerges for a slightly different reason. It is not just that an IT team cannot build things quickly enough. It is that everyone can build things so quickly that nobody can keep count. If the shadow IT problem was a capacity issue, the shadow AI problem is a visibility issue. If anything, capacity is now almost a non-issue. I am reasonably confident that my current employer, for example, while it has hundreds of approved applications, already has tens of thousands of small AI-created artefacts operating between the cracks. Some of them are agents, sure, but some are workflows. Some will be scripts that were generated by an AI for a single task. Some will be persistent instructions sittin [truncated for AI cost control]