machu

Posted on Mar 14

Git Archaeology #13 — Cosmology of Code

#opensource #productivity #git #career

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 scores (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 scores start to become conscious of their commit patterns.

Leaders who see team scores 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 not an evaluation tool. It's an observation instrument — the Git Telescope.

Astronomy doesn't score 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 scoring 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	Total	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 scores 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 scores 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, scores across all FE repositories:

Period	Total	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

Total 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	Total	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, Total 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 Total 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	Total	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.

When you see an engineer hovering around Total 40, do you see "mid-tier"? Or do you see "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	Total	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 scores. 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 score can show.

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

Period	Total	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	Total	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.

An engineer whose scores look low may actually be determining the product's value. This is the dark matter of Chapter 10, in the flesh.

FE H. — The struggle of knowledge transfer:

Period	Total	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 Total 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 scores 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	Total	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., ignited by S.T.'s passion, was building UI while saying "I want to make S.T. happy…!" 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 scores (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.

In Closing

To everyone who read this series, I want to convey one thing.

Your commits remain in the universe.

Even a small commit. Even a review comment. Even a 3-line refactor.

It's released into the universe as starlight, and someday someone will observe it.

The code you wrote continues to exist in the universe after you leave.

Whether it carries structure or leaves a void —

That is for you to decide.

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 12: Collapse | Final Chapter

DEV Community