DEV Community: machuz

Git Archaeology #0 — What If Git History Could Tell You Who Your Strongest Engineers Are?

machuz — Wed, 18 Mar 2026 06:02:21 +0000

git log + git blame. That's all it takes.

What Is This?

Engineering Impact Signal (EIS, pronounced "ace") is an open-source CLI tool that quantifies engineering impact from Git history alone.

No external APIs. No AI tokens. Just git log and git blame.

brew tap machuz/tap && brew install eis
cd your-repo
eis

That's it. Here's what you get:

Why I Built This

Commit counts. PR counts. Lines of code. Easy to measure — and all meaningless.

A typo fix and a system-wide architecture change both count as "one PR." A generated lockfile adds thousands of lines. Commit frequency varies wildly between engineers.

Yet inside every team, people sense whose structural signal is strongest.

"That person writes code that lasts."
"That person touches everything but nothing improves."

Those intuitions exist, but they're not measurable. I wanted to turn gut feeling into numbers — and I wanted those numbers to come from a source that can't be gamed by politics: the git history itself.

The Telescope

Over the years, I've recruited several strong engineers by reaching out personally. I'm grateful that many of them said yes.

Why did they come? I don't think it was just the tech stack or compensation.

"This person actually sees my work." — I believe that's what they felt.

For engineers, having your technical contributions properly observed matters deeply. Not commit counts or PR counts, but whether your code survives, whether you contribute to architecture, whether you clean up debt — having someone who sees that substance.

I had that eye. At least, that's my self-assessment.

EIS is that observer's eye, turned into an open-source telescope.

Anyone can use it. Point it at any team. Through the lens of git history — a lens that cannot lie.

Building a Structure Where Sincere Makers Win

Engineers in Japan are paid less than their peers in other countries.

It's not because they lack skill. I believe it comes from a cultural tendency to let the work speak for itself — rather than asserting their own value. They write code in silence, fix architecture in silence, clean up debt in silence — and that work stays invisible. Invisible means unheard. And when it's unheard, the credit — the soul of their work — gets absorbed by whoever speaks the loudest.

Whenever I've sensed that happening, I've resisted hard enough to warp the team's magnetic field.

I want to build a world where the work of people who sincerely face their craft becomes visible.

As I built EIS, I started to see the shape of what I really wanted to do: create a structure where people who sincerely face their craft are the ones who win. The moment I gained that self-awareness, the energy exploded, and I was able to bring this tool this far in a short period of time.

And now I'm thinking about what comes after the telescope.

A telescope observes the universe. But observation alone doesn't change an engineer's life. You need to interpret the observation data, propose a universe that fits them — the right codebase, the right team, the right organization — and show them a stable orbit within that universe. Only then does "a structure where sincere makers win" become real.

That's the next step for EIS. Turning the telescope into an observatory.

Making Architecture a Science

Being strong at math. Being strong at algorithms. Being strong at language specifications.

These all have theory forged in academia over decades. Computational complexity, type theory, formal verification — they can guarantee correctness through mathematical proof. They stand on scientific foundations.

Academic attempts at software architecture have existed for over 30 years. Architecture Description Languages and evaluation methods have been proposed. But they haven't converged into a unified theory. The efforts remain fragmented and haven't made it into practice.

"What is good design?" "Is this team's structure healthy?" — the industry has best practices and rules of thumb for these questions, but very little quantitative language.

And now AI writes enormous amounts of code.

The value of writing code is declining in relative terms. What matters most is structure. What structure do you place code on top of? Does that structure withstand change? Where does the team's knowledge accumulate?

If EIS can become a tool for making architecture a science, I'd be glad.

And now it observes more than just people. To observe modules themselves, we designed 4 new metrics:

Metric	What it measures
Change Pressure	Change frequency ÷ code volume per module. Higher pressure = more structural stress
Co-change Coupling	Module pairs that change together. Detects implicit coupling invisible in import graphs
Module Survival	Time-decayed survival rate of code within a module
Ownership Fragmentation	How knowledge is distributed across a module. Measured via Shannon entropy

These metrics combine to classify every module along 3 independent axes — Coupling (boundary quality), Vitality (change pressure × survival), and Ownership (knowledge distribution). Invisible structural risks become observable data:

Hub × Critical × Orphaned — a module at the center of implicit dependencies, under extreme change pressure, with no active owner. Maximum risk.
Independent × Stable × Distributed — a well-bounded module with healthy ownership. The ideal state.

The telescope now observes both the stars (engineers) and the space they inhabit (modules).

7 Axes of Impact

EIS observes engineers across 7 axes:

Axis	Weight	What it measures
Production	15%	Volume of changes
Quality	10%	First-time quality (low fix/revert rate)
Survival	25%	Does your code still exist today? (time-decayed)
Design	20%	Contributions to architecture files
Breadth	10%	Cross-repository activity
Debt Cleanup	15%	Cleaning up other people's debt
Indispensability	5%	Module ownership (bus factor)

The most important axis is Survival. Is the code you wrote still there after 6 months? After a year?

Writing a lot means nothing if it gets rewritten next month. Engineers who write code that lasts are the strong ones.

3-Axis Archetypes

Beyond signals, EIS classifies engineers along three independent axes:

Role — What you contribute

Architect: designs the structure
Anchor: guards quality
Cleaner: pays down debt
Producer: generates volume
Specialist: deep in one area

Style — How you contribute

Builder: builds and designs simultaneously
Resilient: rebuilds after destruction
Rescue: pays down others' debt
Churn: high volume, low survival
Mass: mass production with low survival
Balanced: even across all axes
Spread: touches everything but lacks depth

State — Lifecycle phase

Former: left the team, but their code remains
Silent: low activity, low survival (detected only for experienced engineers)
Fragile: code survives only because nobody touches it
Growing: low volume, but high quality
Active: currently contributing

From these classifications, team structure becomes visible.

What This Reveals

Here's what EIS has surfaced in real teams:

A departed Architect's code still makes up 30% of the codebase (Former detection)
Code that survives only because nobody touches it — not because it's good (Fragile detection)
No Producers on the team — the layer that generates volume on top of structure is empty (Producer Vacuum)
Architect Bus Factor = 1 — all design knowledge concentrated in one person
136 Orphaned modules — owners have left, nobody holds the knowledge (Module Topology)
12 Critical modules — high change pressure + code doesn't survive. Structural time bombs (Module Topology)

Cold git history tells team stories you didn't know you had. And module topology tells where the system is breaking, not just who is strong.

Validated on the OSS Universe

The best way to verify a telescope works is to point it at stars whose positions are already known.

We ran EIS against 29 open-source repositories spanning 55,343 engineers. React, Kubernetes, Rails, Laravel, esbuild, Rust — projects whose structures are common knowledge.

The results matched community intuition:

esbuild: Evan Wallace hits 100 on every axis. Gravity concentration: 92.5% — exactly the "Evan built it alone" consensus
Rails: 6 engineers with Design above 35. A civilization that distributed design authority over 20 years — DHH, Jeremy Kemper, Rafael Franca, and others
Laravel: Taylor Otwell at 100, every other top-10 contributor below Design 4 — the "Taylor's creation" consensus, quantified
React: 5 generations of architect transitions over 10 years — Paul O'Shannessy → Dan Abramov → Brian Vaughn → Sebastian Markbåge → Jorge Cabiedes. The Gravity Map revealed dynamics that diverge from commit counts. The most striking case is Jorge Cabiedes. With just 82 commits, he reached Gravity 60 — entering the top 3 gravity zone among 2,010 engineers. Design 100, Production 100, Debt Cleanup 96. Meanwhile, Dan Abramov has 1,890 commits with Gravity 51.1. Twenty-three times more commits, yet less gravitational pull. Jorge generates nearly the same gravity as Brian Vaughn (1,627 commits, Gravity 61.6) with one-twentieth the commit volume. Jorge's style classification is Builder — someone who designs, constructs, and cleans up. He appeared suddenly in the 2025 gravity distribution, and Design 100 is a number only Jorge holds among the top 5 (Sebastian Markbåge 7, Dan Abramov 10, Brian Vaughn 4, Andrew Clark 20). A codebase's gravity field is shaped not by the volume of commits but by the quality of structural engagement. Even 82 commits, when concentrated on architecture files, when the code survives, when it cleans up debt — exert stronger gravity than 1,890 commits. The force invisible when scrolling git log is etched into the strata of git blame. There's another story that only emerges by tracing the timeline. Sebastian Markbåge. From 2016 to 2023, Sebastian's gravity was always there, but never at the center. 68 → 72 → 33 → 60 → 66 → 63 → 63 → 38. As gravitational centers shifted — Paul O'Shannessy's field, Dan Abramov's field, Brian Vaughn's field — Sebastian remained within the top-5 gravity zone but never once became the gravitational pole. Then 2024 — Gravity 100. The center of the gravity field quietly shifted to Sebastian. What happened? Sebastian's role classification is Cleaner. Not a Producer churning out features, not an Architect drawing blueprints. Someone who cleans up structural debt left by others and maintains the codebase's integrity. Debt Cleanup 54, Quality 96.2, and Indispensability 100 — meaning the highest module ownership ratio in all of React's codebase: without Sebastian's code, it doesn't stand. Line up the 8 years of gravity readings and there's nothing flashy. But his code kept surviving (Survival 79.2). Dan Abramov with 1,890 commits at Survival 0.1, Brian Vaughn with 1,627 commits at Survival 0.1 — as waves of rewrites swept away code, Sebastian's 1,495 commits remained in the strata at Survival 79.2. As other engineers departed and code was rewritten, the ratio of code that didn't disappear grew. In 2024, a threshold was crossed. The quietly accumulated strata became the gravity field itself. You can't see this in a snapshot. Only by tracing the annual gravity distribution over time does this story surface: "A Cleaner who was never at the gravitational center for 8 years became the gravitational pole after tectonic shifts in the codebase." This is the strength of the Gravity Map's temporal axis
Kubernetes: Gravity concentration 0.8%. Structure distributed across 5,000+ contributors

An even more interesting finding: gravity concentration varies 4.8× across language families.

Language category	Gravity concentration	Structural physics
Go (anti-framework culture)	16.4%	Concentrated in few architects
Rust / Scala (expressive)	6.7%	Type systems distribute structure
Rails / Laravel (framework-driven)	5.1%	Frameworks absorb structure
C / C++ (systems)	3.4%	Most distributed

Here's the critical point: this is not about which structure is "correct."

esbuild's 92.5% concentration isn't "bad design" — at a scale where one person can hold the entire system in their head, it may be optimal. Kubernetes' 0.8% distribution isn't "better because it's distributed" — at 5,000+ contributors, distribution is inevitable, and that itself is a design outcome.

