I've been at the same company for twelve years. That's long enough to watch a codebase grow from something you could hold in your head to something nobody fully understands. Long enough to feel the accumulation — not as an abstract concept, but as a texture. You open a file and it resists you. Not because it's broken. Because it's layered. Every decision was reasonable when it was made. Together they form something that takes longer to read than it took to write.
Philip K. Dick had a word for this: kipple.
In Do Androids Dream of Electric Sheep?, kipple is the entropy of objects. Junk mail, empty matchbooks, gum wrappers — the stuff that accumulates when nobody's paying attention. "Kipple drives out nonkipple," one character explains. The universe trends toward it. You can fight it locally, but you can't win globally.
I've been thinking about kipple because of what's coming. Not hypothetically — I can see it arriving. OpenAI's Codex runs each task in its own sandbox. Claude Code spawns sub-agents in parallel. The trajectory is obvious: more agents, working simultaneously, touching the same codebases. And the question I keep circling is whether the coordination patterns we built for thousands of humans — at Google, at Amazon, at Meta — transfer to thousands of agents. Or whether agents produce a different kind of mess entirely.
#The Feeling That Motivates Cleanup
Here's the thing I keep coming back to: the reason large orgs stay even partially healthy is that humans feel the weight of complexity.
A messy codebase is annoying. An unclear ownership boundary is frustrating. A duplicated utility function that does almost-but-not-quite the same thing as another one creates a little spike of irritation every time you encounter it. Nobody schedules a fix-it week because a metric told them to. They schedule it because engineers are complaining. The emotional response — the friction, the aesthetic discomfort — is what motivates cleanup.
Agents don't complain.
They don't get annoyed by inconsistent naming. They don't feel the weight of a file that's been touched by thirty people over five years. Every session starts fresh, with no accumulated irritation. An agent will generate a perfectly correct solution that happens to duplicate existing logic, because it doesn't feel the duplication the way you do when you've been in the codebase long enough to know better.
That's what worries me about agents at scale. Not that they'll write bad code — they're actually quite good. But that they'll write correct code that makes the whole system slightly harder to understand, one reasonable decision at a time, without anyone noticing because nobody feels it. Kipple reproducing itself. The universe trending.
#What Carries Over
Some of the patterns I've watched work for large teams do seem to carry over:
Code review as a gate. Meta requires review on every diff, regardless of seniority. This pattern survives — maybe gets more important. GitHub's stacked PRs are explicitly designed for agents to produce and humans to review. The gate still works. The volume going through it is about to change dramatically.
Ownership boundaries. Amazon's two-pizza teams own their services end-to-end: you build it, you run it. When agents write code, the ownership question doesn't vanish — it intensifies. If an agent breaks something at 3am, it can't be oncall. A human still holds the pager.
Progressive rollout. You don't let a thousand engineers ship to 100% simultaneously. Same with agents — canary deploys, percentage rollouts, kill switches. If anything, this matters more when changes arrive faster than humans can review them.
These are the structural patterns. Boundaries, gates, rollout discipline. They transfer because they don't depend on who's writing the code. They depend on what happens after the code is written.
#What Doesn't
The patterns that break are the ones that depend on something more human:
Knowing who to ask. At my company, when something is weird, I know who built it. I know who remembers why the retry logic has that strange timeout. That knowledge lives in my head, transmitted through years of hallway conversations and code reviews and "hey, do you remember when we changed this?" Agents have context windows. There's no hallway. Everything an agent knows has to be written down somewhere. The tribal knowledge problem becomes a documentation problem — which is a worse problem, because documentation is the thing we're worst at.
Taste. In a large org, junior engineers escalate to seniors who escalate to staff who escalate to principals. Each level is a filter — not just "does this work?" but "is this the right approach? Does this belong here? Will this make the next person's life easier?" With agents, what's the escalation ladder? A more expensive model? A model with more context? A human reviewing every structural decision? We don't have a hierarchy of agent judgment. We have humans at the top and agents that are all roughly the same level — capable but not wise, fast but not experienced.
Culture. This is the one that haunts me. Amazon has leadership principles. Google has "Googleyness." Netflix has the culture deck. These aren't rules — they're vibes that shape thousands of micro-decisions in the gaps between explicit policies. When I face an ambiguous choice at work, culture tells me which way to lean. Agents have system prompts, which are rules. You can encode "move fast" as a constraint. But culture is what happens between the constraints — the emergent behavior of a group that shares values. Can a fleet of agents have culture? Or is culture specifically the thing that requires humans feeling something together?
I don't have an answer for that one. I just notice it's missing.
#Both Faster and Slower
So do agents produce kipple faster or slower than humans?
Both. Obviously both.
They generate code at 10x speed, so they generate reasonable-but-redundant code at 10x speed. They solve each problem in isolation, without the holistic discomfort that makes a human say "wait, this doesn't belong here." The kipple piles up faster because nobody feels it.
But they can also clean at 10x speed. "Find dead code and remove it" — a task humans never prioritize because it's tedious — is trivial for an agent. "Migrate all uses of the old API to the new one" — a task that would take my team a quarter — is a Tuesday afternoon. The cleanup capacity is there. The question is whether anyone points it at the mess.
The companies I've watched stay healthiest are the ones that invest in platform teams and developer experience — that treat fighting entropy as real work, not a side project. The agent-scale equivalent would be cleanup agents, consistency agents, deprecation agents. Agents whose entire job is fighting kipple. Not as a nice-to-have. As a system constraint.
Steve Yegge's Gas City — his SDK for deploying teams of collaborating agents — takes an interesting approach. The stack uses Dolt, a git-versioned database, to track every piece of agent work with full version history. Every task, every handoff, every state change is a commit. You can diff what an agent did. You can revert it. You can audit the full chain of decisions that led to a change.
That's not anti-kipple exactly — it doesn't prevent entropy. But it makes entropy visible. You can see what accumulated, when, and why. The kipple is still there. But it's in a versioned database instead of scattered across files that nobody remembers creating. Visibility is the first step. You can't clean what you can't see.
#The Quiet Accumulation
Dick was pessimistic about entropy. "No one can win against kipple," his character says, "except temporarily and maybe in one spot."
I think about that line when I look at the codebase I've lived in for twelve years. The history of it is a history of entropy fought and entropy winning — rewrites, migrations, the eternal "we should really clean this up" that never quite happens.
Humans produce kipple because we're lazy. Agents will produce it because they're not — because they solve each problem in isolation, without the accumulated context that makes a human say "actually, let me refactor this while I'm here." The emotional response that motivates cleanup doesn't exist in an agent. You have to build it into the system instead. Linters as aesthetic judgment. CI gates as taste. Entropy budgets as culture.
For the parts of large-org coordination that transfer — boundaries, gates, rollout — we have a playbook. For the parts that don't — judgment, culture, institutional memory, the feeling that something isn't right — we're building new while pretending we can retrofit.
Where have I heard that before.
Dick had other metaphors worth stealing. In Ubik*, objects don't just accumulate — they regress. Fresh coffee becomes stale instant. A modern car devolves into a 1929 LaSalle. Everything decays backward into its worst possible version. That's a different essay — about technical debt not as clutter but as temporal regression, your clean abstractions slowly becoming the legacy code they replaced. Kipple multiplies when you're not looking. Ubik entropy drains quality while you watch. Software does both.*