Why I Stopped Treating Complexity as a Bug

There’s a quiet failure mode spreading through modern engineering teams.

It doesn’t look like incompetence.

It looks like competence on autopilot.

PRs are clean.

Folders are neat.

Patterns are consistent.

And still — systems feel more fragile than they used to.

Not because they crash more often.

But because fewer people can explain why they work.

That gap — between what runs and what is owned — is the part “clean code” culture doesn’t know how to name.

The Pattern We Rarely Admit

Most developers don’t fail because they lack skill.

They fail because they repeat validated patterns long after the context has changed.

Frameworks stabilize.

Best practices harden.

Heuristics turn into reflexes.

And soon, entire teams move like hamsters on a wheel —

busy, correct, and directionless.

Every once in a while, someone notices that the wheel itself is the problem.

History is surprisingly consistent about this.

Two contrarian moves that changed the game

Most teams don’t get stuck because they lack talent.

They get stuck because they keep polishing the same heuristics long after the world has moved on.

The pattern is boringly consistent:

a rule becomes a guideline, a guideline becomes a reflex, and the reflex becomes a culture.

Every once in a while, someone does something rare:

they don’t optimize inside the frame — they question the frame itself.

Here are two examples I keep coming back to, because they’re not “clean code stories.”

They’re intent stories.

1) Redis: choosing a single thread to make behavior ownable

The default heuristic in performance engineering is almost automatic:

“If you need speed and scale, you need more threads.”

Redis became famous by refusing to treat that as axiomatic.

Redis operates with a mostly single-threaded request-serving model. Redis’s own latency documentation explains that a single process serves client requests sequentially via multiplexing — so only one request can be served at a given moment.

That design forces a kind of honesty:

If you block the main path, you block everything.

You can’t hide latency inside scheduling luck.

You can’t paper over coordination with “just add a lock.”

Redis didn’t “reduce complexity.”

It relocated complexity into an explicit constraint.

A constraint is a form of governance.

It tells every future contributor:

this is the execution model you’re allowed to assume.

2) WireGuard: treating “simplicity” as a security primitive

Security has its own entrenched heuristic:

“Real VPNs are inevitably complex.”

WireGuard succeeded by treating that assumption as a liability.

WireGuard’s design philosophy emphasizes a minimal attack surface and implementation patterns that are secure in practice (including minimal state and no dynamic allocations).

And it goes further than “small codebase” as an aesthetic preference.

In formal analysis, WireGuard aims to be silent in the face of unauthenticated packets (“stealthiness”), avoiding state changes based on unauthenticated data.

This is the inversion I find most relevant to software today:

WireGuard didn’t pursue simplicity as aesthetics.

It pursued simplicity as governance.

Less surface area means fewer places for intent to hide.

Fewer degrees of freedom means fewer “it looked right” decisions that nobody can later explain.

The silent cost of implicit assumptions

Here’s what Redis and WireGuard have in common:

they made the default path auditable.

Not through documentation.

Through constraint.

When the execution model is explicit, you can’t accidentally violate it.

When the attack surface is minimal, you can’t unknowingly expand it.

This matters in any complex system.

But it matters exponentially more when the person producing the code

didn’t design the constraint —

they inherited it from autocomplete.

Why this matters now (especially with AI-generated code)

AI didn’t just accelerate coding.

It changed what “empty” looks like.

We’re entering a world where:

code can look correct while hiding missing intent,

structure can be pristine while behavior is unowned,

style can be perfect while implementation is thin.

And we’re already seeing the verification gap.

Sonar’s recent “State of Code Developer Survey” and press release report a striking split: 96% don’t fully trust AI-generated code, yet only 48% always verify it before committing.

Multiple outlets summarized the same finding, pointing to a growing “verification gap” in day-to-day workflows.

This gap is increasingly described as verification debt — the accumulation of unverified output shipping faster than humans can understand it.

So the old “clean code” heuristics — naming, formatting, familiar patterns — start to fail us, because they were never designed to answer the real question.

Not:

“Is this complex?”

Not even:

“Is this correct?”

But:

“Is this complexity intentional — and who owns it?”

Consent: a missing primitive in code quality

Here’s the leap I’ve been thinking about.

In mature systems, complexity isn’t always a smell.

Sometimes complexity is a choice:

performance constraints,

security constraints,

domain invariants,

irreversible external effects.

The problem isn’t complexity.

The problem is complexity without consent.

By “consent,” I mean something very practical:

If we choose complexity, we should have to say why — inside the artifact.

A mini example (what “consent” looks like)

Imagine reviewing this pull request.

Before (clean-looking, but unowned):

After (more “complex,” but governable):

The second version is “more complex.”

More words. More constraints.

But now it’s governable.

Someone in 2027 can read it and know what they’re not allowed to simplify.

Making this testable (not just theoretical)

This is why I started building a tool that enforces this exact pattern.

Not as a linter that says “this is too complex.”

But as a consent tracker that asks:

“Is this exception documented?”

“Is the reason explicit?”

“Will the next person know what not to simplify?”

It’s called AI Slop Detector — not because it detects “bad code,”

but because it surfaces code that lacks accountable intent.

(If you’re curious: there’s also a VS Code extension so this shows up at the point of creation.)

The goal isn’t to block unusual code.

It’s to prevent the most dangerous outcome of AI-assisted engineering:

systems that look maintained, but are actually unowned.

A practical rule I now trust more than “clean code”

When reviewing modern codebases, I’ve started using a simple mental test:

If I removed the author’s name, could the code defend its own complexity?

Is the constraint explicit?

Is the trade-off documented?

Is the exception scoped and justified?

Would a future reviewer know what must not be simplified?

Redis and WireGuard pass this test at the design level.

That’s why they endure.

Their complexity is not accidental; it’s declared.

What you can do Monday morning

You don’t need new tools to start.

You need one new question in code review:

“If the author’s name was removed, could this code defend its own complexity?”

Ask it about:

performance hacks

security exceptions

domain-specific shortcuts

anything that breaks the “clean code” rules

If the answer is no — if the complexity is implicit, tribal, unowned —

then you’ve found the real debt.

Not the code that looks messy.

The code that looks fine but nobody can explain.

Because the goal isn’t to punish unusual patterns.

It’s to make sure that when we choose complexity, we do it deliberately — and we leave a record.

That’s not clean code culture.

That’s governance culture.

And in the age of AI-generated systems, it might be the only culture that scales.