The Dark Matter of Software - by john - ninety-nine fires

ninety-nine fires

SubscribeSign in

The Dark Matter of Software<br>May 28, 2026

Share

When we think about the universe we normally thing about things we see - stars, planets, galaxies. However, most of the matter in our universe is actually invisible. We call this dark matter, and while we can’t observe it directly, its existence can be inferred by the effect it has on everything else around it.<br>Software works the same way.<br>We tend to think of software as the sum of its components - the codebase, the schemas, apis, infrastructure, data. But those artifacts are only the visible layer, and often the most difficult or complex pieces of software to understand never make it into the code, schema, or database.<br>Every architecture path we explored and abandoned, schema decisions made to preserve flexibility, features intentionally left out, scaling concerns that never materialized, and customer requests that permanently altered direction.<br>We typically document what the system became but we rarely document what it refused to become. And two systems can look nearly identical from the outside while requiring completely different decisions based on the history behind them - and therefore may require very different approaches moving forward.<br>That hidden context is software’s dark matter .<br>This is one of the biggest missing pieces in how we talk and utilize AI for software development today.<br>Today, the models can ingest our code, read our schema, and summarize our tickets - but it usually cannot reveal the roads not taken. It doesn’t see the failed abstractions, the intentional constraints that matter, or what parts of the system are scars left behind by problems that no longer exist.<br>And as a result, what engineers are noticing - that others may not - is AI often feels incredibly capable locally or in greenfield environments and becomes disconnected and much less reliable globally or in mature systems.<br>Greenfield projects have less dark matter because they carry fewer historical constraints, invisible decisions, and have less accumulated context. Mature systems are different. Years of tradeoffs, migrations, and operational lessons become embedded into the software without ever being written down.<br>This isn’t really a criticism of AI as much as it is an observation about software itself. Software contains more history than implementation, and as the implementation continues to become cheaper, preserving the reasoning behind systems becomes more valuable.<br>It’s interesting to consider what software built around this idea would even look like. What changes when historical context stops being treated as external to the system and starts becoming part of the system itself. When the reasoning behind decisions and tradeoffs lives alongside the code instead of disappearing into old conversations and the memories of the people who built it.<br>Maybe systems become less static. Less like repositories of implementation and more like environments that retain the paths, constraints, and decisions that shaped them over time. Maybe understanding a system becomes less about reading what exists and more about understanding why it exists in the first place.<br>The next evolution of software may be less about generating code and more about making more of its dark matter visible.

Share

Discussion about this post<br>CommentsRestacks

Ready for more?

Subscribe

© 2026 jp · Privacy ∙ Terms ∙ Collection notice<br>Start your SubstackGet the app<br>Substack is the home for great culture

This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts