We Already Solved This Problem in 1998. AI Is Bringing It Back.
How AI and automation are helping businesses move faster, while quietly recreating the ownership and understanding problems we spent years learning how to solve.
Over the last year I have noticed a pattern across conversations with founders, operational leaders and product teams. The tools change each time, but the underlying problem keeps turning up wearing new clothes.
One business is experimenting with ChatGPT, Claude and Copilot. Another is building workflows in n8n, Make or Zapier. Others are joining Airtable, HubSpot, Gorgias, Notion, GitHub, Linear and a growing pile of SaaS platforms together through automation, with a few AI agents and custom scripts sitting quietly in the background, holding pieces of the business together that used to be manual or dependent on one person knowing what to do next.
Most of these conversations start positively, and rightly so. Teams are moving faster. Repetitive work is disappearing. Internal processes that used to take hours now take minutes. I use these tools myself, and Jawwws actively helps organisations find where AI and connected workflows create genuine operational value. The productivity gains are real and the excitement is understandable.
What I have started noticing is that a lot of organisations are becoming very good at creating automation without putting the same effort into understanding it. And underneath that, something quieter: nobody is really taking ownership of the system as a whole.
At first this does not feel like a problem. When a workflow is new, the person who built it understands it. The prompt is fresh. The Zapier zap or the n8n scenario makes sense because the thinking behind it has not faded yet. Sending data from one platform to another, transforming it, triggering a notification, updating a record, asking an AI tool to summarise the result, all of it feels perfectly logical at the time.
Six months later it often looks different. More workflows have been added. New prompts have crept in. Different people have made their own improvements. A process that began as one automation now has three branches, two exceptions, a manual fallback and a Notion page that may or may not still describe how it works. A temporary fix has become permanent because nobody remembers why it was temporary. The result is a collection of useful automations that individually make sense and collectively become very hard to explain.
A team that did almost everything right
Recently Jawwws worked alongside a team building a gaming platform. They had done a lot right. They were talented, motivated, and using modern tools in ways that let them move far faster than they could have a few years ago. Between Unity, GitHub, Figma, Airtable, Notion, Linear, Zapier, Make, n8n and several AI tools, they had built an impressive operational ecosystem.
Each person was solving problems in their own area. One owned backend systems. One owned operational workflows, CRM and customer support. One owned the game itself inside Unity. They had weekly conversations about goals and tooling, so this was not a team working in isolation.
The issue was more subtle. They had alignment around activity, but not enough shared ownership of the system as a whole. Each person had their own prompts, their own AI habits, their own workflows. Each part made sense from the perspective of the person who built it. What nobody owned was a clear, shared understanding of how the whole thing fitted together.
That distinction matters more than it first appears. Owning a task is easy and natural. Owning the connective tissue between tasks, the way one person's workflow quietly becomes another person's dependency, is the part that tends to fall to nobody. It is not glamorous, it does not ship a feature, and it rarely has a name on it. So it drifts.
For a while that was fine. The output was good enough to create momentum. New capability appeared almost weekly. The system was producing maybe sixty percent useful progress and forty percent quiet stress, which is a ratio plenty of growing teams will recognise, with or without AI in the mix.
Then one person went on holiday.
A workflow stopped behaving as expected. Someone else used AI to investigate and apply a fix. The fix solved the immediate problem and created a side effect somewhere else. Another adjustment followed, then another. By the time the original developer came back, the platform still worked and the automations were still delivering value. Nothing had exploded in the dramatic way people imagine when they talk about technology failing. But nobody could confidently explain what had changed, why, or how several parts of the system now interacted.
That is the part I find most interesting. They had not created a technical disaster. They had created an understanding problem. And understanding problems are often more dangerous than obvious failures, because for a while they still look like progress.
This is not really an AI problem
It would be easy to read that as a warning about AI, but I do not think that is the right conclusion. AI did not create the behaviour. It accelerated it.
Businesses have always created complexity when tools get cheaper and easier. In the late 1990s and early 2000s it showed up as spaghetti code, undocumented integrations, lonely Access databases, shared spreadsheets and business-critical scripts that nobody dared touch because one person understood them. Today the same pattern wears a more modern outfit: SaaS platforms, AI tools, workflow builders, APIs, prompt libraries and low-code automations. The architecture diagram looks contemporary. The operational risk feels very familiar.
The mistake is believing that because something can now be built quickly, the business no longer needs the disciplines that used to sit around technology and change. That belief is understandable, especially for founders under pressure to move fast and compete with bigger organisations. AI shrinks the distance between idea and execution, and it can give a small team capability that used to require a much larger one.
For operational leaders the pressure is different but just as real. They are often told to "use AI" without much clarity on what that means, asked to find efficiencies and modernise workflows while still running the existing business and supporting people who are already stretched. In that environment automation quietly becomes a release valve for pressure rather than part of a considered strategy. And automation created under pressure tends to solve the visible symptom rather than the underlying process. AI then makes it easy to produce more of those fixes, faster, with less friction. It looks impressive from the outside while becoming harder to understand from the inside.
This is the maturing edge of the AI conversation, and the gaming industry is a good place to watch it. GameDeveloper has reported a real tension in the sector: tool vendors and large companies position generative AI as a way to streamline production, while plenty of working developers worry it lowers quality and adds ambiguity to how things actually get made. Leaders see speed and leverage. Teams often experience pressure and uncertainty.
It is not only games. Finance is asking the same question through governance and auditability, as AI moves into decisions that need human oversight and a clear trail of who was responsible for what. Print is asking it through workflow and production reliability, as automation reaches deeper into estimating, prepress and the parts of a job where a quiet error becomes an expensive one. Different industries, same underlying worry: as the tools get more capable, can we still explain what we have built? That gap, between what a system does and what anyone can account for, is exactly where the trouble collects.
The new operational debt
Most technology leaders know the idea of technical debt: the cost a business takes on when it makes short-term decisions it will need to revisit later. Debt is not always bad. Sometimes a little is sensible if it helps you learn or ship. The problem is never the existence of debt. It is whether anyone knows it exists and has a plan for it.
We are now seeing a related kind of debt form around AI and automation. Much of it does not live inside a codebase, so it does not behave like classic technical debt. It lives across prompts, workflows, integrations, SaaS configuration, permissions, shared documents and unwritten assumptions. It is operational debt.
And it is really a debt of ownership. Operational debt accumulates when a business creates process complexity faster than it creates shared understanding, which is another way of saying it accumulates wherever nobody has taken responsibility for the whole. It appears when a workflow exists because one person knew how to make it work and nobody else can maintain it. It appears when Zapier, Make, n8n, Airtable, HubSpot, Notion, Slack and GitHub each hold a piece of the same process, but no single person can describe the journey from trigger to outcome. It appears when an AI-generated script becomes business-critical without being reviewed, documented or owned.
Like technical debt, it rarely looks like a problem at the point it is created. It looks like progress. A manual step disappears. A report arrives on its own. A ticket is summarised. Everyone reasonably moves on to the next thing.
The cost shows up later, usually when something changes. Someone leaves. Someone goes on holiday. A vendor updates an API. A prompt starts producing slightly different output. And it rarely arrives as downtime. It arrives as hesitation. People get nervous about changing things. Teams lean on AI to keep correcting workflows they no longer fully understand. Small modifications need long investigations. The system still works, but it stops feeling safe. That is an expensive place for a growing business to sit, because confidence is one of the things that lets a team move quickly in the first place.
What this actually takes to fix
With the gaming team, the work was not really technical, or not only technical. The platform functioned. What was missing was a shared picture of the system, someone holding the whole, and a way to keep that picture current as the business kept changing.
Some of it was reading the code, and some of it was reading the room. We unpicked a few of the workflows by hand to work out what they were genuinely doing rather than what people assumed they did. We looked at how the team was actually using AI day to day, and advised on prompting methods so that the tools produced something consistent and explainable rather than a slightly different answer each time. A surprising amount of it was simply people: who felt responsible for what, who had quietly become the single point of failure, and why nobody had felt able to own the parts that sat between them. That part is less about technology than it looks. It is team management and a bit of psychology, and it is usually the hardest piece, because the gaps between people are exactly where the system had gone undocumented.
There is an odd parallel here, and it is the reason the year in the title is not just nostalgia. When Ocarina of Time moved the Legend of Zelda series into a bigger, fully three-dimensional world in 1998, the thing that actually made it playable was not more power or more content. It was a way to lock onto what mattered and keep your bearings while everything else moved around you. That is more or less the job here too. The leap into a faster, more capable world is only really won once people can keep their orientation inside it.
Alongside the people work we walked the whole thing end to end and wrote down what nobody had ever written down. Where each process started, what it touched, which system was the source of truth, what happened when a step failed, and crucially, who owned it. Not a grand architecture document destined to be ignored, but something light enough that the team would actually maintain it. We separated the genuine experiments from the things that had quietly become infrastructure, and set a simple rhythm for reviewing the workflows that mattered most.
The point was never to slow them down. It was to give them their confidence back. Once the system was visible and owned, they could change things again without flinching, which is the whole reason they had reached for these tools to begin with.
What we left behind was less a fixed process than a habit. Build carefully enough to move, but keep observing. Automate where there is value, but keep asking whether each piece still earns its place. Use AI to accelerate the work, and keep human judgement around the system. Document what matters. Share what one person knows. Make sure someone, by name, owns the whole and not just their corner of it. We have continuous development as an idea in software. This is its quieter, more grown-up cousin: continuous understanding.
That mindset is not new. It is how good software has been built for years, how strong operations teams improve, how manufacturing matures. AI does not remove the need for that kind of care. It raises the importance of it, because change now happens faster than the understanding can keep up on its own.
The real opportunity
AI and automation let smaller businesses compete in ways that used to be out of reach. They reduce the manual glue that holds so many operations together. Used well, they help an organisation see itself more clearly.
But the opportunity is not to connect everything together. It is to build businesses that understand themselves better, and that starts with someone deciding the whole is theirs to understand. A business that understands its workflows can improve them. A team that understands its systems can trust them. A founder who understands how the operation really works can make better decisions about where to invest, where to automate and where to simplify.
Used carelessly, AI does the opposite. It hides complexity behind a smoother interface. Today the language is agents and MCPs. Tomorrow it will be something else. The fundamentals stay surprisingly familiar. Understand the process. Know who owns it, and make sure that someone is genuinely you or someone you trust, not the gap between three people. Make the system visible. Review it. Keep people involved where judgement and context matter. Let automation accelerate what is already understood, rather than disguise what is not.
We learned this lesson once already, through years of tangled applications and fragile systems nobody wanted to touch. We survived most of it back then, partly because the systems moved slowly and the blast radius was usually small. AI gives us a chance to do it properly this time. It also removes the excuse, because nothing moves slowly any more.
Building faster is not the same as understanding more. And in a business moving this quickly, the question worth sitting with is a simple one: who actually owns how the whole thing fits together?