Everyone tells the same story about AI-assisted development. AI generates code fast, so you ship faster. Straightforward. Compelling. Wrong.
The actual productivity gain from AI does not come from generation speed. It comes from verification infrastructure that makes it safe to accept AI output at scale. The counterintuitive truth: the team that writes the most tests ships the fastest. Not despite the testing. Because of it.
The plan was to spend a weekend validating whether a complete PCB design library was actually buildable at AI velocity.
Not a prototype. Not a demo with curated inputs. Something that could consume real Gerber RS-274X files — the manufacturing format that PCB designers actually export from KiCad, Altium, Eagle — parse them completely, and produce manufacturing-ready outputs.
I have been writing software for thirty years. In that time I have sat through thousands of daily standups, hundreds of onboarding sessions, and more planning ceremonies than I care to count. Most of them existed for one reason: transferring context from people who had it to people who did not. The new developer needs to know how the deployment pipeline works. The team lead missed yesterday's discussion about the API change. The architect needs to understand why the data model looks the way it does before approving the next feature.
These are not bad reasons to meet. But they are expensive reasons. And increasingly, they are avoidable ones.
You'd think parsing a part number would be trivial.
A string of characters. Match it against a pattern. Done.
Then you actually try to do it across a real component database, and you discover how much institutional knowledge is packed into those strings — and how little of it is documented anywhere.
There's a reason temporal analytics resonates particularly strongly in Norway.
It's not just that Norwegian organisations face the same data challenges as everyone else — though they do. It's that several converging factors make Norway an unusually well-positioned market for AI-powered data infrastructure, right now.
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.