What EIS observes is the physics of structure, not a judgment of quality. A telescope describes the shape of galaxies. It doesn't claim spiral galaxies are "better" than elliptical ones.

Top 50: The Brightest Stars in the OSS Universe

We also mapped the Gravity distribution of the top 50 engineers — structural influence — across all 29 projects.

OSS Gravity Map — Top 50 Engineers

Salvatore Sanfilippo (Redis), Alexey Milovidov (ClickHouse), Ritchie Vink (Polars) — their gravity saturates the scale. But the more remarkable finding was the 440 engineers the world has never heard of. They don't give conference talks. They don't have mass Twitter followings. Yet when we traced the gravitational field lines through the codebase, there they were — quietly holding the architecture together. We call them Hidden Architects.

A note on cross-universe comparison. Gravity is a relative signal within each repository, not an absolute value across repositories. Josh Goldberg's Gravity 100 in eslint and Jordan Liggitt's Gravity 77.3 in Kubernetes are observations from different universes — they cannot be directly compared. This is Engineering Relativity (Ch. 8) in action.

However, the distortion is partially mitigated by Gravity's composition. Its three axes — module ownership ratio, design involvement ratio, and cross-cutting reach — are proportion-based signals, not absolute volume. Owning 80% of modules in a 50-module project and owning 80% in a 500-module project both register the same Indispensability signal. The ranking captures who shaped the gravitational field of their universe, not who works in the "biggest" universe.

Think of it as mapping the brightest star in each galaxy. Some galaxies are larger than others, but in every galaxy, the star that shapes the gravitational field is observable.

Full analysis: OSS Gravity Map

What This Is NOT

We don't measure engineers. We reveal how software actually works.

This series uses the word "combat power" (戦闘力) to describe impact. It's a catchy metaphor borrowed from Dragon Ball — but it carries a dangerous implication: that engineers can be ranked on a single axis of strength.

They can't. And EIS doesn't try to.

So what does it measure? Simple: in this codebase, how much did you build, how much influence did you leave, and how much of what you wrote is still standing? That's it. Not "how good an engineer are you" — but "what trace did you leave in this particular universe of code."

True engineering excellence can only be quantified by traces left across multiple universes. High impact in one codebase is a local observation. Consistent high impact across different codebases, different teams, different domains — that's reproducible gravity. That's the difference between a bright star in one galaxy and a force of nature.

A few things to keep in mind:

EIS measures codebase impact, not engineering ability. An impact of 40 means "on this codebase, this person's code is surviving, shaping architecture, and cleaning up debt." It does not mean they are objectively a better engineer than someone at 30. Move them to a different codebase, and the observations might invert. (We call this Engineering Relativity.)

Signals without context are dangerous. A low Survival signal might mean poor design — or it might mean the engineer is actively rewriting legacy code (Rescue style). A strong signal in a poorly designed codebase might mean "nobody can refactor your code away." Always interpret with context.

Non-code contributions are invisible to git. Code review quality, mentoring, documentation, psychological safety, domain expertise — these matter enormously but leave no trace in git log. EIS captures what git records, nothing more. Using it as a complete evaluation of an engineer would be harmful and wrong.

It's not a surveillance tool. EIS is a telescope — it reveals structures that already exist. It doesn't create hierarchies. If it's used to rank and punish rather than to understand and improve, it has failed its purpose.

Time-decayed survival resists gaming. You can't inflate your impact with busy work. Only code that remains in the codebase months later counts. The debt cleanup axis makes it structurally impossible to achieve high impact by generating work for others.

The telescope measures the brightness of stars. It doesn't decide which stars deserve to exist.

The Series

This blog series — Git Archaeology — applies EIS to real teams and explores what the numbers reveal.

Series

Chapter 1: Individual Observation →

Install

# Homebrew
brew tap machuz/tap && brew install eis

# Go
go install github.com/machuz/eis/cmd/eis@latest

GitHub: eis

Git Archaeology — A Complete Theory of Software Universes

machuz — Sun, 15 Mar 2026 16:53:54 +0000

What if your git history could tell you who really shaped your codebase?

Over 17 chapters (0–16), I built a theory of software — starting from a simple question and ending with a cosmology. This is the complete arc, condensed into one read.

0. The Telescope

It started with a frustration: "This team is strong. But I had no words to explain it."

Over the years, I've recruited several strong engineers by reaching out personally. Why did they come? I believe it's because they felt: "This person actually sees my work." Not commit counts — but whether code survives, whether you contribute to architecture, whether you clean up debt.

I had that observer's eye. EIS is that eye turned into an open-source telescope.

Math has complexity theory. Programming languages have type theory. But software architecture still lacks a unified scientific foundation — 30 years of academic attempts (ADLs, ATAM) remain fragmented and haven't made it into practice. In the age of AI, what matters most is structure. If EIS can become a tool for making architecture a science, I'd be glad.

So I built this telescope. Using nothing but git log and git blame, I quantified engineering impact across 7 axes:

Axis	What it measures
Production	Volume of output (time-decayed)
Quality	Self-revision discipline
Survival	How long code lives without being rewritten
Design	Structural influence — files touched by others
Breadth	Reach across the codebase
Debt Cleanup	Cleaning up others' debt
Indispensability	How much of the codebase you "own" via blame

From these, three topologies emerge: Role (Architect / Anchor / Producer), Style (Builder / Balanced / Mass), and State (Active / Growing / Fragile / Former).

The numbers were eerily accurate. Silent heroes surfaced. Hidden risks became visible.

Quantify what you can. Qualitatively supplement what you can't. That order matters.

Deep dive: Chapter 0 — Introduction, Chapter 1, Chapter 2

II. Evolution

When I added timelines — quarterly snapshots of signals — stories emerged.

An engineer's Role shifts from Producer to Anchor to Architect. Another's signals plateau — not from stagnation, but from strategic patience. A departure trajectory becomes visible three quarters before anyone notices.

Cold numbers tell the most human stories.

From these timelines, I extracted evolution laws:

Builder is a prerequisite for Architect — you cannot design what you haven't built
Producer is metabolism, not regression — sometimes the best Architects go back to producing
Backend Architects converge; Frontend Architects branch — different gravitational physics
Departed Architects leave "souls" in the code — laying them to rest through Debt Cleanup is sacred work

Deep dive: Chapter 3, Chapter 4, Chapter 5, Chapter 6

III. Cosmology

The deeper I looked, the more codebases looked like universes.

Physics	Software
Big Bang	First commit — initial conditions determine everything
Stars	Engineers
Gravity	Structural influence — great engineers bend the gravity of codebases
Dark Matter	Work invisible in commits: reviews, design discussions, mentoring, culture
Entropy	Code rot — left alone, code always tends toward disorder
Black Holes	Engineers who concentrate dependency instead of distributing structure
Collapse	What happens when a Black Hole Engineer leaves

This isn't metaphor. It's structural correspondence.

Gravity is the central concept. Not all code is equal. An engineer who creates a module boundary that 50 files depend on has generated gravity — a structural force that shapes everything around it.

Dark matter is what the telescope can't see. Culture, mentoring, design discussions, planning — these never appear in commits, but they determine the entire structure of the universe. A telescope must know its own limits.

Entropy is the default. Software always rots. Development is fundamentally a battle against entropy. Every EIS axis maps to either increasing entropy (Production) or fighting it (Quality, Design, Survival).

Collapse is what happens when gravity concentrates instead of distributes. A Black Hole Engineer writes great code — but when they leave, the codebase collapses instantly. A good Architect designs for the universe after they're gone.

Stars are not forever. That's why structure matters.

Deep dive: Chapter 7, Chapter 8, Chapter 9, Chapter 10, Chapter 11, Chapter 12

IV. Civilization

Most codebases die within a few years. Entropy wins. The team changes. Knowledge scatters. Someone says "let's rewrite from scratch."

But a few survive. Linux. Git. PostgreSQL. React. Their creators left, contributors turned over across generations, and the structure persisted. These are not repositories. They are civilizations.

Civilization requires three roles:

Civilization =
  Architect  → creates gravity (structure)
  + Anchor   → maintains order (stability)
  + Producer → expands territory (growth)

Remove any one and the equation breaks:

Missing	Result
No Architect	Growth without structure — entropy wins
No Anchor	Beautiful but fragile — collapses when Architect leaves
No Producer	Structure without growth — fossilization

The most important engineers build systems that don't need them. That's the civilization test: does the structure survive after the Architect leaves?

Deep dive: Chapter 13, Chapter 14

V. AI Creates Stars, Not Gravity

AI is a starburst — generating code at unprecedented rates.

But code without structure is entropy. No matter how many stars form, without gravity, no galaxy is born.

In the age of AI, the scarcest engineering capability shifts:

Era	Scarcest capability
Pre-AI	Writing code (Production)
Post-AI	Generating gravity (Design, Survival)

The engineers who thrive are not those whose primary differentiator is implementation speed. They are the ones who generate gravity — Code Architects who create structure, and Code Custodians who fight entropy.

AI becomes a gravity amplifier. An Architect who once shaped one codebase can now shape ten. The muscle that matters is not the muscle for writing code — it's the muscle for generating gravity.

AI creates stars. But engineers are the ones who shape gravity.

Deep dive: Chapter 15

VI. The Engineers Who Shape Gravity

Software engineering exists between two kinds of time.

Git remembers the past. AI imagines the future.

Between them, engineers shape gravity — creating structure, creating order, keeping the system from collapsing.

Where gravity exists, code is not mere fragments — it becomes structure. When structure emerges, systems persist beyond time. That is not just a repository. It becomes a civilization.

Git remembers the past.
AI imagines the future.

Between them, engineers shape gravity.

And from that gravity,
software civilizations emerge.

Deep dive: Chapter 16 — Final

Does your code universe have gravity?

Point the telescope and see.

❯ brew tap machuz/tap && brew install eis
❯ eis analyze --recursive ~/your-workspace

      ✦       *        ✧

       ╭────────╮
      │    ✦     │
       ╰────┬───╯
   .        │
            │
         ___│___
        /_______\

   ✧     the Git Telescope     ✦

Full Series

GitHub: eis — CLI tool, formulas, and methodology all open source. brew tap machuz/tap && brew install eis to install.

If this was useful: Sponsor on GitHub

Git Archaeology #16 (Final) — The Engineers Who Shape Gravity

machuz — Sun, 15 Mar 2026 14:10:37 +0000

Git remembers the past. AI imagines the future. Between them, engineers shape gravity.

Previously

In Chapter 15, I wrote about the relationship between AI and engineers. AI creates stars. But it does not create gravity.

Across 16 chapters of git archaeology — from quantifying combat power, through team structure, timelines, cosmology, civilization, and AI — I've arrived at the final question.

Software engineering exists between two kinds of time.

The past and the future.

Git Remembers the Past

Commits.
Refactors.
Design changes.

