State and the Future of AI-Generated Software

The gap between how fast business leaders think software should be built and how long it actually takes is explained by one thing: state complexity.

Most developer hours are wasted on it. Most bugs come from it. For decades, in our quest to deliver fast, responsive software we have denormalized state. We copy state across caches, services, and layers. Each copy introduces drift. Truth splits. Bugs multiply. Entire fields of engineering exist only to reconcile these drifts. Most of this work adds no business value. It is bookkeeping.

If you want proof of this, just ask frontend developers. Nobody complains about their React components or Vue templates being too complex or hard to reason about. They complain about Redux, Vuex, global stores, query clients—the machinery needed to synchronize fragments of truth. The pain is not in building the UI. It is always in the sprawl of state.

Large language models suffer the same way people do. What looks like business logic is often glue code holding multiple partial truths together. An LLM cannot reason about such a system because there is no single truth to reason about.

Conway's Law and the Root of Denormalization

The reason that state becomes so fragmented is not technical. Conway's Law tells us that systems mirror the structure of the teams that build them. Every group of developers wants to own and manage its own truth.

Backend engineers own the database. Frontend engineers own frontend caches and stores. Analytics own data warehouses.

Each move is reasonable in isolation. But together they produce the sprawl of denormalization: multiple partial truths stitched together with synchronization code, meetings, and politics.

This is why decades of frameworks have left state more denormalized than ever. It is not a bug of technology. It's not an inevitable result of the desire for responsiveness. It is the inevitable outcome of org charts. The org chart itself generates sync code.

Solo developers and small teams avoid this entirely. They choose tools that offer unified state. Django, Laravel + Inertia, even HTMX—these frameworks show that the bottleneck to productivity is not too many languages, but the duplication of state. You can write Python or PHP on the backend, JavaScript on the frontend, but these systems still feel unified because the truth of state lives in one place.

That unity is what makes solo developers so productive. One coherent system can fit in a single head.

The challenge today is bringing that same clarity to teams. AI-augmented developers will work in groups, not alone. They need the speed of solo developers, but with the tools and ecosystems they already have.

Sync Engines

Sync engines promised to end state denormalization by running the same query logic everywhere. In a sync engine the server and client share the same state querying and mutation engine. This creates what should be consistent, bug-free determinism in mutations wherever they occur. A change applied on one client or the server could be replayed anywhere and always produce the same result.

But the price of removing denormalization was removing the clarity of transactions. Sync engines do not give users a definite answer in the moment. They trade certainty for eventual convergence.

When a user takes an action, they expect a concrete result: did it succeed, or did it fail? Sync engines blur that into maybe. A record may exist on one device and not on another. Only later does reconciliation collapse the contradictions into one outcome.

The experience corrodes trust. Request/response semantics give users clarity. I do something, and something happens. Sync engines replace clarity with probability.

Sync engines promised quantum entanglement but gave us Schrödinger's cat—data both dead and alive until someone checks.

The Frontend Land Grab

Modern frontend libraries like TanStack Query, Relay, and Apollo have evolved into sophisticated state systems. They normalize data, cache results, and support optimistic updates—patterns that echo database design.

This isn't a coincidence. Following Conway's Law, frontend teams built their own databases in the browser. They needed independence from backend teams, so they created parallel data layers. The frontend became a second system of record.

Engineers spend their time writing synchronization code to align shadows of the same truth.

What Unified State Really Means

Breaking free from Conway's Law requires recognizing it first. Fragmented state is not accidental—it is the natural outcome of every team demanding its own slice of truth. The question is how to preserve autonomy and responsiveness while maintaining one coherent reality.

A unified model strips things down to two primitives:

Rendering – how the UI reflects ground truth
Mutation – how truth changes through transactions

The frontend does not hold its own system of record. Instead, it subscribes to backend truth through real-time connections. When data changes—by any user, any service, any process—all views update automatically. This process is arbitrated by a single source of truth: the database.

To achieve real-time latency on the user's device, local actions render instantly through operation projection. The client doesn't mutate a local copy of the state. It shows the intended effect, confirms with the backend, then discards the projected operation whether it succeeds or fails. The UI rerenders from truth. No complex rollback semantics. No mutated local data.

This render pattern preserves the speed teams want while eliminating denormalization.

Toward AI-Native Software

Dramatically reducing state complexity matters beyond human productivity. Large language models cannot reliably reason about fragmented systems any more than humans can. What looks like business logic is often glue code keeping multiple realities aligned. Without a single truth, both people and machines are left guessing.

Unified state changes that. Humans and AI share the same map of reality. Complexity collapses. Synchronization gives way to normalization.

In the AI era, progress will not come from producing more code. It will come from removing the need for glue code altogether.

The StateZero Approach

This is what StateZero sets out to provide.

Rendering state: querysets in the frontend behave like arrays, but stay synchronized with the backend via WebSockets.

const users = useQueryset(() => User.objects.filter({ active: true }));
users.map(user => <div>{user.name}</div>);

No Redux store. No manual cache. The array stays live because it's bound to backend truth.

Mutating state: operations are transactional. They render optimistically, then confirm with the backend.

await User.objects.create({ name: "Alice" });

The new user appears instantly, but the backend decides if the transaction succeeds. If it fails, the operation is dropped and the view rerenders from truth. No complex rollback semantics. It is as if it never happened.

Errors, permissions, additional fields, even custom querysets all flow through the same layer. Rendering projects live truth plus pending operations. Mutations execute atomically against the real system of record.

No parallel databases. No org-driven duplication of state. Just one truth, shared everywhere.

Beyond Conway's Law

Conway's Law shaped the last era of software. Every team owned its own state, and the industry built a universe of synchronization code to hold the fragments together.

The next era will be defined by those who can transcend it—preserving team autonomy and the tools they use today while unifying truth. Software built this way is easier to reason about, easier to maintain, and readable by both humans and AI.

That clarity may be the most important step toward the next epoch of software.