AI-Native Redesign: The Principles Don't Change - Only the Machinery Does

AI assistance disclosure

This article was drafted with the help of Claude. All technical content, design decisions, code references, and screenshots reflect production systems I designed and operate at airCloset; the prose was revised by me prior to publication.

Hi, I'm Ryan, CTO at airCloset (a fashion-rental subscription service based in Japan). "Everything changes with AI" is the prevailing mood. My experience building and then running an internal AI platform (cortex) points the other way. The principles don't change at all. Only the machinery does. This post is about what I've come to treat as principle, what I've concluded should be broken, and the thinking behind that split.

Disclaimer: "cortex" in this article is the internal codename for the AI platform built in-house at airCloset. It is unrelated to existing commercial services like Snowflake Cortex or Palo Alto Networks Cortex.

I've written about the individual pieces before: code-graph, product-graph, db-graph, biz-graph, AI-Observability, the auto-review harness, and Self-Healing. This post isn't about any of them. It's about the design principle sitting behind all of them, one abstraction level up, more essay than build log.

The principle, in one sentence: how do we make accurate information accessible? It's an old question. Libraries, legal case books, encyclopedias, search engines - every era has had its own answer using whatever tools that era gave it. Even the technology revolutions people call "paradigm shifts" mostly just changed the means. The underlying question didn't move.

Now AI has arrived, and my read (probably not a controversial one) is that its shift is at least on the scale of the internet, possibly larger. As with every previous paradigm shift, the means of answering "how do we make accurate information accessible?" will get redesigned from the ground up. That's what this post is about: AI-Native Redesign - a view where you rebuild the whole design with AI treated as a given, instead of bolting an "AI tool" or a RAG layer onto a design that was optimized for humans doing everything.

The Underlying Principle

Splitting the Principle into Three Nodes

The frame I use: split the principle into three nodes - creation / maintenance / consumption. Someone (or something) creates it. Someone maintains it. Someone consumes it.

• A library: creation = the catalog and classification system, maintenance = adding new titles and updating the shelves, consumption = someone borrowing a book.
• Legal case books and lawyers: creation = courts writing their rulings, maintenance = new cases getting added to the corpus, consumption = a lawyer looking up a matching case for a client.
• Engineering docs at a company: creation = writing the spec or README, maintenance = updating it when the code changes, consumption = another engineer reading it while implementing.

In every case, each of the three nodes has someone owning it, and the whole thing only works when all three keep turning. As long as the three of them are held together by a chain of trust and incentive, the system holds itself up. If one of them drops out, the whole thing slides into a negative spiral and quality decays. I'll come back to the specific mechanism later in this chapter.

"Information" here changes shape depending on the domain - knowledge in books, legal precedent, internal documentation at a company, runtime behavior of a service, customer trends, the reasoning behind a decision. What they all share is this: as long as it lives only in one person's head, the moment scale kicks in the whole system stops working. It only starts to work at scale once the information is stored in a form you can look up, and reachable when someone needs it.

What Has Changed, What Hasn't

The means have changed a lot. Clay tablets, oral tradition, manuscripts, dictionaries and indices, the printing press, legal codes and lawyers, library classification, then in the last few decades: wikis and paper docs, APM and structured logs, searchable knowledge bases, distributed tracing, web-scale search engines, BI dashboards, RAG. Each era tried to optimize the three-node balance with whatever tools it had. Wikis fit the 90s because "humans write, humans update, humans search" was the only shape available. APM appeared in the 2000s because storage got cheap enough to hold the telemetry that machines generate. Each generation had its own subject and its own tooling to answer with.

But the underlying question hasn't moved. Every era in every domain was solving the same problem - "make accurate information accessible" - with that era's tools. And in some sense, each generation was consciously designing the three-node balance. But once humans are in the loop, they cut corners on writing, forget to update, get things wrong, eventually stop maintaining, and the whole thing breaks. Some systems have held up (library systems, legal frameworks, established academic disciplines), but most have fallen into the negative-spiral side because the human limit was the binding constraint.

What makes AI different is that it dramatically widens the range where creation and maintenance can run without much human labor. Automating creation and maintenance is itself old news - deterministic systems have covered a huge amount of it, so widely that we don't even notice anymore. It's not just engineering infrastructure (APM, CI/CD, log collection, schema validation). Media services run on the same shape: articles get created, updated, and deleted through a system, then distribution pushes them to the app, the website, and the print edition. Bank transactions, e-commerce catalogs, routing data in a map app, the timeline in a social network. Deterministic automation is everywhere, quiet enough that it's easy to forget it's there.

But deterministic automation has a ceiling. There's a class of work it can't touch: qualitative judgment, articulating design context, updating documentation to follow a code change, adding annotations - anything that needs interpretation and context. AI is the first thing that reaches into that zone. And it can even sit on the consumption side (in the APM example, this means AI running the "look at the dashboards, close the improvement loop" work that humans used to do).

Once the human requirement drops structurally, many domains can start running a positive spiral for the first time. But how to wire this expanded capability into your own organization's loops is still a human design call. That's what this post - AI-Native Redesign - is about.

Where this post lands

AI isn't a replacement for deterministic automation. It's a new capability that brings the zones deterministic tools never reached into the automation envelope - but redesigning your organization's loops around that expanded capability is what turns it into a change on the ground.

