A short piece about what happens to development when code stops being the center. More of a reflection: how we think, what we fix in place, and why speed is no longer the main constraint.
Contents
- Introduction What this is about and why it matters now. The shift from "write faster" to "understand more clearly".
- Code Is Not the Center Code as cache and as a projection of decisions. Source of truth is not files but invariants and intent.
- Intent and Invariants What to fix before code and why. Decision first, then code - not the other way around.
- Two Modes Flow and serialization: when something new is born, when clarity appears. How not to get stuck packaging the past.
- Comprehension Debt We generate understanding but don't know how to keep it as a system. And what to do about it.
- Equilibrium Architecture as a balance of forces: latency - throughput, flexibility - simplicity. Change = shift in space, invariants = boundaries.
- One Formula Meaning is fixed, execution is computed, the system lives through the evolution of decisions.
1. Introduction
For the last six months I've had the sense that I'm not so much writing code as trying to get a feel for the invariants of development itself.
At first it looked like a local task: speed up development with AI without losing control. It seemed to be about tools - Cursor, models, pipelines.
Very quickly it became clear: tools aren't the problem at all.
The problem is undefined intent.
AI doesn't break architecture. It just makes its weak spots visible faster than you can paper over them. You used to be able to write by hand for a week and not notice the mess in your head. Now - ten minutes, and you already have an architectural mess in the code.
I stopped trying to "write faster". That's no longer the problem. AI simply removed it.
The problem now is different:
- how well you actually understand what you're doing
- how well you can say it
- whether you have invariants, not just "seems fine"
And the most interesting observation: speed is no longer the constraint. The new constraint is clarity of thinking, sharpness of invariants, the ability to formalize intent.
This booklet is about where that leads: not another framework, but a shift of gravity. Code moves to the background. What we fix before code and how we keep the system within the bounds of understanding moves to the center.
In short: not "how to write better", but "how to make thinking a bit more engineering". And that turned out harder than any NestJS service.
2. Code Is Not the Center
We've lived a long time with the idea that code is the system. That if the code exists - the system exists. If we lost the code - disaster.
AI quietly broke that assumption. Not loudly, not declaratively - through practice.
Code became cheap. So cheap that losing it is no longer a tragedy. Not because code got worse, but because a layer above it appeared that used to be blurry.
Before: idea, discussions, code, workarounds, documentation (if you're lucky).
Now something else is taking shape: idea, invariants, boundaries, decision, execution, code.
That's where the main shift happens: code no longer explains the system, it only reflects it.
Code is not the asset. The asset is invariants and decisions.
Code is their projection. You can rebuild it.
If you have intent, invariants, constraints, decision graph - code becomes computable. Not in a magical sense, but in this sense: computation used to be expensive, so we fixed the result (code). Now computation is cheap - we can fix the description and rebuild the result.
A handy formula:
- CHANGE_PLAN / DOSA / invariants - source of truth
- code - materialized view
- execution - computing system state
You're just applying to development what databases, functional systems, and distributed systems already do: schema and change log matter more than the current snapshot.
One important anti-pattern: "I made it pretty but lost understanding" - that's a real anchor. So the model needs one more invariant: if you can't verify and understand the result - it's invalid, even if it's "computable".
The reality of the system is slowly moving: it used to be "files + classes + functions", it's becoming "decisions + constraints + their evolution".
3. Intent and Invariants
Clean Architecture, DDD, Ports & Adapters - they define structure and boundaries. But the lifecycle of a decision - how it is captured, constrained, and evolved - remains implicit. The closest thing we have is ADR. But ADR turns decisions into documents. What we need is to turn decisions into system primitives.
When you start explicitly fixing intent, invariants, constraints, kill criteria - you don't get documentation. You get a decision graph. And at some point it becomes obvious: code is not the center of the system. Code is a projection of decisions.
Hence the next step. If decisions are primary, they can be versioned, checked, executed, tied to metrics. Then architecture isn't a set of layers, it's a system for managing decisions under uncertainty.
In practice it looks like this. First you form the context of intent: talk to people, gather the picture. Then - a dump of thoughts, into a chat or on paper. Then structuring: not "make it pretty", but "split by intent, invariants, boundaries, steps". One plan file, one execution step at a time, a separate context per step. The model gets not "everything at once" but the minimal sufficient slice. And that gives both quality and economy: moving along meaning is cheaper than recovering meaning through search.
The main observation: a separate chat - less context -> often better quality. LLM quality is proportional to the clarity of local context, not its size. A tree model fits: root -> intent and invariants, branches -> change plans, leaves -> execution steps. That's indexing by meaning, not by text.
The human is responsible for meaning and boundaries. The system (AI + runtime) - for execution. AI shouldn't define the system, it should live inside the frame we set.
4. Two Modes
There are two modes we slip into when we think and do.
Flow / exploration. That's where something new is born. No clarity, just "feels like something's here", contradiction is allowed.
Serialization / fixation. That's where clarity, words, boundaries appear. But almost nothing new appears there anymore.
The problem isn't that the second mode is bad. The problem is that it's very sticky. It gives a sense of control, completeness - "I did good, I packaged it". And you can sit in it for hours, days, and at some point catch yourself: you haven't discovered anything in a long time, you're just neatly packing the past.
The key skill isn't "write better", it's switching between modes on purpose. Almost like a toggle: now I'm exploring, now I'm fixing.
A strict rule helps: if you're in flow - don't try to make it pretty and correct right away. At most - short markers, anchors, scraps of thought so you can come back later. And only in a separate state: ok, now let's turn this into a plan, an article, an architecture.
And an important effect: if you do it that way, serialization stops "killing the flow" and starts feeding it. You return not to a void but to a space that's already a bit structured.
CIMP and similar things are basically an attempt to make even the fixed part not die but stay part of a living thinking process. Not a "memory dump", but a frame you can build the next loop on.
5. Comprehension Debt
You talk with someone - and it's great. But if you close the chat, half the meaning just vanishes.
We generate understanding but don't know how to keep it as a system. I call this comprehension debt - like technical debt, only in understanding. The term has been around in various circles for a long time, and I didn't coin it, but this name fits me best.
Any conversation with AI is ephemeral. It doesn't persist as a knowledge system. You kind of understood - but that understanding isn't anchored anywhere. Hence ideas like RAG, context graphs, structured artifacts. But even that's not enough: knowledge isn't text, it's the link between decisions, invariants, and consequences.
In the new model, documentation stops being "extra work". It becomes the main interface for controlling the system. Not an afterthought, but what execution loses its anchor without.
Formulating outward - articles, posts, plans - is a way to unload your head, check what matters, and make room for new things. Not a side effect but a natural extension of the same approach: structure lowers the cognitive cost.
One more thought: if you can't hold the system as a model - it doesn't exist. Doesn't matter how many lines of code. So fixing meaning isn't bureaucracy, it's the condition for the system to exist in your head and in the heads of everyone who works with it.
6. Equilibrium
Architecture works with a limited set of concepts and meanings. They're almost deterministic, what changes is mainly context. And there are concrete forces that are always being traded off.
Technical: compute vs data, latency vs throughput, consistency and availability.
Structural: flexibility vs simplicity, experimentation and research vs control.
Architecture isn't a choice of "what's better", it's equilibrium. Every change isn't a "feature", it's a shift of the system in the space of these forces. And if you have invariants, you limit where you can move. If you don't - the system just spreads.
It helps to think of it as vectors. The system is a point in the space of forces, a change is a shift of the vector, invariants are constraints on the allowed region. You start to see that system architecture and model architecture (the same vectors, matrices, parallel computation) aren't different worlds - they're the same math in different guises.
Splitting into two layers keeps the zones from mixing: deterministic (invariants, policies, boundaries, checkable rules) and probabilistic (AI, inference, generation, search). AI should live inside constraints, not define them. Then the human is responsible for meaning and boundaries, the system for execution.
In the end, development isn't writing code, it's managing the computation of decisions. And your workflow with plans, steps, and review stops looking like a hack and starts looking like a clean model: you generate intent, fix it, split into steps, execute one at a time, check, adjust. The main thing: you don't hold everything in your head at once. You build a system where moving along meaning is cheaper than recovering it.
7. One Formula
If you pack it all into one short formula:
Meaning is fixed. Execution is computed. The system lives through the evolution of decisions.
You're no longer trying to "write correctly". You're trying to make it so that even if you forget - the system can be restored. That's already very close to how math, physics, and stable systems in general work.
The shift is essentially:
- was: code-centric engineering
- becomes: decision-centric engineering
Like git for code - only for decisions. At some point I realized architecture isn't about diagrams. It's about taking a blurry thought and making it concrete enough to be checked, executed, and not lost a week later.
The final picture: not "speed up development", but make it observable, explainable, controllable, and scalable without losing meaning. Thinking becomes executable. And that's much deeper than it seems at first.
This idea doesn't stop here.
If code is not the source of truth, then:
- what is?
- how is it structured?
- how does it evolve?
I'll explore this in the next short parts:
- DOSA (Decision-Oriented System Architecture) - what happens when decisions become first-class system primitives, and architecture turns into a graph of evolving decisions rather than static structure
- Context-oriented engineering - why smaller, structured context outperforms large prompts, and how to make context composable
- Feedback-centric engineering - how systems close the loop between execution and understanding, and learn through decisions
- System evolution - how systems become capable of change while preserving stability
Top comments (0)