{"slug": "ai-artefacts-are-the-new-access-databases", "title": "AI artefacts are the new Access databases", "summary": "The falling cost of building software with AI agents is creating a new wave of ungoverned, business-critical applications that nobody owns or documents, echoing the legacy of Microsoft Access databases, according to an essay by an unnamed IT professional. The author argues that each wave of low-code tools, from Access to Excel macros to Power Apps, has enabled domain experts to create valuable but unaccounted-for systems, and AI agents now extend this to making decisions and moving money, posing significant risks. The piece warns that organizations' governance frameworks have not kept pace with the scale of creation, leading to hidden operational debts.", "body_md": "# Your Next \"Access Database Problem\" Is an AI Agent\n\nAI has collapsed the cost of building software again, and the debt this time will not be bad code but agents nobody owns, knows about, or can account for.\n\n16 min read\n\nIf you have worked in IT for a while, you have probably at some point inherited an Access database, or certainly something that resembles one.\n\nIt 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.\n\nThen the person who made it moved on.\n\nNobody 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.\n\nIt lived on a shared drive somewhere with a filename that resembled `Customer Database FINAL v6.accdb`\n\n.\n\nEvery 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.\n\nIt is easy to look back and blame Microsoft Access, but I do not think Access itself is the problem.\n\nAccess 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.\n\nThe 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.\n\nRight now, we are doing it again.\n\nOnly 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.\n\n## We have been through this cycle before\n\nAccess was one wave, but it was not the first and it obviously was not the last.\n\nThis 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.\n\nEach 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.\n\nSo, 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.\n\nThe 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.\n\nBuilding 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.\n\nSo it is very easy to describe these things as failures of governance, but I actually think they are failures of scale.\n\nThe organisation has a process for governing ten large applications. It does not have a process for governing ten thousand small ones.\n\n## AI changes the economics again\n\nSo here we are once again, talking about AI and how it changes the economics.\n\nIt 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.\n\nAn 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.\n\nIt 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.\n\nIt 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.\n\nBy 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.\n\nIt 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.\n\nProjects 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.\n\nBut what happens when the first working version takes fifteen to thirty minutes?\n\nIt 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.\n\nThere 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.\n\nBut you also cannot pretend these things are harmless just because they were quick to build.\n\nAn 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.\n\nI 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](/writing/no-your-agent-skill-is-not-automation/) about how easily a personal productivity win gets mistaken for an operational system. Right now, AI is making that gap simply impossible to ignore.\n\n## Software has become disposable\n\nThe other big change here is that software has become a disposable commodity.\n\nIt 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.\n\nFor 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.\n\nThat 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.\n\nThere 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.\n\nSo I stand by it. Software is disposable now.\n\nWith 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.\n\nBut disposable does not mean consequence-free.\n\nA 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.\n\nThe code might be disposable. The consequences are not.\n\n## The new technical debt is not the code\n\nEveryone tends to harp on about AI-generated software’s main risk being poor-quality code.\n\nThere 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.\n\nCode can be reviewed and tested. Now it can just be regenerated. If you understand the problem, you ask the AI a more refined question.\n\nThe hard questions now are different.\n\nWho owns it?\n\nWho knows it exists?\n\nWhat identity is it operating as?\n\nWhat permissions have you given it?\n\nWhat systems can it access?\n\nWhat data does it retain?\n\nWhat model is it using?\n\nWhat instructions was it given?\n\nWhat tools and connectors can it call?\n\nWhat happens when the person who created it leaves?\n\nWhat else depends on it?\n\nAnd who would know if it started behaving incorrectly?\n\nThis 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.\n\nIn 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.\n\nThat 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](/writing/gen-5-ai-enterprise-harness-war/) — the connectors, identity model, and governance around the model — rather than the model itself.\n\n## Shadow AI will not look like Shadow IT\n\nIn some ways this problem resembles the classic shadow IT problem.\n\nShadow 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.\n\nShadow 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.\n\nIf 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.\n\nI 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 sitting around as agent skills being shared amongst the sales team. Some are AI snippet outcomes that exist inside larger SaaS products like Salesforce or ServiceNow. Some are going to live on people’s laptops. Some of these things will simply be long-lasting chats shared between a group that were never formally named at all.\n\nI am absolutely confident that the industry’s current application inventory paradigm is not designed for this world. Neither are our architecture boards, change boards, planning cycles, or steering committees.\n\nThey all assume that this work has a beginning. A project formally starts, something is delivered, and the organisation records what now exists as a consequence.\n\nBased on my experience so far, AI-created software often does not even have an obvious beginning. It emerges at some point from the work being done in these new tools, as a consequence.\n\n## Banning it will fail\n\nSo, now onto the so what.\n\nYou can imagine some people are going to have the reaction of, well, let’s just ban it, or restrict creation in some way.\n\nThat would be a mistake.\n\nIt was a mistake to treat every spreadsheet as a threat. It was a mistake to assume every departmental database should have been replaced by a multimillion-pound enterprise system. It would be a mistake to force every AI-created workflow through the same process as a major company-wide application.\n\nThe value in these tools comes from allowing the people closest to a problem to solve the problem.\n\nThe answer cannot be to restore scarcity back into the system. The answer has to be governance that works under abundance. We have to move governance away from permission to create, and towards the conditions under which created things can operate.\n\nJust to declare an interest here: this is not a theoretical position for me. [My role at Pax8](/writing/new-role-svp-workflow-engineering-pax8/) exists to operate and govern exactly this kind of citizen development ecosystem, which means providing the tools and guardrails that let people build quickly without the organisation losing track of what now exists.\n\nEverything below is easier to write down than to run.\n\n## Make the easy path the correct path\n\nThe thing for me is about making the easy path, the happy path, and the correct path all the same thing.\n\nYou want people’s path of preference to self-steer down the one you want. There is a UX challenge here, amongst other things, and I do not think we talk about it that way often enough. Governance gets designed as a set of rules to be complied with, when it should be designed as the route of least resistance.\n\nI have written about this before in a completely different context. One of [the rules I try to do business by](/writing/the-rules-i-try-to-do-business-by/#make-it-easy-to-do-business-with-you) is to make it easy to do business with you, and the argument there was that every piece of friction should have to justify its existence. What I said about friction then applies exactly here: people stop asking for help, they work around the official process, they keep their own spreadsheets, or they buy software on a company card.\n\nThat is shadow IT described in advance. Shadow AI is the same behaviour with the barrier lowered again.\n\nSo if the governed route is slower, uglier, or harder to find than opening a chat window, you have already lost. Not because people are reckless, but because you have made the correct path the expensive one.\n\nIn practice, that means the platform has to do the work rather than the person:\n\n- Identity should come for free. If the natural place to build something already knows who you are, nobody has to be persuaded to authenticate properly.\n- Organisational credentials should be the easiest credentials to reach for, so that using a personal account is the awkward option rather than the default one.\n- Permissions should be legible at the point of creation, not buried in an admin console that somebody visits a year later during an audit.\n- Tool calls should be logged by the platform itself, so that observability is not something anyone has to remember to add.\n- Ownership should be captured at the moment of building, while somebody is there to answer the question, rather than reconstructed afterwards from commit history and guesswork.\n- Registration should be a by-product of building, not a separate form that a person has to be chased to complete.\n- Expiry should be the default, so that keeping something alive is the deliberate act rather than the accidental one.\n- Existing solutions should surface at the moment of creation, so that somebody sees the seventeen versions that already exist before they build the eighteenth.\n\nNone of that stops anybody building anything. That is the point. People should be able to experiment freely with low-risk data and actions, and the moment something connects to a production system, affects another person, or begins making consequential decisions, stronger controls should appear automatically. It is the same threshold I described in [the shape of agentic work](/writing/the-shape-of-agentic-work/): agents that touch real systems need to be embedded, policy-guided, and observable, not merely clever.\n\nThis is less like traditional project governance and more like building roads, signs, and traffic rules. You do not approve every journey before someone gets in a car. You create an environment in which millions of journeys can happen without constant central intervention.\n\nThat is the challenge enterprise technology teams now face.\n\nNot how to stop people creating software.\n\nHow to make rampant software creation safe enough to become normal.\n\n## The Access database was a warning\n\nI do not think we should remember the Access era as a disaster.\n\nAn enormous amount of useful work was done in those databases.\n\nThey filled gaps that expensive corporate systems ignored. They allowed people to improve their own work. They proved that software creation did not have to belong exclusively to professional developers.\n\nThe mess came because our organisations did not adapt to the abundance Access created. We treated each database as an isolated oddity rather than recognising that the cost of software production had changed.\n\nThen we repeated the same pattern with spreadsheets, SharePoint workflows, and low-code platforms.\n\nAI is the next wave, but it is not just a slightly easier version of what came before.\n\nThe scale is different.\n\nThe speed is different.\n\nMost importantly, the software can act.\n\nWe are entering another Access database era, except this time the databases can read our policies, call our systems, make decisions, and talk to our customers.\n\nThe organisations that succeed will not be the ones that prevent this explosion.\n\nThey will not even necessarily be the ones that create the most.\n\nThey will be the ones that understand a fairly uncomfortable truth early enough:\n\nWhen software becomes almost free to create, building it is no longer the hard part.\n\nKnowing what exists, what it can do, who is responsible for it, and whether anyone should still trust it becomes the real work.", "url": "https://wpnews.pro/news/ai-artefacts-are-the-new-access-databases", "canonical_source": "https://sjg.io/writing/your-next-access-database-problem-is-an-ai-agent/", "published_at": "2026-08-05 09:07:04+00:00", "updated_at": "2026-08-05 09:22:17.669832+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-policy", "ai-ethics"], "entities": ["Microsoft Access", "Excel", "Power Apps", "SharePoint"], "alternates": {"html": "https://wpnews.pro/news/ai-artefacts-are-the-new-access-databases", "markdown": "https://wpnews.pro/news/ai-artefacts-are-the-new-access-databases.md", "text": "https://wpnews.pro/news/ai-artefacts-are-the-new-access-databases.txt", "jsonld": "https://wpnews.pro/news/ai-artefacts-are-the-new-access-databases.jsonld"}}