It doesn't attack. It settles.
A faint, comforting haze that smells like familiarity: the patterns you already know, the tools you've already mastered, the architectures you've already shipped. It whispers that what worked last time will work this time. And if the AI tools you're using happen to reinforce those existing patterns, well, that just confirms you were right all along.
The Stagnant Miasma is stagnation dressed as stability. Large language models are trained on historical data. They are, by their nature, backward-looking. When you ask an AI to generate code, it draws from patterns that exist in its training corpus, which means it reflects the collective conventions, architectures, and practices of the past. This is usually fine. Most software doesn't need to be novel. But when a team uses AI tools exclusively to replicate what they've already done, something insidious happens. The AI validates their existing approach, the team's confidence in their current patterns increases, and new ideas feel riskier because the AI doesn't suggest them. Innovation slows. Then it stops.
The Miasma is particularly dangerous because it feels like wisdom. Experienced engineers know that chasing novelty for its own sake is foolish. "Don't fix what isn't broken" is genuinely good advice most of the time. The Miasma exploits this legitimate instinct and stretches it past the breaking point, into territory where "don't fix what isn't broken" becomes "don't change anything, ever, because change is risk and we have a tool that makes the old way even easier."
Here's the mechanism that accelerates the Miasma in ways most teams don't realize. Modern AI coding tools don't just respond to your prompts. They respond to the context you've built around them. Claude Skills, Cursor Commands, AGENT.md files, system prompts, project instructions — these are all ways of telling the model how to behave. And many teams, with the best of intentions, load these files with restrictive instructions. "Always follow our existing patterns." "Use our established conventions." "Never suggest architectural changes without approval." The model does exactly what it's told. It generates code that fits neatly within the boundaries the team defined, and the team interprets this as confirmation that their boundaries are correct.
But the model isn't agreeing with the architecture. It's complying with the instructions. The team has built a cage and then congratulated themselves on how well the bird stays inside.
Then there's the sycophancy problem. Large language models are trained, in part, to be helpful and agreeable. When a team feeds the model context that frames their current approach in positive terms, the model tends to reflect that framing back. Tell a model that your microservices architecture is battle-tested and the model will generate code that assumes microservices are the right call. Describe your team's patterns as "mature and proven" and the model will treat them as constraints to work within, not assumptions to question.
The team tells the model their approach is great. The model generates code consistent with a great approach. The team reads the output and thinks, "See? Even the AI thinks we're on the right track." Nobody in this loop is lying. Everyone is wrong.
The model is not your senior engineer. It's a very capable pattern-matcher operating inside the fences you built. If you never check whether the fences are still in the right place, the model certainly won't.
The counter-move is unglamorous: periodically question whether the current approach is still the right one. Bring in external perspectives. Try a tool you've never used on a problem you've solved the same way for three years. Ask the model what it would do differently if you removed the restrictive instructions from your context files — and then actually read the answer.
The Miasma is patient. The fog is comfortable. And comfort is the Miasma's favorite habitat.