A Closer Look at Each Node

Creation. Putting information into a form that can be looked up later. Writing the structure of your code down as docs. Instrumenting the runtime to emit logs and traces. Leaving the reasoning behind a decision as a design doc. Turning a customer trend into a KPI definition. Anything that leaves something behind in a form someone (or something) can come back to.

Maintenance. Keeping what you already wrote from drifting away from its source as that source changes. Code changes, the doc should follow. Service topology changes, the metric definitions should follow. Customer trends shift, KPIs should follow. Decisions get overridden, the record should follow. If creation is a one-shot act, maintenance is the standing chore that never ends.

Consumption. Actually reaching for what's stored and using it to decide or act. Humans reading. Machines querying. Alerts firing. AI agents pulling context. All of it counts.

These aren't sequential phases (creation → maintenance → consumption). They're a single system held together by mutual trust and incentive - you can't evaluate any one of them in isolation.

The Negative Spiral - Why It Collapses in Most Real Places

Concretely, the interdependence looks like this:

• If it doesn't get consumed, no one is motivated to create it. Nobody keeps writing docs no one reads. No engineer polishes a dashboard no one looks at.
• If it doesn't get maintained, it becomes unfit to consume. A doc from six months ago gets a "probably stale" tag in someone's head and is skipped. A dashboard whose metric definition drifted since the last product change quietly seeds wrong decisions.
• If it doesn't get created, there's nothing to maintain in the first place. Information that was never stored in a queryable form can't be tracked as it changes.

As long as all three sides believe "my part is worth doing," the loop keeps turning. But if any one of them gets too expensive, the other two lose their incentive too. "Nobody's going to read it, and it'll rot anyway," "I updated it but no one cared," "when I search it's stale or wrong" - three separate excuses that reinforce each other, and the negative spiral picks up speed.

How this collapses in most places: If any one of the three nodes gets too expensive, the other two lose their reason to invest. The reason documentation cultures don't stick, monitoring stacks go stale, and knowledge bases quietly hollow out isn't a tool problem - it's structural. The balance between the three nodes has to hold, or the whole thing decays in silence.

That's why patching a single node never fixes it. Many people have seen the "our Confluence has 100k pages and no one reads or updates them" version of this. Not a Confluence problem - what happens when at least two of the three nodes (creation and maintenance) stay expensive, and the fix that gets applied is a search feature on the consumption side. The loop never closes.

The Rest of This Post

Everything from here on works off the same principle: make information accessible, and run it as a three-node loop.

• Chapter 2 lines up concrete cases from around us (internal docs, monitoring, business data, schema management, security) and shows how each one has been carrying its own version of the three-node problem.
• Chapter 3 argues why AI is the pivot, from the angle of "the first thing that brings zones deterministic automation couldn't reach into range of automation."
• Chapter 4 walks through the AI-native implementations in cortex (code-graph / db-graph / biz-graph / product-graph / Observability) side by side.
• Chapter 5 goes into the difference between "adding an AI tool" and AI-Native Redesign, and why keeping pre-AI design in place while adding AI is a losing pattern.
• Chapter 6 sketches what widens between organizations that have multi-layered self-sustaining loops and organizations that don't - the evolution-speed gap I think grows non-linearly over time.

Each chapter reads independently, but read in order, they form a single chain: unchanging principle → common applications → what's special about AI → concrete implementations → the redesign argument → what's next.

Where Deterministic Automation Couldn't Reach

I said earlier that deterministic automation has already reached almost everywhere. And I said that deterministic automation still has zones it can't touch. This chapter breaks those remaining zones down.

If you look at each domain and split it into the three nodes, two categories show up.

Type 1: Domains Where One Node Is Still Human-Only

Domains where deterministic automation covers some nodes but not others. Laying them out side by side:

Every remaining human dependency is in the parts that need qualitative judgment or contextual interpretation. In most of these, the bottleneck settles on the consumption side - "the information is there, but no one uses it" is the classic symptom. Humans interpreting a room full of dashboards and log streams at once hits a cognitive ceiling, and that ceiling has been the structural bottleneck. Internal docs is a special case where all three nodes are human, which is why it's the most obvious pain point.

Type 2: Domains Where Building the Artifact Wasn't Worth the Return

Separate from Type 1, there's a deeper category: the zones we never tried in the first place. The individual data and code are there, but the cost of building the "system that structures the relationships between them" never matched the payoff. This covers two subtypes:

• Type 2a - relationships that already exist but aren't visible to humans (like connections across code, or across tables)
• Type 2b - relationships that were never even defined (like the causal link between a marketing initiative and a KPI)

What's interesting is that the underlying work - static analysis, SQL aggregation, graph-building pipelines - is often perfectly writable in deterministic logic. The reason nothing existed here wasn't "we couldn't build it." It was "the ROI didn't clear the bar."

Break down why no one built it and you get problems on both sides - a double whammy:

• Cost side. Even if deterministic logic can build it, standing up the system to do so (the static analyzer, the extraction pipeline, the graph substrate) is real engineering effort.
• Payoff side. Even if you build it, humans can't consume it usefully. A human traversing a graph node-by-node isn't a real workflow, and no semantic search layer existed to sit on top.