Eight Months of Running Claude in Production. The Honest Audit.

We had a client launch in February that should have taken six weeks. We finished in three. The thing that changed wasn't a new framework or a hire. It was that the lead engineer started running Claude Code with a custom agent and three MCP servers wired into our Linear, our GitHub, and the client's staging Postgres. He shipped at roughly twice the rate of any project we ran in 2025. We've been quietly running variants of that setup on every project since.

This is not a love letter. We've broken Claude in production in ways that were embarrassing. We've also kept it doing things that nothing else we tried could match on cost or quality. Here's the audit, for anyone considering a serious bet on Claude in 2026.

What we actually use it for

Three buckets. They're not equal in size.

Internal engineering. Almost every senior engineer on our team runs Claude Code on at least one client project right now. Not as autocomplete. As a co-pilot that owns whole tasks: "read this Jira ticket, look at the last three commits in this folder, propose a plan, write the migration, run the tests, open a PR." The agent doesn't ship anything to production without review. But the per-engineer throughput is up roughly 60% on the projects where we adopted it, measured by Linear ticket velocity over a comparable feature set.

The thing that shifted in 2026 is not the model. It's that the scaffolding around the model finally got good. Tool use that actually works. File editing that doesn't hallucinate paths. A way to plan, then act, then check, then revise. That's most of why the velocity changed.

Client-facing assistants. This is the bucket we used to default to GPT-4. We don't anymore. We default to Claude Sonnet 4.6 for new builds. The reason is boring: it follows long system prompts more reliably and it hallucinates less on retrieval-grounded queries. On a recent legal-tech build, swapping the model from GPT-4o to Sonnet 4.6 with no other changes dropped our hallucination rate on contract clause queries from about 7% to about 2%. Same prompts. Same retrieval. Different model.

We still test multi-vendor on every project. Sometimes Gemini wins on a specific task, especially anything involving long PDFs. But for a structured customer-facing assistant with a knowledge base and a defined tone, Sonnet 4.6 is now our default.

Agentic workflows. This is where MCP changed everything for us. More on that below.

What we tried and killed

Three things we shipped and then pulled back.

A "general copywriter" agent for one of our marketing clients. Claude is a good writer. But "good" is not "good enough to publish under your brand without editing." We were spending more time editing the output than writing from scratch. We killed the agent and used Claude as a brainstorming tool instead. Different job. Worked fine.

A code review bot that ran on every PR in a client's repo. It found real bugs about 15% of the time. The other 85% of the time it produced suggestions the team ignored. Signal to noise was bad enough that engineers turned off notifications, which meant the 15% real bugs got missed too. We rebuilt it to only comment on a narrow set of issues: security, n+1 queries, missing error handling. The false positive rate dropped. Engineers started reading it again.

A meeting-notes-to-tickets agent that listened to client calls, summarized them, and opened Linear tickets. Worked great in the demo. In production, it kept opening duplicate tickets for items discussed across multiple calls. We killed it after two weeks. Going to retry with better deduplication and a human approval step in the loop.

The pattern keeps repeating: fully autonomous fails. Narrow scope plus a human in the loop succeeds. We've stopped trying to skip that lesson.

MCP is the actual story of 2026

If you've been ignoring MCP, this is the part to read.

Eighteen months ago, every time we wanted Claude to talk to a client's CRM, ERP, or database, we wrote bespoke integration code. Custom function definitions. Custom serialization. Custom error handling. Every project had a few hundred lines of plumbing nobody wanted to maintain.

