The rise of dark code and the death of architectural intent

As Staff Engineers and Principal Architects, most of us have spent years thinking about long-term system health. We are considerate of the company’s business objectives and strategy, accumulation of technical debt, and operational risk. For us it is not about whether code works today, but whether the engineer who inherits it in three years will be able to understand what it was trying to do and why. That's what makes a codebase maintainable rather than just functional.

AI coding assistants are eroding that. A lot of the current discourse focuses on speed and enabling developers to do more with less time. But, as additional tools are introduced into the mix, what we are losing is an understanding of developer intent. While we are technically moving faster, we are generating a new category of technical debt, but it doesn't look like technical debt. It looks like clean, well-structured, passing code, but with no human reasoning behind it.

The anatomy of dark code

Key takeaway: Automated code generation masks the loss of developer intent. Clean repositories are accumulating legacy at double the historical speed.

The local AI development loop feels productive on the surface. A developer opens their editor, highlights a block of code, and prompts the model: "Refactor this authentication handler to support multi-tenant token exchanges." The model returns a 200-line diff. The developer skims it, runs a local test, commits with a message like "refactor auth for multi-tenant," and pushes to the branch.

On paper, the task is complete. In practice, the repository just inherited a liability.

Version control recorded the what: the raw diff of the newly generated lines. It captured nothing about the why. The prompt, the context the model was working from, the logic paths it evaluated and discarded, the structural assumptions baked into the output, all of it evaporated when the editor session closed.

Picture that same authentication handler, six months later, failing at 2am because of an edge-case token configuration nobody anticipated. A senior engineer runs git blame. They don't find a design decision. Instead they find an artifact, driven by an agent choice. There's no commit message that explains the reasoning, no PR comment that captures the tradeoffs, no way to reconstruct what the model was optimizing for when it chose that particular structure. The context is gone because it was never written down anywhere that outlasted the session that produced it.

We've always accumulated technical debt. But, now we're accumulating it faster, and in a form that's harder to pay back, because of the absence of context.

The collapse of Git authorship

Key takeaway: When an engineer reviews and merges a diff they can't trace, they become accountable for decisions they didn't make.

Git was built on a foundational assumption: the name on a commit represents the mind that planned the change. That relationship has quietly broken down.

Developers using local AI tools have shifted from authors to editors of machine-generated text. That shift has consequences that aren't evenly distributed. The developer who prompted the model moves on. The reviewer is the one left holding the diff.

A Staff Engineer reviewing a complex multi-file pull request is now being asked to sign off on architectural choices (e.g., a specific database lock pattern, a particular approach to nested async calls) without knowing whether those choices were intentional decisions or the model's best guess given a context window the reviewer has never seen. The model isn't available for questions. The developer who ran the prompt may not fully understand why the output looks the way it does either.

Two things follow from this. The first is a review quality problem: under backlog pressure, the honest answer to "do you understand why this code is structured this way" is increasingly no, but the merge happens anyway. The second is an accountability problem that most teams haven't fully reckoned with yet: the person who clicks merge is operationally responsible for the consequences of code they didn't design and can't fully trace.

What traceability actually requires

Key takeaway: The fix isn't restricting AI use. It's capturing the context that AI execution currently discards.

The temptation is to treat this as a tooling problem with a tooling fix: better commit message discipline, mandatory PR templates, AI code review layers. Those things help at the margins. They don't solve the underlying issue.

The underlying issue is that AI reasoning happens in a place that produces no durable record. A model running inside a developer's local editor processes context, makes decisions, and generates output, and then the context is gone. What gets committed to version control is the output. Everything that led to it is gone.

The teams starting to work through this seriously are rethinking where in the process AI operates, not just how it operates. When the context an agent works from, the decisions it makes, and the human review of those decisions are all captured as part of the same record as the code change itself, you have something you can actually audit. Six months later, when something breaks, the reasoning is still there.

That's a different kind of infrastructure requirement than most teams are used to thinking about. But it's the right framing for the problem. We don't have a code quality problem. We have a context preservation problem. And solving it means treating the reasoning behind a code change as part of the engineering artifact, not a byproduct that gets discarded when the session ends.

This is the problem we're building Upsun Dispatch™ to solve: capturing the full chain of context, reasoning, and human sign-off as part of the engineering record itself, not something recreated after the fact.

• New here? Read the introduction to Upsun Dispatch
• Want to help build it? Apply to the founding design partner cohort

Frequently asked questions (FAQ)

What exactly is dark code?

This is code that compiles, passes review, and reaches production with no auditable record of why it was written the way it was. The architectural decisions are invisible to everyone except the model that made them, and that model may be long gone.

Why isn't a good commit message enough to avoid dark code?

A commit message captures what a human chose to summarize. It doesn't capture the prompts, the context, or the reasoning chain that led an AI to specific structural decisions. A developer writing "refactor auth for multi-tenant" is summarising their interpretation of the output, not documenting the process that produced it. Those are very different things.

Doesn't traceability slow developers down?

Only if you implement it badly. The goal isn't to make developers manually document every AI interaction. It's to capture that context automatically, at the point where AI is actually operating, without adding friction to the developer's workflow.

How does dark code relate to compliance?

Frameworks like ISO 27001 require you to prove why a change was made, who authorized it, and how it was verified. Code generated locally by an AI assistant, with no shared record of context or approval, is genuinely difficult to account for in an audit. That's a risk most teams haven't fully mapped yet.