AI creates stars. But it doesn't create gravity.
Previously
In Chapter 14, I wrote about Civilization — why only some codebases become self-sustaining structures that outlast their creators.
The three elements of civilization: Architect (creates structure), Anchor (maintains order), Producer (expands territory).
Now, a new variable is entering this equation.
The Starburst
The software universe is entering an era of profound change.
AI.
AI writes code. Faster than humans. In greater volume. GitHub Copilot, Claude Code, Cursor — AI assistants are no longer "experimental tools." A significant portion of production code is now generated by AI. That era has already arrived.
In cosmic terms, this is a starburst.
New code. New functions. New services. New files. The code universe is experiencing star formation at a rate never seen in its history.
But Stars Alone Don't Make a Universe
As I wrote in Chapter 7, a code universe isn't composed of stars (code) alone. There is gravity (structural influence), dark matter (invisible forces), and entropy (the tendency toward disorder).
The more stars form, the more entropy increases.
This might seem counterintuitive. Isn't more code a good thing? Isn't higher productivity a good thing?
The answer is No. At least, not unconditionally.
The Nature of AI-Generated Code
AI-generated code has a structurally important characteristic:
AI generates the future but takes no responsibility for the past.
When a human engineer writes code, there's implicit context. "This module was built on this design philosophy." "This naming convention carries this intent." "This implementation is the result of a discussion three months ago." This context doesn't appear in git log. It lives in the engineer's head.
AI has none of this context. AI generates code that satisfies the requirements in a prompt. The code works. Tests pass. But consistency with the existing structure is not guaranteed.
In EIS terms:
AI generates stars ← Production
AI does not generate gravity ← Design, Survival
AI supercharges the Production axis. But it doesn't contribute to Design or Survival — in fact, code that doesn't fit the structure can erode these axes.
The Survival Problem of AI Code
In Chapter 1, I wrote that Survival (code longevity) is EIS's most important axis. Whether the code you wrote persists through time.
What happens to the Survival of AI-written code?
We don't have enough data yet, but hypotheses are possible.
Short-Term: High Survival
AI-generated code usually "works." Tests can be written. So in the short term, there's no reason to rewrite it. Survival reads high.
Long-Term: Survival Degrades
But months later, when adjacent modules change — what happens? AI-written code wasn't designed with awareness of structural intent. So it can't withstand structural changes. It gets rewritten. Survival drops.
In other words, AI code Survival may exhibit a temporal degradation pattern. Survives short-term, but crumbles when waves of structural change arrive.
Viewed on an EIS timeline:
Period Survival
2025-Q2 85 ← Just generated, no rewrites yet
2025-Q3 72 ← Adjacent module changes force partial rewrites
2025-Q4 55 ← Design changes make major rewrite unavoidable
2026-Q1 40 ← "Easier to just rewrite from scratch"
This is the entropy of Chapter 11 in action. Code without structure is fragile against structural change.
Can AI Become an Architect?
This is the core question.
Recall the civilization equation from the previous chapter:
Civilization =
Architect → creates gravity (structure)
+ Anchor → maintains order (stability)
+ Producer → expands territory (growth)
AI can clearly fulfill the Producer role. Writing code. Expanding territory. Fast and in volume.
AI can partially fulfill the Anchor role. Refactoring, adding tests, fixing lint — some maintenance work can be delegated to AI.
But can AI become an Architect?
My current answer is No.
An Architect defines structure. Where to draw module boundaries. Which direction dependencies flow. What meaning to encode in naming conventions. These decisions require domain knowledge, team context, business direction, technical constraints — knowledge across multiple dimensions.
AI can answer "how to write this code." It cannot yet answer "how to structure this system."
Think of it as pair programming. The human is the Navigator (making design decisions), the AI is the Driver (handling implementation). The most productive development setup in the AI era is the ultimate form of Architect/Producer division of labor.
Writing code and generating gravity are entirely different capabilities.
The Shift in Engineering Value
This answers how engineering value changes in the AI era.
Before AI
Engineering value = the ability to write code
Engineers who write code fast are strong. Engineers who write code in volume are strong. High Production scores get recognized.
After AI
Engineering value = the ability to generate gravity
In an era where AI writes code, the value of humans writing code drops relatively. But the value of designing structure — generating gravity — doesn't drop. It rises.
Because the more code AI generates, the more important the humans who give that code order become. More stars means more gravity is needed.
Viewed through EIS's 7 axes, the value shifts look like this:
| Axis | Value Change in AI Era | Reason |
|---|---|---|
| Production | ↓ Declining | AI can substitute. Human production speed is no longer a competitive advantage |
| Quality | → Stable | Ability to validate AI code quality remains necessary |
| Survival | ↑ Rising | Only structurally grounded code survives. Proof of design ability |
| Design | ↑↑ Sharply rising | The scarcest capability in the AI era. The only axis that generates gravity |
| Breadth | → Stable | Cross-cutting knowledge depends on human contextual understanding |
| Debt Cleanup | ↑ Rising | The ability to clean up debt AI generates |
| Indispensability | → Stable | Structural influence remains a human responsibility |
Design becomes the most important axis. In Chapter 1, I called Survival the most important axis. That's still true. But in the AI era, Survival and Design become two sides of the same coin — only structurally correct code can maintain Survival.
Defining the Engineers Who Will Survive
So what exactly is an "engineer who survives in the AI era"? I want to articulate this clearly.
Implementation Speed Alone Won't Be Enough
Engineers whose primary differentiator is implementation speed will struggle to survive the AI era.
This isn't a denial of ability. It's a structural change in the market. When AI can write in one hour what a human writes in a day, there's no economic value in the human doing it. The ability to write code fast and accurately was a scarce resource before AI. After AI, it becomes a commodity.
Three Conditions for Survival
Through EIS's 7 axes and Software Cosmology, three conditions for "surviving engineers" emerge:
1. The ability to generate gravity (Design)
The ability to define structure. Drawing module boundaries, determining dependency direction, encoding domain meaning in naming conventions. In the language of Chapter 7 — the ability to create a gravitational field in the code universe.
In an era where AI generates massive amounts of code, the human who can give that code gravitational pull so it doesn't scatter in all directions. This becomes the scarcest capability.
2. The ability to explain the "why" of structure (Context)
AI can write the "what" of code. But "why this structure?" — domain context, business constraints, the team's historical decisions — only humans can understand and communicate this.
The dark matter of Chapter 10 — invisible forces that don't appear in commit logs — exists only in human minds. To give AI context and make it generate code in the right direction, you must be able to articulate that dark matter.
3. The ability to fight entropy (Survival × Debt Cleanup)
AI-generated code accelerates entropy. Code that doesn't fit the structure seeps in, and technical debt accumulates.
Surviving engineers can resist this entropy. They can restructure AI-generated code to align with the architecture, pay down debt, and maintain order. The power to directly oppose Chapter 11's law of entropy.
A New Classification of Engineers
Organized, AI-era engineers fall into three categories:
| Classification | Characteristics | AI Era Outlook |
|---|---|---|
| Code Writer | Primary value is writing code | Replaced by AI. Market value drops sharply |
| Code Architect | Designs structure, generates gravity | Most scarce in AI era. Market value rises sharply |
| Code Custodian | Maintains structure, fights entropy | Cleaner of AI-generated debt. Value rises |
Mapped to the civilization equation from Chapter 14:
- Code Writer = Producer
- Code Architect = Architect
- Code Custodian = Anchor
The survivors in the AI era are Architects and Anchors. AI takes over the Producer's work.
And the Architect/Builder — the engineer who builds structure with their own hands — becomes the ultimate AI user. Because they can direct AI with structural understanding. They can show the right direction to AI as a Producer.
AGI — When Even This Premise Collapses
Everything above assumes "AI cannot become an Architect."
But there's a question I must face honestly.
What happens when Artificial General Intelligence (AGI) acquires the Architect's capability?
The Conditions Under Which AGI Could Become an Architect
Let me revisit why current AI (LLMs) cannot be Architects:
- Lack of context — Cannot holistically understand domain knowledge, team history, and business direction
- Lack of long-term consistency — Cannot maintain design consistency across sessions
- Lack of tradeoff judgment — Cannot apply domain-specific weights to decisions with no right answer (performance vs. maintainability, flexibility vs. simplicity)
Conversely, an AI that acquires all of these could become an Architect.
When AGI fully understands a company's domain knowledge, remembers team context, and can make tradeoff judgments based on business direction — that AGI can design structure. It can generate gravity.
What Remains for Engineers Then?
This might lead to a pessimistic conclusion. But I won't shy away from it.
In a world where AGI can be an Architect, an engineer's "technical" value approaches zero. No need to write code, no need to design structure.
But — and this is the critical point — there is one thing even AGI cannot replace.
The decision of "what to build."
"Why is this product necessary?" "Where is the user's real pain?" "Where should this business go?" — these aren't technical questions. They're questions of human will.
Continuing the cosmic metaphor:
Can create stars ← AI (Production)
Can create gravity ← AGI (Design)
Has a reason to create the universe ← Humans (Purpose)
AGI might be able to construct a universe. But deciding why that universe should exist — that's human.
"Deciding What's Fun" Will Always Be Human
I'm currently in the entertainment domain.
Why did I choose this field? Because I believe defining "fun" is something only humans can do.
Entertainment is the act of humans deciding "this is fun." No matter how far AI evolves, humans set the standard for "fun." Designing game rules. Crafting experiences. Understanding the sensation of "this moment is exciting" and translating it into a product.
I see this as the most concrete form of Purpose. Even when AGI can write code and design structure — no matter how far we go, deciding what's fun remains human. That fact doesn't change.
That's why I jumped into this field. And this conviction is one answer for engineers living in the AI era. Placing human will on top of technology. That's work that never becomes obsolete, in any era.
Neither Optimism Nor Pessimism
I view the technological singularity neither optimistically nor pessimistically — but as fact to be reckoned with.
I don't know if AGI will arrive. I don't know when. But ignoring that possibility while talking about "engineering value" would be dishonest.
What I can do right now is clear. Accurately understand current AI's capabilities and focus on work only humans can do. And every time AI's capabilities expand, update the definition of "what only humans can do."
This isn't a retreat. It's a redefinition of the front line.
The Archaeology of AI Code
Another use for git archaeology becomes visible.
Track the Survival gap between AI-written and human-written code.
If AI code Survival is systematically lower, that's evidence AI is generating code that doesn't fit the structure. Conversely, if AI code Survival matches human code, it means the Architect's structure is clear enough for AI too — proof the structure functions as "civilization's legal codex."
This is a variation of Chapter 14's Civilization Test:
Does the civilization continue after the Architect leaves?
That was the Civilization Test. The AI-era variation:
Does the structure hold even when AI writes the code?
AI stresses structure differently than an Architect's departure. The Architect's absence is structural abandonment. AI's intervention is structural dilution. The gravitational field thins as masses of new stars form.
Only structures that withstand this stress can become civilizations of the AI era.
The Architect/Builder in the AI Era
In Chapter 13, I wrote that I want to be an Architect/Builder.
In the AI era, this orientation becomes even more important.
An Architect/Builder demonstrates structure through code. Not through design documents, but through the implementation itself — showing "this is how it should be written."
This applies to AI too. When AI generates code, it references the existing codebase. Implementation patterns left by an Architect/Builder become the AI's structural templates.
The Architect/Builder's work expands: not just communicating design intent to human successors, but communicating it to AI as well.
Good design is structure where both humans and AI, reading the same codebase, write code in the same direction.
Succession of the Soul to AI
Here, we can see how the civilization equation from the previous chapter functions in the AI era.
The Architect builds the foundation. Module boundaries, dependency direction, naming conventions — defining the gravitational field of the code universe.
The Anchor, on that foundation, teaches AI to understand the structure. Maintaining CLAUDE.md files and architecture documents, giving AI the knowledge it needs to generate code that fits the structure. Verifying AI's output against the structural context, course-correcting to prevent entropy from growing.
And as Architect and Anchor complement each other, they weave massive amounts of functionality into the product with order, alongside AI as the ultimate Producer.
This is a new form of Succession — the structural knowledge transfer I wrote about in Chapter 14. Not human-to-human succession. Human-to-AI succession. The Anchor transmits the soul of the Architect's structure to AI. AI receives that soul and produces code that follows the structure.
A succession of the soul to AI.
Just as civilizations persist across generations, a codebase's structure is inherited by AI as a new "generation." CLAUDE.md becomes the civilization's legal codex — rules that AI reads, understands, and follows. The design intent that human Architects encoded continues to be implemented through AI's hands.
Civilization is no longer woven by humans alone. The era of humans and AI weaving it together has already begun.
The Articulation of Structure and the Birth of New Culture
An Architect's design intent lives in the code. Naming conventions, module boundaries, dependency direction — if you can read structure, you can extract it from commit history. That's exactly what the EIS telescope shows.
But AI still lacks the ability to infer structural "intent" from code alone. So we need to maintain documents like CLAUDE.md, providing structural knowledge as explicit text.
This is an interesting byproduct of the AI era. The text written for AI also becomes a useful guide for human engineers who haven't yet developed the skill to read structure from code. More codebases will have structural knowledge as text from the start — an unexpected benefit of the AI era.
But beyond this lies something far bigger.
When Architects' Souls Accumulate
A single CLAUDE.md contains one Architect's design philosophy.
But what if it crosses the boundaries of a single team, a single product? When the structural knowledge of multiple Architects accumulates, gets refined, and becomes reusable as a common language of good design — that's no longer the story of a single codebase.
A high-quality accumulation of structural knowledge that has absorbed the souls of many Architects. When shared beyond organizational boundaries, a new unit of "culture" may be born.
In Chapter 14, I wrote about "organizational civilization" and "open source civilization." Common coding conventions, architecture patterns, naming conventions — these become civilization's legal codex.
The AI era's codex has the potential to evolve one layer higher. The accumulation of structural knowledge that both humans and AI reference could form a grand culture that transcends individual codebases.
Linux culture, Go culture, React culture — these have existed as community tacit knowledge. In the AI era, that knowledge gets accumulated more explicitly, more systematically. And as AI faithfully embodies that culture, the speed of cultural diffusion increases dramatically.
AI can become a carrier of culture itself.
The Gravity Amplifier
Before AI, an Architect could only build structure with their own hands and demonstrate implementation patterns themselves. There was a physical limit to how much code a single Architect could influence.
In the AI era, that limit vanishes.
AI amplifies the Architect's gravity.
A design pattern the Architect demonstrated in one module gets horizontally deployed by AI across a hundred other modules. Naming conventions the Architect defined get faithfully reproduced by AI in every file. The structural intent the Architect encoded in CLAUDE.md gets embodied by AI in daily coding.
A single Architect's gravity gets amplified 10x, 100x through AI.
This is a fundamental change to EIS's Design axis. Before AI, an engineer with high Design "brought structure to the code they touched." After AI, an engineer with high Design "brings structure to the entire codebase through AI."
The Architect's radius of influence expands dramatically.
In Chapter 12, I wrote about the danger of Black Holes — when gravity concentrates too much in one place, structure collapses. But gravity amplification through AI is different from a Black Hole. It amplifies the Architect's gravity distributively. AI functions not as a center of gravity but as a transmission medium for gravity.
AI carries the gravity an Architect created to every corner of the universe.
My Own Transformation
Of course, I use AI extensively in my own development.
I've been an Architect/Builder for much of my career, but before AI, my work was almost entirely about facing code. Design the structure, implement it with my own hands. That alone would fill a day.
After acquiring AI, this changed fundamentally.
With AI handling the Producer role and writing large volumes of code, I now have time for dark matter work too. Maintaining design documents, expanding CLAUDE.md, having design discussions with team members, making structural decisions — things that were squeezed out by "time spent writing code" are now possible.
And code output hasn't decreased — it's increased. Through pair programming with AI, I can produce massive amounts of structurally-aware code at high speed.
Building structure as an Architect/Builder, making dark matter visible, and weaving large volumes of features through AI. A way of working that was impossible before AI is now routine.
This is the true power of the Architect/Builder in the AI era.
Measuring AI Performance with EIS
Here, a new use for git archaeology emerges.
The EIS telescope can measure AI's performance too.
If AI-generated commits can be identified (via Co-Authored-By tags or commit message conventions), the Survival of AI-written code can be compared against human code.
If AI code Survival is systematically low — that's evidence the structural knowledge given to AI is insufficient. CLAUDE.md needs work. The Architect's design intent isn't reaching AI.
Conversely, if AI code Survival matches or exceeds human code — the civilization's codex is functioning. AI understands the structure and generates code that fits.
In other words, EIS becomes a feedback loop for AI governance.
Architect → CLAUDE.md → AI generates code → EIS measures Survival
↓
Low Survival → improve CLAUDE.md
High Survival → structure is working
The telescope is no longer just a tool for observing the universe. It becomes an instrument for constructing it. Continuously monitoring the quality of AI-generated code from the perspective of structural influence, and running improvement cycles.
This is also an application of Chapter 8's Engineering Relativity — the same engineer gets different scores in different contexts. If AI is measured as an "engineer," its performance should vary by repository. High AI Survival in repositories with clear structure, low in repositories with ambiguous structure.
AI's Survival is a proxy for structural quality.
How I Use AI
These 14 chapters of blog posts were written with AI. EIS itself was born from sparring with Claude Code. I routinely use AI as a pair programming partner.
But the structural decisions are made by a human.
I ask AI to "implement this feature." But "how to structure this system" — I decide that myself. Module boundaries, dependency direction, naming conventions, architecture patterns — I don't delegate these design decisions to AI.
AI is the ultimate Producer. But the Architect is human. At least for now.
And that is precisely the muscle I believe engineers should train most in the AI era.
Not the muscle for writing code. The muscle for generating gravity.
Closing — In the Age of Starburst
In the history of the universe, there were eras when star formation exploded. This is called a starburst. When galaxies collide, gas compresses, and massive numbers of stars form all at once.
The AI era is the code universe's starburst.
Stars will explode in number. But without gravity, galaxies can't hold their shape. Stars scatter and it's over.
That's why we need humans who generate gravity. Now more than ever.
Engineers who can create structure. Engineers who can demonstrate design through implementation. Engineers who can give order to the code AI writes.
The git archaeology telescope was built to make that gravity visible.
In the AI era especially, look through the telescope. Does your code universe have gravity?
❯ brew tap machuz/tap && brew install eis
❯ eis analyze --recursive ~/your-workspace
✦ * ✧
╭────────╮
│ ✦ │
╰────┬───╯
. │
│
___│___
/_______\
✧ the Git Telescope ✦
Series
- Chapter 1: Measuring Engineering Impact from Git History Alone
- Chapter 2: Beyond Individual Scores: Measuring Team Health from Git History
- Chapter 3: Two Paths to Architect: How Engineers Evolve Differently
- Chapter 4: Backend Architects Converge: The Sacred Work of Laying Souls to Rest
- Chapter 5: Timeline: Scores Don't Lie, and They Capture Hesitation Too
- Chapter 6: Teams Evolve: The Laws of Organization Revealed by Timelines
- Chapter 7: Observing the Universe of Code
- Chapter 8: Engineering Relativity: Why the Same Engineer Gets Different Scores
- Chapter 9: Origin: The Big Bang of Code Universes
- Chapter 10: Dark Matter: The Invisible Gravity
- Chapter 11: Entropy: The Universe Always Tends Toward Disorder
- Chapter 12: Collapse: Good Architects and Black Hole Engineers
- Chapter 13: Cosmology of Code
- Chapter 14: Civilization — Why Only Some Codebases Become Civilizations
- Chapter 15: AI Creates Stars, Not Gravity (this post)
- Final Chapter: The Engineers Who Shape Gravity
GitHub: engineering-impact-score — CLI tool, formulas, and methodology all open source. brew tap machuz/tap && brew install eis to install.
If this was useful: Sponsor on GitHub
← Chapter 14: Civilization | Final Chapter: The Engineers Who Shape Gravity →
Top comments (0)