MCP collapsed that into "install a server, point Claude at it." The Anthropic-released Postgres MCP server alone has saved us probably 200 engineering hours across our active projects. We now have a small library of standard MCP servers (Linear, Slack, GitHub, Postgres, Stripe, the client's CRM) that we wire into agents in an afternoon. Things that used to be a two-week integration project are now a one-day task.

The numbers from the wider ecosystem track with what we're seeing. MCP went from 100,000 SDK downloads at launch to about 97 million monthly by March 2026. OpenAI, Google, Microsoft, and Salesforce all shipped support inside thirteen months. Anthropic donated the protocol to the Linux Foundation in December. This is now industry infrastructure, not a vendor protocol.

The thing nobody tells you: most public MCP servers are over-permissioned. Read access and write access usually come bundled. We've had to fork servers and strip them down to read-only for client projects more times than we'd like. If you're putting MCP into a regulated environment, audit the permissions surface before you ship. Mirantis and a few others have published guides on this. They are worth reading.

Honest pricing

Claude Sonnet 4.6 is roughly competitive with GPT-4o on price. Opus 4.6 is more expensive but you should rarely need it for production traffic. We use Opus mostly for offline tasks: data analysis, hard reasoning, anything where a human is going to wait a few seconds anyway.

Where Claude actually saves money is the cache discount. The 90% savings on cached input tokens is real and substantial. On our highest-volume client (a support assistant doing about 200K queries a month with a long system prompt), aggressive prompt caching cut their API bill by about 65% with no engineering changes other than restructuring the prompt for cache stability. That kind of win is rare. Take it when you can get it.

The other thing worth knowing: Anthropic has been more conservative than OpenAI about pushing rate limits and pricing changes mid-contract. We've had two clients on OpenAI hit unexpected rate limit changes that broke their production traffic. None on Claude. Take from that what you will.

Where Claude still loses

Three places we don't reach for Claude.

Image generation. Claude can describe images well. It cannot make them. If your workflow involves generating images, you're going elsewhere.

Real-time voice. Anthropic has not shipped a competitive real-time voice product. For voice AI builds, we still default to OpenAI's Realtime API or ElevenLabs depending on the use case. Claude is sometimes in the loop for the language layer but not the voice itself.

Bleeding-edge agentic browser tasks. OpenAI's Operator is genuinely better at "go do this in a browser" workflows right now. Claude is closing the gap with the Conway agent that's reportedly in testing, but as of April 2026, if your job is "agent, go log into this SaaS dashboard and pull a report," Operator is the safer bet.

The Claude Code workflow that changed our shipping speed

A few specifics, since this part actually moves the needle for engineering teams.

We run Claude Code with a CLAUDE.md at the repo root that has the architecture summary, the conventions we care about, and the gotchas (the API endpoints that look REST but aren't, the test that's flaky, the migration we don't run locally). Roughly 200 to 400 lines per repo. The file pays for itself in the first session because the agent stops asking the same questions.

We use task lists religiously. Long-running work gets broken into tracked tasks. The agent updates them as it goes. This is the single biggest difference between "agent that ships features" and "agent that loses the plot in a long session."

We almost never let the agent ship without a plan first. Plan mode catches half the mistakes before any code gets written. The other half show up in review.

We've stopped writing one-off "ChatGPT in a browser tab" prompts for engineering work. The agent in the IDE with file access, the test runner, and a few MCP servers wired in is a fundamentally different tool. The browser tab is fine for explaining things. The IDE agent ships work.

If you're a CTO trying to decide whether to roll out Claude Code to your team, the test isn't "does it write code." It's whether your engineers will adopt the workflow. Most of our wins happened because the engineers who picked it up first taught the others. The bottom-up adoption is the thing.

What we tell clients to start with

If you're a CTO at a 20 to 200 person company evaluating Claude in 2026, here's the path we suggest.

Start with one production workload that has a clear definition of success. A support classifier, a RAG-based internal search, an email triage agent. Something where you can write down "right" before you build.

Wire it through MCP from day one. Even if you only need one integration today, you'll need three by month four. Saving the integration work later is most of the long-term cost savings.

Cache aggressively. Every system prompt over 1,000 tokens should be cached. The savings compound fast.

Build evals before you ship. Not aspirational ones. Actual labeled examples from your real traffic. If you can't write 50 of them, you don't understand the problem yet.

Use Sonnet 4.6 by default. Reach for Opus 4.6 only when Sonnet's outputs aren't good enough on your eval set. Don't pay Opus prices on tasks Sonnet handles fine.

What's coming next

Two signals worth watching.

Claude Mythos is the rumored next frontier model out of Anthropic, in gated early access through something called Project Glasswing. We don't have it. The benchmarks people are leaking show meaningful jumps on reasoning and coding, with the same broad-stroke shape that Opus 4 had over 3.5. If those hold up, the agent workflows that don't quite work on Sonnet 4.6 will probably work on Mythos.

Conway is Anthropic's reported always-on agent. If it ships and works as described, the architecture of half our client builds changes. Background agents that operate continuously, with persistent state, are a different kind of system from the request-response chatbots we ship today.

Both are unannounced. Don't bet a roadmap on them. But if you're a CTO planning your AI platform for 2026 to 2027, build in the assumption that long-running, persistent, tool-using agents become a real category by mid-2027.

The thing we keep telling people

Pick a model based on the job. Not the brand. We run Claude on most of what we ship. We also run OpenAI, Gemini, and self-hosted small models on specific workloads where they're better. Anyone who tells you "always use Claude" or "always use GPT" is selling you something.

The teams that win in 2026 are the ones who treat model choice as one engineering decision among many, not a religious one. The model is a component. The system around it is the product.

If you're shipping AI in 2026 and you haven't seriously evaluated Claude in the last three months, you're working with stale information.

Considering Claude for a real production workload? Book a free strategy call. We'll look at what you're trying to ship, tell you which model fits, and what the integration actually takes. If Claude isn't the right call, we'll tell you that too.