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."
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.
Code Writers Won't Survive
I'll say this without hedging. Engineers whose primary value is "writing code" will not 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.
How I Use AI
I'll be honest.
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: The Age of AI — The Starburst That Code Universes Were Never Prepared For (this post)
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


SOCIAL SHARE CARD GENERATOR