Two Is One, One Is None
Why AI Teams Need Model Redundancy
Anyone who spent time in the military knows the phrase.
If something is mission-critical, you have a backup. If the backup is mission-critical, you have a third backup (or batteries, parts, ammo, whatever). You do not test your backup plan when shit breaks.
Workers are becoming more dependent on AI as a crutch for cognitive work and it’s making us dumber.
We’re outsourcing things like writing, coding, research, analysis, customer insights, copy, experiment review, data analysis, and internal tooling to our agents. Quality output now depends on a model answering well, quickly, and consistently.
It is a single point of failure and a really bad idea.
This Already Happened
On April 23, 2026, Anthropic published a postmortem on recent Claude Code quality issues.
The root cause was three reasonable product changes that went horribly wrong:
Default reasoning effort was lowered to reduce latency.
A caching bug caused Claude to lose prior reasoning in stale sessions.
A system prompt change intended to reduce verbosity hurt coding quality.
API users were fine, it was the CC folks that got burned while people with alternatives switched models and kept working. People without alternatives were SOL.
Product And Growth Teams Should Care
Engineering teams understand dependency risk. Product, Marketing, and Growth teams often underestimate it.
If your analyses, onboarding copy, PRD drafts, customer research synthesis, experiment readouts, SQL queries, and internal automations all depend on one model, then your team’s output is tied to that model’s behavior, which you don’t control.
Models change. They get stingy with compute. They get slower. They get “optimized.” They get new system prompts. They get enshittified.
The same skill or workflow starts producing different quality output, your review/verification burden goes up, your team loses trust, and nobody knows whether the problem is the model, the tool, or the person using it.
That is expensive.
Model Agnostic Beats Model Loyal
I use Cursor because it keeps model choice flexible to the work. The UI is a huge improvement over VS Code, but the biggest benefit is easy model changes for chats and subagents.
Different models are better at different things. I like Anthropic for planning, feedback, and everyday document work. I like Codex for code implementation and I use Gemini when a task benefits from Google’s index or long-context handling. I use different levels of all models at the same time to “red team” my work. The best question is not “which model is best?” It is “which model(s) work best for this task?”
Once you see the benefits, it becomes normal and you learn to test different models for the same task to understand the nuance between them.
When Anthropic has a bad week, move to GPT. When OpenAI has an outage, move to Claude.
The Litmus Test
If your primary AI vendor vanished tomorrow, how long before you or your team was productive again?
If the answer is days, you are locked in.
If nobody knows the second-best tool, you are locked in.
If your agents only work because of one model’s quirks, you are locked in.
If your internal process says “use Claude” or “use ChatGPT” instead of describing the job to be done, you are locked in.
What To Do This Week
Pick a workflow and run it through another model.
Use a PRD, an experiment analysis, a customer research synthesis, a bug investigation, or a Jupyter notebook. Compare the output. Note what is better, worse, or just different.
Then do a few things:
Keep your workspace (e.g. folder) platform agnostic - point CLAUDE.md to AGENTS.md, keep skills in the same spot.
Document where each model performs best
Test the fallback before you need it
These tools are good. I use them all day. But they are still tools, built by companies with priorities and incentives that don’t align with yours.
Do not put critical work on a foundation you cannot inspect, control, and replace quickly.
Two is one. One is none.
Plan accordingly.