The Automation Lineage: From Spreadsheets to Intelligent Systems
February 27, 2026 by Asif Waliuddin
The Automation Lineage: From Spreadsheets to Intelligent Systems
I started building governance tools in the late 1990s.
Not because I planned to. Because the work demanded it. I was coordinating projects with dozens of dependencies and no shared tooling. Everyone tracked their piece of the work in their own way. Status lived in someone's head, or in a document no one could find, or in a meeting that happened last Tuesday.
The fix was a spreadsheet.
Not elegant. Rigid. Impossible to query. But it worked: a single place where everyone could see the same information, formatted consistently, updated on a shared schedule. The coordination problem didn't go away. It became visible, which is the precondition for solving it.
That was the first chapter. There have been four.
Chapter One: The Spreadsheet (1998-2004)
The dot-com era was the first time many organizations ran large-scale software programs, and most of them were not prepared for the coordination overhead.
My first serious governance tool was an Excel workbook: project status, dependencies, resource allocation, risk log. One tab per workstream. One color code per status. Weekly update, distributed by email to sixty people.
It was manual, fragile, and insufficient. And it was better than what it replaced, which was nothing — or worse, conflicting versions of nothing.
The insight the spreadsheet taught me was not about spreadsheets. It was about coordination infrastructure: the value is not in the format or the tool. The value is in the shared context that the format enables. When sixty people look at the same status board, they stop asking each other questions that the board already answers. That freed up the meeting time for decisions instead of status updates.
Every version of this principle I've applied since then traces back to that spreadsheet.
Chapter Two: The Access Database (2004-2010)
Spreadsheets have a scaling problem. Around fifteen concurrent editors, they become unreliable. Around fifty rows of complex interdependencies, they become unreadable. Around three years of historical data, they become unusable.
The move to Access databases (and later SQL Server backends) wasn't about sophistication for its own sake. It was about encoding rules into the system.
A spreadsheet can record that a task is "In Progress." An Access database can enforce that a task cannot move to "Completed" without a reviewer assigned. It can enforce that a dependency cannot be marked "Resolved" without the dependent task acknowledging the resolution. It can enforce that a risk cannot be "Closed" without a mitigation strategy documented.
Rules that previously lived in process documents, or in someone's head, or in a meeting where someone said "we don't do it that way" — those rules got encoded into the system. Not as documentation. As constraints that the system enforced.
This was my first direct experience with the principle that would shape everything I built afterward: governance is only real when it's intrinsic to the workflow, not bolted on as a review process.
Chapter Three: Power Automate (2010-2019)
The shift to workflow automation was the first time I could encode not just rules but responses.
Power Automate (and its predecessors in the enterprise automation space) made it possible to say: when this condition is met, take this action. When a task moves to "Blocked," notify the dependency owner automatically. When a risk is escalated, create a review item in the portfolio board. When a project reaches 80% budget consumption, generate a variance report.
The human coordination work that previously happened in email threads and weekly meetings started moving into automated flows. Not because the judgment was automated, but because the information routing was.
This is the distinction I spent years explaining to stakeholders who worried about automation replacing human decision-making: automation handles the information routing. Humans handle the decisions. The goal is to ensure that the right information reaches the right person at the right moment, with enough context to make a good decision without having to go gather it themselves.
The ten-year run with workflow automation taught me something that turned out to be directly relevant to AI development: the hardest part of automation is not the automation itself. It's the governance of the automation. What happens when two automated flows conflict? What happens when an automated action triggers a condition it wasn't designed for? What's the visibility into what the automated systems are actually doing?
These questions have straightforward answers in mature workflow automation. They are entirely unresolved in most AI development workflows.
Chapter Four: Forge (2025-present)
In 2023 and 2024, I watched the same coordination failures I'd spent two decades solving appear immediately in AI-native development.
Claude Code refactors a module. Codex CLI updates tests against the pre-refactor interface. Both save. Tests fail. Neither tool knows the other exists.
Knowledge captured in one Claude Code session evaporates before the next session starts. Decisions made during a refactoring sprint are invisible to the tools running the test suite. Governance that everyone agrees on gets applied inconsistently because it depends on the developer remembering to run a separate check.
These are not new failure modes. They are the spreadsheet-era failure modes with a faster execution substrate.
The spreadsheet fixed information silos with shared context. The Access database encoded rules into constraints. Power Automate moved information routing from email threads into automated flows.
Forge encodes coordination infrastructure into the AI development workflow:
- The knowledge flywheel replaces the spreadsheet: shared context that every AI tool can read and write.
- The governance hooks replace the Access constraints: rules that can't be bypassed because they're intrinsic to the workflow.
- Drift detection and the Orchestrator replace the workflow automation: information routing that ensures the right context reaches the right tool at the right moment.
The product is different. The underlying problem is the same one I've been solving for 23 years.
What the Lineage Shows
Looking at these four chapters together, a few things become clear.
The tools changed. The coordination problem didn't.
Every chapter produced a tool that was more capable and more intrinsic to the workflow. Spreadsheets were bolted on. Databases were integrated. Workflow automation was embedded. Forge is intrinsic — it runs as part of the session, not as a post-processing step.
The underlying principle also didn't change: governance is only real when it's part of the work, not a review process that happens afterward. The spreadsheet made status visible. The database encoded rules. Power Automate automated routing. Forge runs governance during generation, before the code reaches production, before the coordination failure has time to compound.
The people who built these tools didn't need to understand every technical detail of every automation platform. They needed to understand the coordination problem clearly enough to encode it into something repeatable. That's the job.
Every era, the same job. Every era, a more capable tool.