Git is not merely a code history.
It preserves the history of an engineer's decisions.

Where did the structure change?
Who altered the design?
Which code survived, and which was erased?

Git is the memory device of the software universe.

AI Imagines the Future

New code.
New designs.
New possibilities.

AI generates the future.

But

Software cannot exist on the past alone, nor the future alone.

Software exists

between memory and imagination.

Git remembers the past. AI imagines the future.

So what are engineers doing in between?

Writing code?

No.

What engineers create is

gravity.

Creating structure.
Creating order.
Keeping the system from collapsing.

That is gravity.

Where gravity exists, code is not mere fragments — it becomes structure.

When structure emerges, systems can persist beyond time.

That is not just a repository.

It becomes a civilization.

What EIS Is

So I built a telescope — to observe that gravity.

That is EIS.

EIS is not a metric for measuring code volume.

It is

a telescope for observing who generated gravity.

And that gravity can be observed not through intuition, but through history.

In the Age of AI

AI will write more code than humans ever could.

But code volume alone does not make a universe.

No matter how many stars form, without gravity, no galaxy is born.

AI creates stars.

But

engineers are the ones who shape gravity.

Git remembers the past.
AI imagines the future.

Between them, engineers shape gravity.

And from that gravity,
software civilizations emerge.

                      ✦ AI Era
                     /       \
                Culture     Stars (AI)
                    |          |
                Civilization   |
              /      |      \  |
       Architect   Anchor  Producer
              \      |      /
                 Gravity
                /       \
          Dark Matter   Entropy
               |           |
               |        Collapse
                \        /
              Code Universe
            /      |      \
       Origin    Stars   Relativity
                   |
                Timeline
                   |
             Git Telescope
                   |
              Git History

Across 16 chapters, the series turned out to be a complete mapping from cosmology to software.

Physics             Software
─────────────────────────────
Matter        →     Code
Gravity       →     Reuse
Dark Matter   →     Anchor, PO, PdM, QA...
Entropy       →     Tech Debt
Stars         →     Engineers
Civilization  →     Team
Telescope     →     EIS

Software is not a collection of code.
It is a universe of structure, shaped through time.

Within that universe, the ones who create order and make civilization possible —

they are the engineers who shape gravity.

Does your code universe have gravity?

Point the telescope and see.

❯ brew tap machuz/tap && brew install eis
❯ eis analyze --recursive ~/your-workspace

      ✦       *        ✧

       ╭────────╮
      │    ✦     │
       ╰────┬───╯
   .        │
            │
         ___│___
        /_______\

   ✧     the Git Telescope     ✦

Series

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 15: AI Creates Stars, Not Gravity | Final Chapter

Git Archaeology #15 — AI Creates Stars, Not Gravity

machuz — Sun, 15 Mar 2026 13:50:54 +0000

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

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 →

Git Archaeology #14 — Civilization: Why Only Some Codebases Become Civilizations

machuz — Sun, 15 Mar 2026 13:50:52 +0000

Most code universes die. Only a few become civilizations.

Previously

In Chapter 13, I looked back at the entire series as Software Cosmology — the unified framework mapping code to the universe.

But there is one more stage beyond the universe. One I hadn't written about yet.

Beyond the Universe

Across the previous chapters, we saw that software can be understood as a universe:

Gravity — structural influence of engineers (Ch. 7)
Stars — the engineers themselves (Ch. 1–)
Dark Matter — invisible forces that don't appear in commits (Ch. 10)
Entropy — unattended code always rots (Ch. 11)
Collapse — concentrated gravity destroys structure (Ch. 12)

These are the physics of code universes.

But in the real universe, there is one more stage. Matter coalesces, stars form, galaxies take shape. And in vanishingly rare cases, order begins to sustain itself, expand, and propagate across generations.

That is civilization.

Most Code Universes Die

You don't need statistics to know this. Most software projects die within a few years.

They launch. Code is written in a burst of momentum. The team changes. Knowledge scatters. Entropy wins. Eventually someone says, "it'd be faster to rewrite from scratch," and the universe collapses.

This isn't unusual. It's the default outcome.

Expecting a codebase to spontaneously develop order is like expecting a room to clean itself. The second law of thermodynamics applies to code without mercy.

But a Few Are Different

Linux. Git. PostgreSQL. React.

The first commit of each of these repositories was made over a decade ago. Linux — over 30 years ago.

Their creators have stepped back or moved on. Contributors have cycled through multiple generations. Yet the structure persists. They resist entropy. They don't just survive — they evolve.

These are not mere repositories.

They are civilizations.

Defining Civilization

Civilization is not simply "code that exists."

Civilization is structure that persists beyond time and can self-extend without its creators.

This definition contains three conditions:

Structure exists — not just files piled up, but a skeleton with design intent
It outlasts time — it survives longer than any single person's tenure
It self-extends — it can absorb new features and new contributors without external intervention

Conversely, a project that stops functioning when one person leaves is not a civilization. That is a kingdom. When the king leaves, it falls.

The Three Roles That Build Civilization

Mapped to EIS's classification system, the elements of civilization are surprisingly simple.

Architect — The One Who Creates the Skeleton

Architects generate gravity. Module structure, naming conventions, dependency direction — these design decisions bring order to the code universe.

But as Chapter 12 showed, Architect gravity is also dangerous. When gravity concentrates in a single Architect, it becomes a Black Hole.

A civilization's Architect is one who creates gravity, then releases it. After building the structure, they enable others to build on top of it. Like O. in Chapter 5, who transitioned from Architect to Producer — structure complete, now producing on top of it.

This is the essence of the Architect/Builder from Chapter 13. The founder of a civilization must be an architect who is simultaneously prepared to leave.

Anchor — The One Who Maintains Order

Anchors work like dark matter. They're not flashy. They don't create new structures. But they stabilize existing structure without breaking it.

Chapter 10 called it "invisible gravity" — Anchors are exactly that. A team with Architects but no Anchors has beautiful but fragile structure. Nobody maintains it, so the moment the Architect leaves, entropy wins.

The dual-Anchor formation on our BE team wasn't coincidence — it's a stability condition for civilization. Two Anchors supporting the structure means that when one Architect departs, the structure doesn't collapse. Redundancy in maintenance is as important as brilliance in design.

Producer — The One Who Expands Territory

Producers write new code. They extend the territory of civilization.

But Producers alone don't make a civilization. Without an Architect's structure, continuous production is just chaotic expansion — entropy increasing. As Chapter 11 established, code left to itself rots. Structureless production accelerates decay.

However, when Producers build on top of an Architect's structure, civilization expands. Like new stars forming within a gravitational field, new code is laid down within the framework of order.

The Civilization Equation

Combining the three roles, the conditions for civilization reduce to a simple equation:

Civilization =
  Architect  → creates gravity (structure)
  + Anchor   → maintains order (stability)
  + Producer → expands territory (growth)

Remove any one, and civilization cannot form.

Missing Role	Result	Cosmic Analogy
No Architect	Structureless expansion. Code grows but has no design	A universe without gravity — matter disperses
No Anchor	Beautiful but fragile. Collapses when Architect leaves	A galaxy without dark matter — stars scatter
No Producer	Structure exists but doesn't grow. Fossilizes	A galaxy where star formation has stopped — cold and dark

Architect/Builder + Dual-Anchor — The Rare Structure of a Civilization-Ready Team

Let me talk about our BE team.

As I mentioned in Chapter 13, our backend runs on a formation of one Architect/Builder plus two Anchors. When I asked an AI "what do you think of this composition?" it responded that a dual-Anchor setup is extremely rare. That made me happy.

Why is this structure unusual? And why is it uniquely suited for civilization?

Comparison with Common Team Structures

Most teams fall into one of these patterns:

Structure	Characteristics	Civilization Fitness
No Architect + Producers	Production without design. Code grows but has no structure	Low. Entropy always wins
Classical Architect + Producers	Architect only designs, never implements	Moderate. Design philosophy vanishes when Architect leaves
Architect + Single Anchor	Structure + maintenance, but no Anchor redundancy	Moderate. Anchor departure leaves no maintainer
Architect/Builder + Dual-Anchor	Structure demonstrated through implementation, two maintainers	High

What It Means to Be an Architect/Builder

As I wrote in Chapter 13, an Architect/Builder is fundamentally different from an Architect who only designs. They create the structure and write code on top of it themselves.

This is critically important for civilization because design intent survives as implementation.

A Classical Architect's design philosophy often exists only in their head. Even when documented, the documentation frequently diverges from the actual implementation. When the Architect leaves, the why behind the structure is lost.

With an Architect/Builder, design philosophy is embedded in the code itself. Naming conventions, module decomposition, dependency direction — these are implemented by the Architect's own hands. Subsequent engineers can read the why directly from the code.

The code becomes the documentation of its own design. This is the civilizational value of the Architect/Builder.

What It Means to Have Dual-Anchors

A team with one Anchor has no redundancy in maintenance. If that Anchor takes leave, transfers, or burns out — the maintainer of order disappears.

With dual-Anchors, order maintenance is distributed. If one falls, the other continues supporting the structure. This is critical as a stability condition for civilization.

What's even more interesting is the complementary effect. The modules guarded by Anchor A and Anchor B are different, so coverage expands. It's not just backup — the surface area of maintenance doubles.

The Civilizational Durability This Structure Creates

The greatest effect of combining Architect/Builder with dual-Anchors is that the probability of civilization surviving the Architect's departure jumps dramatically.

