First and foremost, code is a language built for people. Not for computers. Computers have no say or preference in the matter. To the silicon, it is all just electrical potential, ones and zeroes.
The history of software development has always been one of translating human intent into computer instruction. This “intent gap”—the space between what a system is supposed to do versus what it actually does—has shifted dramatically over the decades.
In the early days of computing, this intent was expressed through a physical medium: paper. Punch cards were used to give computers literal, linear instructions. There was not much ambiguity. Perform this op here, and that op there.
In the image above, you see this translation of intent to instruction lead by Margaret Hamilton to help the 1969 NASA Apollo 11 mission. But the “code” didn’t just stay on paper. To be flight-ready, it was sent to Raytheon, where workers physically wove the software into Core Rope Memory.
A “1” was represented by a wire passing through a magnetic core, and a “0” by a wire bypassing it. They were essentially weaving the “Why” into the copper. Intent & code were expensive and labor intensive. Things had to be done correctly the first time.
Over time, paradigm shifts moved development from the purely functional toward the representative. Assembly abstracted away raw binary so that memory, registers, and hardware could be manipulated using mnemonics. However, the true tipping point of this shift was the rise of high-level languages like C++—one of the first widely adopted languages to bring Object-Oriented Programming (OOP) principles to the mainstream.
OOP gave developers a way to express intent that resembled business processes and entities. It was a layer of abstraction that removed the complexities of the underlying machine. While it became easier and quicker to write code, that velocity came with a hidden cost: it became equally easy to write meaningless code. Now, with the rise of LLMs and AI tools, we are at another inflection point. It is so cheap to generate code that it can be injected anywhere in the process. Why does it matter if there is code without clear intent?
The answer lies in novelty. AI trends toward the “average.” Novelty—the ability to solve a unique business problem in a specific context—is an innately human ability. As long as people are involved in the process (the owner, user, stakeholder), there remains a desperate need to articulate the Why behind the software.
I didn’t intend for this…
“When I wrote this code, only God and I understood what I was doing. Now, only God knows.” — Anonymous
As soon as you hit “merge” on a PR, entropy starts taking root. You are immediately tasked with something else. Deadlines, incidents, and life happens. Six months later, an incident pops up, and your name is the one on the git blame.
You shuffle through the code, wondering how the hell this even worked to begin with. You search for the ticket in Jira or messages in Slack to figure out what the “Map” was supposed to be. But those artifacts are out of sync—they are dead ghosts of a past conversation. The only thing that is alive, the only thing that cannot lie or get stale, is the code itself.
If the code doesn’t radiate its own intent, you are forced into “Forensic Coding”—slogging through digital ruins to rediscover a “Why” that should never have been lost. To fight entropy, we must ensure Systemic Intent Preservation.
Systemic Intent Preservation
At the highest level, intent can be preserved through an entire business process, spanning multiple systems. Let’s imagine we are designing software for a Library Book Return system.
Service Boundaries: The Shield of Context
In low-intent systems, we build around Entities (the things). In high-intent systems, we build around Capabilities (the why).
| Low Intent (Entity-Centric) | High Intent (Capability-Centric) |
|---|---|
BookService: Manages book records. | CatalogContext: Inventory & Discovery. |
UserService: Manages user records. | LendingContext: The Lifecycle of a Loan. |
FeeService: Manages money. | BillingContext: Fines and Policy Enforcement. |
The Entropy Test: We need to add a “Grace Period” for late returns.
In a Low Intent model, where does that go? Does UserService check the grace period before calling FeeService? Does FeeService hold the logic? The intent is scattered across the gaps. In a High Intent model, the LendingContext owns the lifecycle; it knows a “Return” is happening and can explicitly invoke the BillingContext based on a specific business policy.
The Communication: Signals vs. Noise
How these services talk determines if your system is a “Living Organism” or a “Distributed Monolith.”
The “Forensic” Approach (Low Intent)
The scanner hits an API. Generic data patches are fired.
sequenceDiagram participant S as Scanner/API participant B as BookService (Entity) participant F as FeeService (Entity) participant DB as Database S->>B: PUT /books/101 {status: 'available'} B->>DB: UPDATE books SET status='available' WHERE id=101 B-->>S: 200 OK B->>F: Broadcast Event: "EntityUpdated" {id: 101, type: 'Book'} Note over F: Forensic Phase: What happened? F->>DB: SELECT * FROM books WHERE id=101 Note over F: Logic: "Ah, it was late. I should charge." F->>DB: INSERT INTO fees (user_id, amount) VALUES (55, 10.00)
The Takeaway: The Fee Service has to investigate the crime scene (diff the data) to figure out what happened.
The “Narrative” Approach (High Intent)
The scanner hits an endpoint that captures the human action.
Code snippet
sequenceDiagram participant S as Scanner/API participant L as LendingContext (Capability) participant B as BillingContext (Capability) S->>L: POST /lending/return-book {bookId: 101} Note over L: Logic determines business outcome L-->>S: 202 Accepted (Return Processed) alt is Late L->>B: Emit Event: "BookReturnedLate" {days: 3, user: 55} Note over B: Intent is clear: Assess Fine. B->>B: Apply Overdue Policy else is On Time L->>B: Emit Event: "BookReturnedOnTime" {bookId: 101} end
The Takeaway: The event name carries the intent. The payload carries the context. No guessing required.
The Orchestration (The Process)
Finally, how do we ensure the business process is respected?
Low Intent (Choreography): The BookService marks the user’s available book capacity immediately. The user is able to check out another book before the FeeService even finishes its background job. The intent—“Block bad actors”—is lost in the race condition.
High Intent (Policy Enforcement): The LendingContext marks the user’s standing as Suspended inside the same transaction as the return. The system intent is explicit: “The return is complete, but the account is not settled.”
The Golden Rule of The Anchor
To test if your system is resisting entropy, apply this thought experiment:
“If I deleted every line of implementation logic and left only the API routes and Event names, could a non-technical stakeholder still understand the business workflow?”
-
No:
UPDATE /table/1,Topic: entity_changesHigh Entropy. -
Yes:
POST /check-in,Topic: book.returned.lateNegentropic.
By naming our abstractions after actions rather than objects, we anchor the “Why” directly into the “How.” We ensure that even when we are long gone, the code remains a living document of human intent.
Systemic intent is our North Star—it tells us where we are going. But once a request makes its way into the individual application, that intent often dissolves into a mess of database queries, framework boilerplate, and “God Objects.”
It isn’t enough for our services to speak clearly to one another; the internal guts of the application must also reflect the “Why.” If the code inside the service is a black box of side effects, the anchor will eventually drag.
Next Chapter: [The Application: The Living Blueprint] In the next part, we zoom into the application layer to explore how Architectural Patterns (like Hexagonal and Clean Architecture) act as a shield, ensuring that business intent isn’t suffocated by the very frameworks meant to support it.