Over the years I've tried a lot of organisational models. Standups. Retrospectives. Timesheets. Sprint planning. The full suite.
At eXOReaction, we've converged on something different. It's not a framework with a name. It's more a set of positions — things we've decided, and held to, even when they make people uncomfortable.
In 2017 I wrote a short piece out of frustration — a street-smart survival guide for developers tired of missing deadlines despite giving themselves plenty of time. Eight years later the problem hasn't changed. If anything it's worse: we have more tools, more planning methods, more retrospectives, and we still end up in last-minute panic on projects we thought we had under control.
I revisited the original piece in November 2025 with a bit of help from AI — research, narration, the lot. Here's the framework, written out properly.
In late 2024 and through 2025, we published a series of short horror stories about building with LLMs. Not fictional in the sense of being made up — fictional in the sense of being slightly dramatised versions of things that happen, or will happen, or already have happened to someone you know.
The format was deliberate. Security warnings written as dry checklists get skimmed. Security warnings written as campfire stories get remembered.
Here are all eight tales.
Most data systems are built to forget.
Not deliberately. It's just the natural consequence of how databases work. When you update a customer's address, the old address is gone. When you change a product price, the previous price is gone. When a process state changes, the prior state is gone.
Each of those deletions also deletes something else: the why.
Here's a question most organisations can't answer: what was Pump 47's vibration reading before it failed?
Not a complex question. A specific measurement, at a specific point in time, for a specific piece of equipment. But in most asset management systems, if that reading was overwritten when the failure was logged, it's gone. The data archaeology required to reconstruct it — if it's possible at all — involves manual investigation across multiple systems, log files, and human memory.
The same pattern applies everywhere.
The hardest part of analytics isn't the analysis. It's getting the data there in the first place.
Most organisations have data in a dozen places. ERP systems. HR platforms. CRM. Custom databases. Real-time event streams. Legacy systems that predate modern API design. Getting all of that into a consistent, queryable format is the project that takes eighteen months and still isn't finished.
Xorcery AAA is built around two components that solve this problem together.
Most databases have amnesia.
They know what things look like right now. Change something, and the old state is overwritten. The database has no memory of what existed before, no way to ask "what did this look like on the 15th of March?", no record of who made the change or why.
This is fine for most use cases. It's a serious problem when the question you need to answer is historical.
Every organisation I've worked with in the last decade has the same problem.
They're drowning in data. Dashboards for everything. Metrics to the decimal point. And when something goes wrong — when performance dips, when people leave, when costs spike — they look at the charts and they still don't know why.
Most software systems were designed for a world without AI.
Not in the sense of lacking ML features — in the deeper sense of having an architecture shaped by assumptions that AI changes. Assumptions about where intelligence lives, what questions systems should answer, what "the right data model" looks like.
Those assumptions are worth examining.
Frøya describes herself as a cartographer of potential — not as the QA manager she was built to be.
The distinction is instructive. A QA manager checks definitions against standards. A cartographer is always working at the edge of the known, building the map as the territory reveals itself.