Design philosophy is embedded in code (the Architect/Builder's legacy)
Order maintainers are redundant (the dual-Anchor stability)
New Producers can join and write code that fits the structure (civilization's self-extension)

This didn't happen by accident. But it wasn't deliberately designed either. Looking back, I think strong engineers gathered, and the structure naturally converged to this formation.

Perhaps civilization isn't something you design. Perhaps it's something that emerges naturally when conditions align.

The Lindy Effect of Code

There's a deeper principle at work here. Nassim Taleb's Lindy Effect states that the longer something non-perishable has survived, the longer its expected remaining lifespan.

A codebase that has been maintained for 10 years is more likely to survive another 10 years than a codebase that launched last month. This isn't mysticism — it's selection bias made real. The codebase has already proven it can survive team changes, technology shifts, and entropy. Each year it survives is evidence that its structure works.

This is why civilizations compound. Linux isn't successful despite being old. It's successful because it's old. Thirty years of Succession, maintenance, and evolution have embedded design intent so deeply into the structure that new contributors naturally write code that fits.

EIS can see this effect indirectly. A codebase with consistently high Survival across multiple timeline periods is exhibiting Lindy behavior — its structure is durable enough that code doesn't need to be rewritten. The architecture has proven itself.

The Bus Factor Paradox

Chapter 1 introduced Bus Factor as a risk metric. But civilization reframes it entirely.

A civilization's Bus Factor approaches infinity.

Not because no one is important, but because the system has made itself independent of any single contributor. Design intent is encoded in the structure. Maintenance patterns are shared across Anchors. Production conventions are absorbed by new Producers through the code itself.

The paradox is this: the most important engineers build systems that don't need them. The highest expression of engineering impact is making yourself replaceable — not because you're weak, but because the structure you built is strong enough to stand on its own.

This is why EIS measures Indispensability but weights it at only 5%. High Indispensability is a risk signal. In a civilization, Indispensability is distributed.

The Civilization Test

And here the real test begins.

Does the civilization continue after the Architect leaves?

This is the civilization test.

While Architects are present, any project can maintain order. As long as design intent lives in the Architect's head, code evolves in the right direction.

But Architects don't stay forever. They change jobs. They move to other projects. They burn out.

What happens at that moment separates civilization from kingdom.

In a kingdom, order collapses when the king leaves. Design intent existed only in the king's head. The remaining team doesn't understand the why behind the code. Changes that contradict the design start creeping in. Structure rots from the inside.

In a civilization, order continues after the Architect departs. Design intent is embedded in the structure itself. New participants can write code that fits the structure naturally. Anchors maintain order. Producers continue building on top of the foundation.

Can EIS Measure Civilization?

EIS measures individual scores and team health. It doesn't directly measure civilization — not yet.

But the precursors of civilization appear in EIS data.

1. Architect Diversification

In teams heading toward civilization, there isn't just one Architect. Like the dual-Anchor formation from Chapter 13, multiple Architects generate gravity in different domains.

In EIS timelines, if multiple members show high Design scores and each has healthy (green) Gravity — that codebase is approaching civilization.

2. Succession Traces

Another sign: generational transition visible in timelines.

One Architect's Design gradually declines while another member's Design rises. A member's Role transitions from "Producer → Architect." This is evidence of structural knowledge propagating.

H.'s "succession Architect" movement from Chapter 13 — diving into R.M.'s structure to absorb its design philosophy — is exactly this. Civilization requires Succession because it must outlast any single Architect's tenure.

3. Stable Survival Rates

In civilized codebases, Survival stays consistently high. Code that's written isn't rewritten — it persists. This proves the structure is robust: good design means new requirements can be met by extending existing code rather than replacing it.

High, stable Survival across timeline periods is a proxy for structural quality — and a precursor to civilization.

The Scale of Civilization

So far we've discussed civilization within a single team. But civilization scales further.

Organizational Civilization

Shared design philosophies, coding conventions, and architecture patterns maintained across multiple teams — that's organizational civilization.

When a new team launches, they don't design from zero. They build on the civilization's infrastructure: common libraries, common patterns, common vocabulary. The organization's architecture becomes the soil in which new codebases grow.

Open Source Civilization

Linux and PostgreSQL are civilizations because their structure is maintained beyond organizational boundaries. Contributors are worldwide and may never meet. But the code's structure — naming conventions, module boundaries, commit message conventions — these "rules of civilization" are shared. As long as the rules hold, order persists.

In OSS civilization, CONTRIBUTING guides and architecture documents are the legal codex. New participants write code that follows the codex, and civilization extends across generations without any central authority.

When Civilization Becomes Culture

Civilization was about structure persisting beyond time.

But there is a stage beyond.

When structure begins to change how people behave — it becomes culture.

Imagine two Architects committing different design philosophies to the same module. In verbal design debates, the loudest voice might win. But run eis timeline and track the Design axis — history shows which design survived, which generated gravity.

Code becomes the judge.

In early Silicon Valley, they say that simply posting task progress on a board was enough to make talented engineers compete with natural intensity. That wasn't visibility creating competition. It was visibility creating pride.

Run eis timeline every week. See what gravity you left behind. When that becomes a team's routine — culture already exists.

Civilization is structure surviving after the Architect leaves. Culture is the next Architect emerging naturally without anyone forcing it. Structure changes behavior, behavior creates new structure. When that cycle starts turning, a codebase transcends civilization and becomes culture.

Our Civilization

Let me be honest.

I don't know yet whether our codebase is a civilization. Civilization takes time. Claiming it after two or three years is premature.

But the team I described in Chapter 13 shows signs:

R.M. created a new universe in FE, and H. is inheriting its structure (Succession)
P. completed the hardest BE domain through autonomous design (Architect diversification)
The dual-Anchor formation ensures structural redundancy (Order maintenance)
PO and PdM as dark matter support civilization through non-code channels (Invisible infrastructure)

Whether we become a civilization depends on what comes next.

But we have proof from another universe. In past codebases, we built structure that survived beyond team turnover. And the culture we shared in that previous universe — the culture of visualizing design gravity, of taking pride in structure — we've carried it into this team. So I'm confident. The conviction that this team can build a civilization — that was taught to us by a previous universe.

Will this structure survive after I leave?

That's the question. And facing that question honestly is, I believe, the final work of an Architect/Builder.

Does the code you're working with carry the scent of civilization?

Point the telescope at your own code universe — and see what you find.

❯ brew tap machuz/tap && brew install eis
❯ eis analyze --recursive ~/your-workspace

Maybe you'll see the signs of civilization in your codebase too.

Series

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 13: Cosmology of Code | Chapter 15: AI Creates Stars, Not Gravity →

Git Archaeology #15 — AI Creates Stars, Not Gravity

machuz — Sun, 15 Mar 2026 13:12:47 +0000

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.

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.

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

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.

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 signals 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

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.

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)

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

A succession of the soul to AI.

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

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.

But beyond this lies something far bigger.

When Architects' Souls Accumulate

A single CLAUDE.md contains one Architect's design philosophy.

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.

AI can become a carrier of culture itself.

The Gravity Amplifier

In the AI era, that limit vanishes.

AI amplifies the Architect's gravity.

A single Architect's gravity gets amplified 10x, 100x through AI.

The Architect's radius of influence expands dramatically.

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.

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

This is also an application of Chapter 8's Engineering Relativity — the same engineer gets different signals 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.

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

GitHub: eis — 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 →

Git Archaeology #14 — Civilization: Why Only Some Codebases Become Civilizations

machuz — Sun, 15 Mar 2026 12:52:10 +0000

Most code universes die. Only a few become civilizations.

Previously

In Chapter 13, I looked back at the entire series as Software Cosmology — the unified framework mapping code to the universe.

But there is one more stage beyond the universe. One I hadn't written about yet.

Beyond the Universe

Across the previous chapters, we saw that software can be understood as a universe:

Gravity — structural influence of engineers (Ch. 7)
Stars — the engineers themselves (Ch. 1–)
Dark Matter — invisible forces that don't appear in commits (Ch. 10)
Entropy — unattended code always rots (Ch. 11)
Collapse — concentrated gravity destroys structure (Ch. 12)

These are the physics of code universes.

That is civilization.

Most Code Universes Die

You don't need statistics to know this. Most software projects die within a few years.

They launch. Code is written in a burst of momentum. The team changes. Knowledge scatters. Entropy wins. Eventually someone says, "it'd be faster to rewrite from scratch," and the universe collapses.

This isn't unusual. It's the default outcome.

Expecting a codebase to spontaneously develop order is like expecting a room to clean itself. The second law of thermodynamics applies to code without mercy.

But a Few Are Different

Linux. Git. PostgreSQL. React.

The first commit of each of these repositories was made over a decade ago. Linux — over 30 years ago.

Their creators have stepped back or moved on. Contributors have cycled through multiple generations. Yet the structure persists. They resist entropy. They don't just survive — they evolve.

These are not mere repositories.

They are civilizations.

Defining Civilization

Civilization is not simply "code that exists."

Civilization is structure that persists beyond time and can self-extend without its creators.

This definition contains three conditions:

Structure exists — not just files piled up, but a skeleton with design intent
It outlasts time — it survives longer than any single person's tenure
It self-extends — it can absorb new features and new contributors without external intervention

Conversely, a project that stops functioning when one person leaves is not a civilization. That is a kingdom. When the king leaves, it falls.

The Three Roles That Build Civilization

Mapped to EIS's classification system, the elements of civilization are surprisingly simple.

Architect — The One Who Creates the Skeleton

Architects generate gravity. Module structure, naming conventions, dependency direction — these design decisions bring order to the code universe.

But as Chapter 12 showed, Architect gravity is also dangerous. When gravity concentrates in a single Architect, it becomes a Black Hole.

This is the essence of the Architect/Builder from Chapter 13. The founder of a civilization must be an architect who is simultaneously prepared to leave.

Anchor — The One Who Maintains Order

Anchors work like dark matter. They're not flashy. They don't create new structures. But they stabilize existing structure without breaking it.

Producer — The One Who Expands Territory

Producers write new code. They extend the territory of civilization.

However, when Producers build on top of an Architect's structure, civilization expands. Like new stars forming within a gravitational field, new code is laid down within the framework of order.

The Civilization Equation

Combining the three roles, the conditions for civilization reduce to a simple equation:

Civilization =
  Architect  → creates gravity (structure)
  + Anchor   → maintains order (stability)
  + Producer → expands territory (growth)

Remove any one, and civilization cannot form.

Missing Role	Result	Cosmic Analogy
No Architect	Structureless expansion. Code grows but has no design	A universe without gravity — matter disperses
No Anchor	Beautiful but fragile. Collapses when Architect leaves	A galaxy without dark matter — stars scatter
No Producer	Structure exists but doesn't grow. Fossilizes	A galaxy where star formation has stopped — cold and dark

Architect/Builder + Dual-Anchor — The Rare Structure of a Civilization-Ready Team

Let me talk about our BE team.

Why is this structure unusual? And why is it uniquely suited for civilization?

Comparison with Common Team Structures

Most teams fall into one of these patterns:

Structure	Characteristics	Civilization Fitness
No Architect + Producers	Production without design. Code grows but has no structure	Low. Entropy always wins
Classical Architect + Producers	Architect only designs, never implements	Moderate. Design philosophy vanishes when Architect leaves
Architect + Single Anchor	Structure + maintenance, but no Anchor redundancy	Moderate. Anchor departure leaves no maintainer
Architect/Builder + Dual-Anchor	Structure demonstrated through implementation, two maintainers	High

What It Means to Be an Architect/Builder

As I wrote in Chapter 13, an Architect/Builder is fundamentally different from an Architect who only designs. They create the structure and write code on top of it themselves.

This is critically important for civilization because design intent survives as implementation.

The code becomes the documentation of its own design. This is the civilizational value of the Architect/Builder.

What It Means to Have Dual-Anchors

A team with one Anchor has no redundancy in maintenance. If that Anchor takes leave, transfers, or burns out — the maintainer of order disappears.

With dual-Anchors, order maintenance is distributed. If one falls, the other continues supporting the structure. This is critical as a stability condition for civilization.

The Civilizational Durability This Structure Creates

The greatest effect of combining Architect/Builder with dual-Anchors is that the probability of civilization surviving the Architect's departure jumps dramatically.

Design philosophy is embedded in code (the Architect/Builder's legacy)
Order maintainers are redundant (the dual-Anchor stability)
New Producers can join and write code that fits the structure (civilization's self-extension)

This didn't happen by accident. But it wasn't deliberately designed either. Looking back, I think strong engineers gathered, and the structure naturally converged to this formation.

Perhaps civilization isn't something you design. Perhaps it's something that emerges naturally when conditions align.

The Lindy Effect of Code

There's a deeper principle at work here. Nassim Taleb's Lindy Effect states that the longer something non-perishable has survived, the longer its expected remaining lifespan.

The Bus Factor Paradox

Chapter 1 introduced Bus Factor as a risk metric. But civilization reframes it entirely.

A civilization's Bus Factor approaches infinity.

This is why EIS measures Indispensability but weights it at only 5%. High Indispensability is a risk signal. In a civilization, Indispensability is distributed.

The Civilization Test

And here the real test begins.

Does the civilization continue after the Architect leaves?

This is the civilization test.

While Architects are present, any project can maintain order. As long as design intent lives in the Architect's head, code evolves in the right direction.

But Architects don't stay forever. They change jobs. They move to other projects. They burn out.

What happens at that moment separates civilization from kingdom.

Can EIS Measure Civilization?

EIS measures individual scores and team health. It doesn't directly measure civilization — not yet.

But the precursors of civilization appear in EIS data.

1. Architect Diversification

In teams heading toward civilization, there isn't just one Architect. Like the dual-Anchor formation from Chapter 13, multiple Architects generate gravity in different domains.

In EIS timelines, if multiple members show high Design scores and each has healthy (green) Gravity — that codebase is approaching civilization.

2. Succession Traces

Another sign: generational transition visible in timelines.

One Architect's Design gradually declines while another member's Design rises. A member's Role transitions from "Producer → Architect." This is evidence of structural knowledge propagating.

3. Stable Survival Rates

High, stable Survival across timeline periods is a proxy for structural quality — and a precursor to civilization.

The Scale of Civilization

So far we've discussed civilization within a single team. But civilization scales further.

Organizational Civilization

Shared design philosophies, coding conventions, and architecture patterns maintained across multiple teams — that's organizational civilization.

Open Source Civilization

When Civilization Becomes Culture

Civilization was about structure persisting beyond time.

But there is a stage beyond.

When structure begins to change how people behave — it becomes culture.

Code becomes the judge.

Run eis timeline every week. See what gravity you left behind. When that becomes a team's routine — culture already exists.

Our Civilization

Let me be honest.

I don't know yet whether our codebase is a civilization. Civilization takes time. Claiming it after two or three years is premature.

But the team I described in Chapter 13 shows signs:

R.M. created a new universe in FE, and H. is inheriting its structure (Succession)
P. completed the hardest BE domain through autonomous design (Architect diversification)
The dual-Anchor formation ensures structural redundancy (Order maintenance)
PO and PdM as dark matter support civilization through non-code channels (Invisible infrastructure)

Whether we become a civilization depends on what comes next.

Will this structure survive after I leave?

That's the question. And facing that question honestly is, I believe, the final work of an Architect/Builder.

Does the code you're working with carry the scent of civilization?

Point the telescope at your own code universe — and see what you find.

❯ brew tap machuz/tap && brew install eis
❯ eis analyze --recursive ~/your-workspace

Maybe you'll see the signs of civilization in your codebase too.

Series

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 13: Cosmology of Code | Chapter 15: AI Creates Stars, Not Gravity →

Git Archaeology #13 — Cosmology of Code

machuz — Sat, 14 Mar 2026 21:28:39 +0000

Git archaeology is the astronomy of code universes.

Previously

In Chapter 12, I wrote about Collapse — good Architects and Black Hole Engineers.

This final chapter looks back at the entire series.

Software Cosmology

Over 13 chapters, I've been writing about git archaeology.

Looking back, a unified framework emerges.

Software Cosmology.

The Correspondence Table

Let me organize the cosmic metaphors used throughout this series.

Universe	Code Universe
Big Bang	The first commit (Ch. 9)
Stars	Engineers
Galaxies	Teams
Constellations	Architecture patterns (Ch. 9)
Gravity	Design influence (Ch. 7)
Dark Matter	Work invisible in commits (Ch. 10)
Entropy	Code rot (Ch. 11)
Black Holes	Engineers who concentrate dependency (Ch. 12)
Collapse	Key person departure (Ch. 12)
Nucleosynthesis	Structure that code leaves behind (Ch. 12)
Relativity	Same engineer, different signals (Ch. 8)
Observation	The act of reading git log (Ch. 7)
Telescope	Git
Starlight	Commits
Instrument	EIS — the Git Telescope

Why the Universe?

Why use cosmic metaphors for software measurement?

One reason.

Codebases follow the same laws as the universe.

There is gravity. There is entropy. There is the observer effect. Initial conditions determine structure. There is relativity.

This is not a metaphor.

Codebases are complex adaptive systems that follow laws isomorphic to physical laws.

Git is the telescope that records the light — commits — of this universe.

EIS is the instrument that analyzes the recorded light.

The Meaning of Observation

In Chapter 7, I wrote about "observing the universe of code."

Observation has two meanings.

1. Understanding

Observation is the first step toward understanding.

Read git log and you see the universe's history. Read git blame and you see the distribution of gravity. Use EIS and you see the properties of stars.

Without understanding, there can be no improvement.

2. Changing

Just like the Observer Effect in quantum mechanics, observation changes what is observed.

Engineers who see their EIS signals start to become conscious of their commit patterns.

Leaders who see team signals recognize structural distortions.

Organizations that see timelines correct the direction of evolution.

The act of observation itself changes the universe.

The Limits and Honesty of Measurement

In Chapter 10, I wrote about dark matter. EIS cannot see dark matter.

This is important honesty.

A measurement tool should be explicit about what it cannot measure.

What EIS shows is only starlight — the light of commits. Not the entire universe.

But with starlight alone, astronomy has made remarkable discoveries.

EIS is the same. From commits alone, we can learn many things — the nature of engineers, the structure of teams, patterns of evolution.

Measure accurately what is visible. Never forget that the invisible exists.

This is the stance of git archaeology.

Structural Memory — Git Stores Decision History

There's a concept that has been implicit throughout this series.

Structural Memory.

Git is thought to store "code." But what it fundamentally stores is — a history of decisions.

A commit is a record of "I decided to place this interface here." A blame result is the fact that "this design decision survived six months." A refactor is a record of "I chose to revise the previous decision."

What EIS measures isn't the volume of code. It's the impact of decisions.

Engineers with high Design axes have left many decisions about structure. Engineers with high Survival axes have left good decisions.

A codebase is not a collection of features. It's a sediment of decisions.

And git archaeology is the work of excavating that sediment.

Restoring Justice — Code Doesn't Lie

There's another theme running through this series.

In real organizations, loud voices get rewarded. Political skill gets rewarded. The person who speaks most in meetings becomes the "leader."

But code doesn't lie.

git blame records who actually built the structure. git log records who actually did the work.

EIS doesn't ask people about people. It makes the effort preserved in code visible — through code.

This is a restoration of justice.

The quiet engineer who was actually holding the team's structure together. The invisible work that existed as dark matter behind EIS numbers.

EIS isn't omniscient. It can't see dark matter. But at the very least — the facts recorded in code are immune to politics.

Gravity as Skill — The Ability to Create Structural Gravity

What is engineering ability?

The ability to write code? Knowledge of algorithms? Those matter.

But what this series has shown is another kind of ability.

The ability to create gravity in a structure.

Design that other code naturally depends on. Structure that other engineers intuitively follow. Abstraction that maintains order after you leave.

This is the ability to create "good gravity."

Gravity isn't measured by degrees or years of experience. It can only be measured as the actual track record of creating structure within a codebase.

Architect Reproducibility from Chapter 8 — engineers who create gravity regardless of which universe they enter — is evidence that this ability is real.

Observer Theory — Where EIS Stands

Finally, let me clarify EIS's position.

EIS is an observation instrument — the Git Telescope.

Astronomy doesn't grade stars. A telescope doesn't judge a star as "good" or "bad." It simply observes.

EIS is the same. It may look like it's profiling engineers. But what EIS does is observe the structure of a code universe and describe the properties of each star.

How to interpret the observed data — that's a human job.

Remember dark matter exists. Account for relativity. Understand the context of structural memory.

Measurement is objective, but interpretation requires wisdom.

This is Observer Theory — the observation philosophy of EIS.

Why I Built the Telescope

Let me get personal.

The motivation for building EIS was simple. I wanted to brag about my team.

We had a new product development planned for six months. The frontend team was exploring the new version ahead of us, but the backend — caught between enhancing the existing product and building the new one — had only 3.5 months of actual development time.

The scope was enormous. Abstracting the existing account system. Adding new concepts. Making those new concepts work with the existing product too. Integration, QA, fine-tuning for edge cases. We were desperately short on time.

But we charged ahead.

Why? Because I had teammates I'd been through hell with before, and I knew exactly how strong they were.

This is exactly the Architect Reproducibility from Chapter 8 — engineers who create gravity regardless of which universe they enter. We'd built structure together in a different codebase. We knew each other's gravitational fields. That's why we could leap into an unknown universe.

The result: a beautiful product was born. The "proof" phase of our engineering organization was complete, and we felt the culture of building good things take root across the company.

So — I want to point EIS at this crucible and see what it reveals.

Thirteen chapters of building this telescope. Now I'm turning it toward my own team. Not theory — actual commit logs, actual blame data, observing what happened during those three months.

What the Telescope Revealed

Let's point the telescope at this period.

Backend — machuz (the author) timeline:

Period	Impact	Quality	Commits	Lines	Breadth	Indisp	Role	Style
2025-Q3	93.2	67.4	1004	+113k/-48k	—	—	Architect	Builder
2025-Q4	87.7	74.5	656	+153k/-208k	—	—	Architect	Builder
2026-Q1	92.4	41.4	1120	+140k/-33k	100	100	Architect	Builder

Q1 2026 — the height of the new product crunch. Quality plummets from 74.5 to 41.4.

This isn't quality degradation. It's the trace of debugging and finishing during the frontend integration phase. The ratio of fix commits rose, pushing Quality signals down. But Commits hit their peak at 1120, Breadth=100 (commits across every repository), Indisp=100 (every module depends on this engineer).

One engineer crossing all domains, building structure, and simultaneously debugging to the finish line. That's what the signals show.

Looking at the frontend timeline too:

Author	Period	Commits	Lines	Role	Style	State
machuz	2025-Q4	85	+5k/-2k	—	Spread	Active
machuz	2026-Q1	313	+26k/-10k	—	Rescue	Active
R.M.	2025-Q4	1241	+178k/-122k	Architect	Builder	Active
R.M.	2026-Q1	592	+169k/-69k	Architect	Builder	Active

machuz accumulated 313 commits on the FE side too, Style shifting from Spread to Rescue. A backend engineer diving into frontend to support integration.

Meanwhile, FE lead R.M. evolved from Anchor to Architect in Q4 with 1241 commits. Building the entire frontend structure single-handedly.

FE R.M. — The star that created a new universe alone:

First, signals across all FE repositories:

Period	Impact	Prod	Quality	Survival	Design	Lines	Commits	Role	Style	State
2025-Q2	71.5	60	92	100	86	+30k/-15k	290	Architect	Balanced	Active
2025-Q3	73.6	92	97	100	65	+47k/-34k	414	Anchor	Balanced	Active
2025-Q4	83.4	100	73	100	100	+178k/-122k	1038	Architect	Balanced	Active
2026-Q1	76.4	100	84	84	100	+169k/-69k	1417	Anchor	Builder	Active

Impact 83.4, commits=1038 across all FE. Already high. But to see R.M.'s true gravitational field, we need to observe the new project's repository alone:

Period	Impact	Prod	Quality	Survival	Design	Lines	Commits	Role	Style	State
2025-Q4	51.8	100	85	100	100	+174k/-119k	993	Architect	Emergent	Active
2026-Q1	50.4	100	80	100	100	+168k/-68k	1398	Architect	Emergent	Active

R.M. is the engineer who built the new project's FE repository from scratch — creating its entire structure. On top of that, R.M. personally took on a significant share of the UI design. Architecture, implementation, and UI — all driven through by a single person.

Design=100, Survival=100, Role=Architect — both periods. Style=Emergent — the creative type. Not inheriting existing design, but generating structure from zero.

For the sheer volume of design decisions made, Impact 51.8/50.4 may look low. This is exactly what Style=Emergent represents — creating a new universe alone, code that no one else has touched yet, relative metrics like Breadth and Indispensability that don't fully activate. EIS measures "gravity within a team" — in a universe of one, relative gravity is hard to express.

But I know. From another universe, I know this design carries refined, high-quality gravity. R.M. and I built structure together in a different codebase, and I've experienced firsthand the soundness of this architectural thinking. How much structural intelligence lives behind these Impact numbers — the telescope alone can't see it. Only an observer who has shared another universe can understand the true intensity of this light.

Q4 — Prod=100, commits=993, Lines=+174k/-119k. A single engineer triggering the Big Bang of a new universe. This is exactly the "initial conditions determine structure" from Chapter 9. The architecture R.M. laid down in this period defined the gravitational field for the entire frontend that followed.

In Q1, commits reached 1398. Lines shift to +168k/-68k with deletions dropping sharply — the exploratory phase of destruction and reconstruction has given way to building up.

BE R.S. — The stable core holding the team's gravitational field:

Period	Impact	Prod	Quality	Design	Debt	Lines	Commits	Role	Style	State
2025-Q3	42.5	69	62	9	54	+49k/-12k	262	Producer	Balanced	Active
2025-Q4	37.9	53	85	16	58	+42k/-6k	216	Anchor	Balanced	Active
2026-Q1	40.5	50	77	38	35	+37k/-6k	327	Anchor	Balanced	Active

R.S. was a steady Anchor — but "steady" doesn't do justice to this story.

Look at Quality — 62 → 85 → 77. Q4's Quality 85 is among the highest on the team. R.S. was actively taking on customer inquiry responses, ensuring the quality of APIs that users directly interact with — and hitting these numbers while doing it.

Design climbs steadily: 9 → 16 → 38. In Q1, commits peak at 327 — an Anchor who's also stepping into design territory. R.S. took on a significant share of user-facing APIs, collaborating with K.M. and O. across the FE/BE boundary to bring the experience to completion.

And Debt Cleanup — 54 → 58 → 35. Quietly fixing other people's bugs. Resolving issues found through inquiry handling. The coordination that doesn't appear in commits — the dark matter work was substantial.

R.S. also appears in the FE domain in Growing state. A backend engineer reaching into frontend territory.

Stabilizing the team's gravitational field while guarding the last line of user experience. As the name Anchor implies — without this person, the team's gravity would have wavered.

BE P. — The other gravity supporting the crunch:

Period	Impact	Prod	Quality	Design	Debt	Lines	Commits	Role	Style	State
2025-Q3	35.5	42	94	12	26	+28k/-10k	296	Anchor	Balanced	Active
2025-Q4	48.3	100	98	13	55	+52k/-92k	438	Anchor	Mass	Active
2026-Q1	37.6	60	80	13	30	+41k/-11k	502	Anchor	Mass	Active

P. with Mass style — charging forward with high-volume commits, supporting the crunch.

The standout metric is Quality — 94→98→80. Maintaining this quality while operating in Mass style is an anomaly. In Q4, Prod=100 and Quality=98 simultaneously — pushing both volume and quality to extremes at the same time. Lines +52k/-92k reveals that this development involved large-scale refactoring of existing code.

The Mass period in Q4-Q1 was when P. took on the most complex and operation-heavy domain in the entire project head-on — with zero prior domain knowledge. The original design we'd agreed on turned out to be unworkable once implementation began. I deferred to P.'s judgment — and P. rebuilt that domain with a design of their own, and delivered it.

And P. was simultaneously handling the handover and deadlines of an entirely separate domain while putting up these numbers. The coordination and knowledge transfer that don't appear in commits — the ratio of dark matter work was enormous.

P. has also inherited my architecture in the past. In another universe, P. served as an Architect who carried structure on their shoulders. That means knowledge embedded in architecture transfers smoothly between us, and I know that if needed, P. can take over design wholesale. Having an engineer you can trust at your back. In this crucible, that mattered more than any signal can show.

FE O. — Laid the foundation, then committed to the finish:

Period	Impact	Prod	Quality	Survival	Design	Lines	Role	Style
2025-Q1	60.1	64	76	24	100	—	Architect	Builder
2025-Q2	48.5	61	69	12	24	+31k/-23k	Producer	Emergent
2025-Q3	36.5	52	62	44	0	+32k/-13k	Producer	Balanced
2025-Q4	52.8	45	60	100	1	+25k/-12k	Producer	Balanced

In Q1, Architect/Builder with Design=100 — a star creating FE structure. But through discussions with R.M., some of O.'s structure was replaced by R.M.'s. Survival at 24 → 12 reflects this — two gravitational fields were colliding within the same repository.

From Q3 onward, R.M. shifted resources to the new repository, and the collision subsided. Survival jumped from 44 to 100. While watching a new universe being built in parallel, carrying the anxiety that their own structure might be replaced — O. trusted the existing architecture and pushed through.

Q4 Survival=100 — not a single line of code was rewritten. The existing structure worked. Which architecture to choose is simply a team decision. But O. proved definitively that the existing structure had value too. That's what Survival=100 as starlight means.

FE K.M. — Guardian of the user experience:

Period	Impact	Prod	Quality	Survival	Design	Lines	Role	Style
2025-Q3	47.8	78	30	79	13	+49k/-21k	Producer	Balanced
2025-Q4	35.9	31	58	90	0	+19k/-8k	Producer	Balanced

K.M. owned the domain most directly tied to user experience and brought it to completion.

The key metric is Survival — 79 rising to 90. High Survival means the code they wrote wasn't rewritten. It survived. Meaning they got the design right the first time.

In Q4, Design drops to 0 and Production falls. This isn't decline — it's a shift from building new structure to polishing and perfecting the existing design for the end user. And the polish was right — users have been sending overwhelmingly positive feedback.

Not generating high gravity, but an engineer who can move like this is the one actually determining the product's value. This is the dark matter of Chapter 10, in the flesh.

FE H. — The struggle of knowledge transfer:

Period	Impact	Prod	Quality	Surv	Robust	Dormant	Design	Lines	Role	Style	State
2025-Q2	70.4	100	80	44	71	31	100	+75k/-133k	Anchor	Builder	Active
2025-Q3	46.5	100	96	11	30	3	64	+78k/-75k	Anchor	Mass	Active
2025-Q4	30.4	44	94	16	28	10	10	+25k/-13k	Anchor	Balanced	Active

H. is the engineer who dove into the entirely new FE repository that R.M. built from scratch for the new project, working to absorb its knowledge and patterns.

In Q2, Design=100, Style=Builder — a star that creates structure. But from Q3 onward, Design drops from 64 to 10, and Style shifts from Builder → Mass → Balanced.

This isn't decline. It's the trace of building structure that didn't take root — and the struggle that followed. Robust Survival tells the story — 71→30→28. The structure H. poured design into was being rewritten by R.M.'s new infrastructure. Code that embodied architectural intent didn't survive.

But H. is fundamentally an emergent Architect — someone who creates structure from zero. And now, inside the new repository R.M. built, H. is absorbing feedback through code reviews, calibrating design sensibility, and evolving into a succession Architect.

Meanwhile, Dormant drops from 31 → 3 → 10. Even in low change-pressure areas, survival rates fell — the new infrastructure's ripple effects reached the entire existing structure. Watching your own architecture get rewritten by another engineer. The numbers capture that struggle.

And yet Quality — 80 → 96 → 94. On a high-quality, high-gravity field, continuing to build new code even while being rewritten.

Q2 Lines = +75k/-133k — deletions far exceed additions. Evidence of restructuring and cleaning up existing architecture. From Q3 onward, +78k/-75k and +25k/-13k stabilize, showing continued forward momentum even while being rewritten.

At the same time, H. appears in the BE domain in Growing state (Quality 94-97). Handing off FE knowledge while stepping into backend territory themselves.

When Impact drops from 70.4 to 30.4, do you see "declining performance"? Or do you see "transmitting structure for the team's future"? Without the telescope, it looks like the former. With the telescope — the high Quality, the Robust Survival crash, and the Style transitions tell the truth.

Why I want to remain an Architect/Builder

A brief aside about myself.

My signals consistently show Architect / Builder. Why do I refuse to let go of Builder?

Backend design — Clean Architecture, DDD layering — has established patterns. But the real art is in modeling. The subtle nuances of a domain, the gradations, where to draw boundaries. This is impossible without being a Builder. Classical Architects who define structure without writing code are valuable. Distributing well-designed starting points across the codebase is real, important work.

But I want to keep modeling on top of structure, fighting the unknown, producing high gravity with my own hands. That's why I write code.

FE's R.M. is the same way. Architecture, implementation, UI — all driven through by a single person. An Architect/Builder. R.M. and I exist in different universes (BE/FE), but we share the same nature: modeling on top of structure, creating gravity with our own hands.

This is precisely why H.'s "succession Architect" carries different weight. A succession Architect in an Architect/Builder environment is fundamentally different from one in a classical Architect environment. They're not just inheriting structural scaffolding — they're absorbing the depth of modeling, the gradations of design judgment, the density of a high-gravity field. What they inherit is denser.

And then there are BE's R.S. and P. — two engineers serving as Anchors within this Architect/Builder high-gravity field. When I ran the team data through AI for deeper insights, it came back with: "A two-Anchor formation is exceptionally rare. Typically, an Architect's gravitational field pulls other members down to Producer level." An Architect/Builder creates structure, and two Anchors support and stabilize it — this formation holding together is one of the reasons we survived the crucible.

And I look forward to watching O. — an emergent Architect — trace the trajectory ahead. If we keep clashing minds and building good things together, we'll reach gravitational bands none of us have seen yet.

machuz's long-term timeline tells another story:

Period	Impact	Lines	Role	Style
2024-Q3	59.9	+43k/-13k	Anchor	Builder
2024-Q4	68.3	+42k/-19k	Anchor	Builder
2025-Q1	76.4	+53k/-20k	Anchor	Builder
2025-Q2	83.1	+17k/-11k	Architect	Builder
2025-Q3	93.2	+113k/-48k	Architect	Builder
2025-Q4	87.7	+153k/-208k	Architect	Builder
2026-Q1	92.4	+140k/-33k	Architect	Builder

The evolution from Anchor to Architect is visible. The Architect Reproducibility from Chapter 8 — engineers who create gravity regardless of which universe they enter — is inscribed in the timeline.

This is the starlight the telescope revealed. Behind the numbers, you can see 3.5 months of battle. Behind the Quality crash, days of debugging. Behind Breadth=100, cross-repository design work. Behind "Rescue," the moment a backend engineer leapt into frontend.

Commit light doesn't lie. And a team's starlight can be told in numbers, not opinions.

The Massive Dark Matter — PO, PdM & QA

The telescope observes commit light. But this project had massive gravitational sources that never appeared in a single commit.

PO D.H. — came from sales and was suddenly assigned to the development organization last year. And yet, a deep respect for craftsmanship. Rather than throwing customer insights over the wall as requirements, D.H. sat with the development team and refined them together. That approach built trust with the team — and it was on that foundation that D.H. entered this project. Synthesizing perspectives from sales, customer success, and strategic business units, D.H. powered through a staggering volume of planning. Creating screen mockups by hand with cut-and-paste, coming at us with full force to synchronize minds.

PdM S.T. — the soul of this development organization. Pouring passion for the business into the team, relentlessly. Together with D.H., S.T. plowed through massive planning, coordinated with other organizations, navigated scope adjustments on razor-thin margins, and prepared backup plans so we'd never hit a dead end. And when the very last moment came — when everything hung in the balance — S.T. said "Let's keep going!!" and floored the accelerator with us.

R.M. said it half-jokingly over drinks one night: "I wanna make S.T. happy, man…!" It could have sounded like bar talk. But then you look at what followed — commits=1,398, Design=100, Survival=100 — and you realize it was dead serious. I witnessed the moment when love for a product was converted into commits.

QA T.Y. — yet another massive dark matter. Together with S.T., T.Y. powered through an enormous volume of QA. In the final week before release, there was a phase of crushing hundreds of bugs — and T.Y. worked through them steadily, methodically, until we reached release day with zero obvious bugs in normal user flows.

QA never appears in commits. But without QA, an engineer's commits remain "code that might work." Only after passing QA verification does a commit become "code that works." QA is the entity that converts commit light into starlight — light that actually reaches users. Dark matter invisible to the telescope, yet determining the product's quality.

EIS can only observe commit light. But there was dark matter that provided the fuel generating that light — vision, planning, organizational coordination, passion, and the last line of defense for quality. Massive dark matter that built a culture of quality. Knowing the telescope's limits is also the observer's duty.

The Telescope as Negotiation

This is where EIS becomes meaningful.

Observe the team's starlight — the track record preserved in commits — through the telescope, and turn it into numbers. Then "our team is strong" stops being subjective.

If you can prove the team's capability, then even when aligning with business direction is hard, you can move as dark matter with conviction and purpose.

As I wrote in Chapter 10, dark matter doesn't appear in commits. Design discussions, spec negotiations, technical persuasion — none of these become starlight.

But if the telescope accurately captures the team's starlight, dark matter starts to believe in the existence and value of the stars.

Just as starlight cannot see dark matter, dark matter could not see us either.

The telescope bridges that gap. "A team that emits this kind of starlight is working at the same density in the invisible places too" — that becomes a credible argument.

When EIS functions as negotiation material for building better things — that's the ultimate reward for its creator.

What Was Git Archaeology?

Over 13 chapters, git archaeology demonstrated the following:

Engineering impact can be quantified from commits alone (Ch. 1)
Team structural health can be derived from individual signals (Ch. 2)
Engineers have Role, Style, and State, and they evolve (Ch. 3-6)
Codebases are universes that follow physical laws (Ch. 7-12)
Measurement changes the universe (this chapter)

Git archaeology is the astronomy of code universes.

Just by looking through the telescope, the laws of the universe become visible.

Series

GitHub: eis — 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 12: Collapse | Chapter 14: Civilization →

Git Archaeology #12 — Collapse: Good Architects and Black Hole Engineers

machuz — Sat, 14 Mar 2026 21:28:01 +0000

The universe has another property. Collapse.

Previously

In Chapter 11, I wrote about Entropy — the universe always tends toward disorder.

This chapter is about another property of gravity.

Collapse.

Stars Are Not Forever

The universe has another property.

Collapse.

Stars are not forever. Galaxies are not forever.

When gravity breaks down, the structure of the universe changes in an instant.

The same phenomenon occurs in codebases.

When an Architect Leaves

Architects create universes.

They define design, create abstractions, organize dependencies, and build gravitational centers.

But here's the critical point.

A truly great Architect designs for "the universe after they're gone."

In a universe built by a good Architect, order is maintained even after they leave.

Because the structure remains.

The gravitational field of the design persists in the universe.

Black Hole Engineer

But not all strong gravity is good gravity.

The universe has black holes. Black holes have extremely strong gravity. But their gravity doesn't create structure — it swallows everything.

The same type of engineer exists in code universes.

Black Hole Engineer. This label describes a structural pattern observed in the codebase, not a character judgment of the person.

Their characteristics:

High technical skill. High output. Strong influence.

But — they don't create structure.

Instead — dependency concentrates.

A Black Hole Universe

Around a Black Hole Engineer, this happens:

Massive services. Massive utilities. Massive modules.

Work concentrates, dependencies concentrate, code concentrates.

The result — the center of the universe becomes one engineer.

A good Architect distributes gravity. Leaves structure. Gives the universe order.

A Black Hole Engineer concentrates gravity. Becomes the center of the universe themselves.

Collapse

The problem is when that engineer leaves.

When the black hole disappears, the center of the universe disappears.

What happens then?

Design decisions stop. Dependencies break. Nobody can touch the code.

The code universe collapses in an instant.

Good Gravity

A good Architect is different from a black hole.

They don't concentrate gravity. They distribute structure.

They share abstractions, clarify boundaries, and leave order in the universe.

So — even after they leave, the universe doesn't collapse.

This is seasoned, good gravity.

Remember Chapter 4's "laying souls to rest." A good Architect can be laid to rest. Their code lives on after departure. Survival 100 is proof that the structure remains.

A Black Hole Engineer cannot be laid to rest.

Because the code universe collapses the moment they leave.

Using EIS to Prevent Collapse

1. Monitor Bus Factor

Teams where eis analyze --team shows a Bus Factor near 1 are at risk of Black Hole collapse.

❯ eis analyze --team --recursive ~/workspace

Bus Factor = 1 means "if one person leaves, it collapses." This is the clearest sign of a Black Hole.

2. Detect Indispensability Concentration

Use --per-repo to examine individual signal distributions.

❯ eis analyze --recursive --per-repo ~/workspace

One person with extremely high Indispensability while everyone else is extremely low — this distribution is the signature of a Black Hole.

3. Watch for "One Person Stays Architect Forever" in Timelines

❯ eis timeline --author engineer-x --periods 0 ~/workspace

A good Architect's timeline shows an Architect → Producer transition (like O. in Chapter 5). Once the structure is built, they produce on top of it.

A Black Hole Engineer's timeline shows permanent Architect. They never release the structure. They keep concentrating gravity.

4. Judge Gravity Quality Through Surrounding Signals

Use the gravitational lensing effect from Chapter 8.

Around a good Architect:

Teammates' Design signals gradually rise (they learn the structure and start contributing)
New joiners ramp up quickly (the structure is clear and understandable)

Around a Black Hole Engineer:

Teammates' Design signals stay low (they can't touch — or don't dare touch — the structure)
New joiners ramp up slowly (you have to ask one person to understand anything)

The quality of gravity is reflected in the surrounding signals.

Preventing Collapse Is a Leader's Job

EIS can detect collapse risk. But detection alone doesn't prevent collapse.

Preventing collapse is a leader's job.

Specifically:

When you find Bus Factor = 1, deliberately expand pair work and code review scope
When you find Indispensability concentration, create time for that engineer to teach
When you find a permanent Architect pattern, build mechanisms to distribute design decisions

EIS shows you the universe's structure. How to reshape that structure is a human decision.

Regeneration After Collapse — Engineers Who Can Replace a Black Hole

Collapse isn't necessarily the end.

Just as R.M. created a new universe in Chapter 5, there are engineers who can bring new gravity to a collapsed universe.

These engineers have specific traits:

Architect Reproducibility (Chapter 8). They can create structure in any universe
They can read existing gravitational fields. They understand collapsed structures and grasp what was lost
They choose designs that distribute gravity. They don't repeat the Black Hole mistake

In timelines, the pattern looks like this:

When such an engineer joins a post-collapse team:

Team classification recovers from Unstructured → Guardian → Balanced
Bus Factor rises from 1 to 2, then 3
Multiple members' Design signals start rising simultaneously

Only an Architect who distributes structure can turn collapse into regeneration.

What's needed to replace a Black Hole isn't the same strength of gravity. It's a different quality of gravity.

Stars are not forever. That's why structure matters.

In the universe, when a star dies, the elements it created remain. Iron, oxygen, carbon — all forged in the star's nuclear fusion.

A good Architect is the same. What remains after they leave isn't code — it's structure.

What a Black Hole Engineer leaves behind is — void.

Stars are not forever. That's why structure matters.

Series

GitHub: eis — 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 11: Entropy | Chapter 13: Cosmology of Code →

Git Archaeology #11 — Entropy: The Universe Always Tends Toward Disorder

machuz — Sat, 14 Mar 2026 21:26:07 +0000

Entropy always increases. Engineers fight it.

Previously

In Chapter 10, I wrote about Dark Matter — work that doesn't appear in commits, invisible gravity.

This time, I write about another law of the universe.

The Second Law of Thermodynamics. The increase of entropy.

Entropy

Physics has a concept called entropy.

Put simply — order, left alone, always breaks down.

Drop a single drop of ink into a glass of water. The ink diffuses and mixes uniformly. But the reverse never happens. Ink never spontaneously separates from the mixed water.

This is the increase of entropy.

The universe always tends toward disorder. Maintaining order requires energy.

The Entropy of Code

Codebases have entropy too.

Left alone, code always rots.

At first, the design was beautiful. Layers were clear, responsibilities separated, naming conventions unified.

Six months later —

"It's urgent" — a shortcut cuts through layers
"Just this one place" — a method ignores the naming convention
"It works for now" — code goes in without tests

This is the entropy increase of code.

Each one is small. But accumulated, the structure crumbles.

Entropy and EIS

EIS's five observation axes are deeply connected to entropy.

Production — An Act That Increases Entropy

Writing new code increases entropy.

More code means more complexity. More dependencies. More to understand.

Production is necessary. But Production alone drives the universe toward chaos.

Quality — An Act That Resists Entropy

Writing tests. Making review comments. Fixing bugs.

These are acts of resisting entropy.

Engineers with strong Quality signals are guardians of the universe's order.

Survival — Proof of Victory Over Entropy

Code has survived for a long time. Meaning it endured the pressure of entropy.

Survival 100 is proof that "this code was not eroded by disorder for six months."

Design — The Greatest Weapon Against Entropy

Design is the most powerful weapon against entropy.

Good design limits the blast radius of changes. Module boundaries are walls that block the propagation of entropy.

Architects with strong Design signals are people who build entropy barriers.

Breadth — The Monitoring Range of Entropy

Engineers who touch a wide range can detect signs of entropy early.

"This area is starting to rot" — engineers with high Breadth can sense the health of the entire universe.

The Battle Against Entropy

Software development is, at its core, a battle against entropy.

Every new feature increases entropy. Refactoring is the act of reducing entropy. Tests are sensors that detect entropy increase.

Watch a team's signal trends and you see the results of the battle against entropy.

Quality signals declining → entropy is winning
Survival declining → past order is crumbling
Design signals rising → barriers are being reinforced

EIS timelines are the record of a battle against entropy.

Why Refactoring Is Necessary

"Don't touch working code."

This is a common engineering maxim.

But physics teaches us something different.

Left alone, order always breaks down.

If you don't touch working code, as the surrounding code changes, order degrades relatively.

Refactoring is the act of locally reducing entropy.

As I wrote in Chapter 10, small refactors look like "dark matter." They don't stand out in commit logs.

But they're holding back the collapse of the universe.

Entropy Cannot Be Avoided

Finally, one harsh truth.

The increase of entropy cannot be avoided.

No matter how beautiful the design, no matter how excellent the team, entropy will inevitably increase over time.

Perfect order doesn't exist. A perfect codebase doesn't exist.

What exists is — only the will to keep fighting entropy.

A good engineering team is one that keeps slowing the rate of entropy increase.

EIS tells you where you stand in that battle.

Series

GitHub: eis — 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 10: Dark Matter | Chapter 12: Collapse →

Git Archaeology #10 — Dark Matter: The Invisible Gravity

machuz — Sat, 14 Mar 2026 21:26:06 +0000

Most of the universe's mass cannot be observed. The same is true in code universes.

Previously

In Chapter 9, I wrote about Origin — the Big Bang and the first commit of code universes.

This time, I write about another force that exists in the universe.

An invisible force.

Dark Matter

Most of the universe's mass is said to be dark matter.

Yet it cannot be observed.

Telescopes can't see it. There's no means of direct detection.

Still, we're certain dark matter exists. Because — it manifests only as gravity, but gravity is undeniably there.

When you calculate a galaxy's rotation speed, visible matter alone can't explain it. Invisible mass is holding the galaxy together.

Dark Matter in Code Universes

Code universes have dark matter too.

It's the work that doesn't appear in commits.

Code review. Design discussions. Pair programming. Dependency cleanup. Small refactors. Documentation fixes.

These are small as commits — or don't even become commits at all.

Yet they support the stability of the universe.

Anchors Are Dark Matter

Remember the Anchor role defined in Chapter 3.

Anchors don't stand out. Neither their Production nor Design signals are exceptional.

But without them, the universe would quickly crumble.

Anchors are the dark matter of code universes.

Just as galaxies can't rotate without dark matter, teams can't stay stable without Anchors.

EIS can detect Anchors. But what EIS shows is dark matter's "gravitational effect" — not dark matter itself. The real work of an Anchor lies in the parts that don't appear in code.

Examples of Invisible Work

Code Review

Reviews don't produce commits.

Yet a codebase without reviews loses its structure.

Review is observation. Just like the Observer Effect in physics, observed code always changes.

It might be deleted. It might be improved. New dependencies might emerge.

Observation changes the universe.

Design Discussion

Thirty minutes in front of a whiteboard, and the design is decided.

Those thirty minutes aren't recorded in commits. But they determine the structure of thousands of lines of code that follow.

Invisible forces determine visible structure.

Small Refactors

A 3-line rename. A 5-line method extraction.

In the commit log, they look like "noise."

But this is the act of fighting the universe's entropy. The accumulation of small refactors prevents structural decay.

The Limits of EIS

Here's something I must be honest about.

EIS cannot see dark matter.

EIS is a commit-based tool. It can't measure work that doesn't appear in commits.

The quality of reviews. The depth of design discussions. The effect of mentoring. A team's psychological safety.

These are all dark matter.

What EIS shows us is only the "visible part" of the universe — stars and galaxies.

But knowing that dark matter exists lets you interpret EIS numbers correctly.

An Anchor's impact looks low because most of their work is dark matter.

Judging "this engineer has low productivity" by looking only at numbers is the same mistake as calculating a galaxy's mass from visible matter alone.

Being Aware of Dark Matter

When using EIS, always be aware of dark matter's existence.

Dark matter doesn't only exist within engineers. It exists in every layer of the organization and business.

Engineer Dark Matter

An engineer with a low impact might actually be supporting the team's stability
Design decisions that don't appear in commits might be the core of the structure
The quality of reviews might be lifting the entire team's Quality signals

Planning Dark Matter

A planner pouring their soul into the business, producing precise specifications — this doesn't appear in a single line of commits.

But without that precision, code gets rewritten over and over. Survival drops. Quality crumbles.

A team's high Robust signal isn't just engineering skill. It's because the specs are stable. And the one creating that stability is a planner — dark matter fighting invisible battles with the business.

Cultural Dark Matter

In organizations without a tech-company culture, business decisions rain down that ignore the state of the code.

Sudden pivots. Schedules that don't account for technical constraints. Pressure to "just make it work."

The result: gravitational fields get torn apart. Architects disappear. If engineers are still moving forward despite this — those engineers are dark matter itself, holding together a universe on the verge of collapse.

Conversely, in organizations with good culture — where failure is tolerated, where time for Debt Cleanup is secured, where design discussions are valued — Growing engineers develop, Cleaners function, and Architects are reproduced.

Culture is the largest dark matter of all. It never appears in commits, but it determines the entire structure of the universe.

Hiring Dark Matter

Having strong engineers on the team is no accident.

Someone identified them, persuaded them, built the right environment. That work is never recorded in commits. But it determines the team's initial conditions — the Big Bang from Chapter 9.

The one who sets the universe's initial conditions is also dark matter.

When you look at EIS numbers, never forget that layers upon layers of dark matter exist behind them.

Trying to see the invisible. That too is an act of observing the universe.

Series

GitHub: eis — 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 9: Origin | Chapter 11: Entropy →

Git Archaeology #9 — Origin: The Big Bang of Code Universes

machuz — Sat, 14 Mar 2026 20:43:13 +0000

Every universe has an origin. In code universes, it's the first commit.

Previously

In Chapter 8, I explored Engineering Relativity — how the same engineer gets different scores in different codebases.

From here, we go deeper into the philosophy of git archaeology.

Starting from the very beginning.

The Big Bang

Every universe has an origin.

In our universe, it's called the Big Bang. Time and space began there.

Code universes have the same moment.

It's the first commit.

The Primordial Universe

The first commit has almost no design.

No structure. Just the impulse: "I want to make something work."

It resembles the primordial universe.

No galaxies yet. No stars yet. Just energy and particles swirling together.

Early codebases are the same.

if statements line up. Functions line up. Small utilities line up.

Architecture doesn't exist yet.

But from that small commit, a universe begins.

Every structure that follows is built on top of that first commit.

Initial Conditions

In cosmology, the Big Bang's initial conditions determine the universe's subsequent structure.

Early density fluctuations eventually become galaxy clusters.

The same thing happens in code universes.

The first directory structure. The first module split. The first naming convention.

These initial conditions influence every design decision that follows.

A project that started with src/ and lib/ separated will carry that split for years. A project that started as a monolith will be dragged by the monolith's gravity for years.

The gravity of initial conditions is strong.

The Birth of Constellations

Looking up at the sky, stars appear to be scattered randomly.

But humans find meaning in them.

Orion. Cassiopeia. The Big Dipper.

These aren't physical structures. They're patterns that humans found.

The same thing happens in codebases.

What starts as a mere collection of files eventually gets assigned meaning by humans.

Modules. Services. Packages. Layers.

These are constellations.

Not the stars themselves. Maps that humans created to understand the universe.

A great Architect doesn't create stars — they create constellations.

They discover structure, organize structure, and share structure.

That is architecture.

Git Archaeology Observes the Big Bang

Run git log --reverse.

You'll see the first commit.

It has a date. An author. A message.

That is the record of this universe's Big Bang.

Git archaeology is also the study of observing a universe's history from its Big Bang.

The codebase in front of you right now is the present state of a continuous universe that began with that first commit.

Initial Conditions and EIS

EIS reflects the influence of these initial conditions.

In mature codebases, structures created early on persist as Survival 100. The first Architect's commits remain etched in blame for years.

The "laying souls to rest" from Chapter 4 often targets this initial Architect. The gravity of the person who created the Big Bang lasts the longest in the universe.

Conversely, in codebases with weak initial conditions — projects that started without structure — everyone's Design axis is low. Because the gravitational center never existed from the start.

The universe's present is determined by its Big Bang.

It All Started Here

The first commit is small.

Maybe just a few lines.

But from there, a universe begins.

Gravity is born, structure forms, constellations are drawn, Architects appear, teams evolve.

It all started here.

Series

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 8: Engineering Relativity | Chapter 10: Dark Matter →