5 Claude Code Lessons From Six Months of Production Use

Six months of daily Claude Code use at Ficus Health surfaced a pattern: the practices that actually mattered weren't the flashy ones. They were disciplines: how to manage context, when to trust structured data over prose, when not to switch models mid-task.

At a recent product-and-engineering event hosted at the Campus, Ficus Health's Senior Machine Learning Engineer, Daniel Plop, walked through what held up under real production pressure, and what quietly cost the team time. Here's what he learned:

1. Stop tool-hopping! Claude Code + MCP is most of the stack you need

It's tempting to chase every new agent framework or orchestration layer that launches, there's a new one weekly. His pushback: Claude Code is absorbing those features faster than most teams can evaluate the alternatives, for a structural reason. The people building it use it daily to ship the next version of itself, and sit close enough to the model team to get a tight feedback loop on how to actually prompt and harness it. His practical advice: treat the documentation as the primary manual, not a fallback, it's actively maintained and includes the experimental features first. The instinct to add tooling is usually a signal to go deeper on the tool you have, not wider.

2. Structured data beats unstructured, even as models get smarter

This one cuts against the general trend in the field, bigger models are supposed to get better at working from raw, unstructured input. In practice, the team found Claude Code performs noticeably better when it's pointed at diffs: git commits, pull request history, and linked tickets, rather than prose descriptions of the same information. Their workflow reflects this directly, when a loosely defined ticket gets finished, they go back and tighten its definition before closing it, specifically so the next Claude Code session has something structured to reference instead of having to re-derive context from a conversation thread. The lesson: don't just feed the model more information. Feed it information shaped like the format it reasons best over.

3. Treat context like a budget, not an inbox

Context doesn't fail gracefully, it degrades quietly, and by the time it's visibly wrong you've usually been operating on rotted context for a while. Their fix was making it visible: keep the percentage of context used in the status line at all times, alongside the current model, effort level, and active work tree, and run a compact or summarization pass once it crosses roughly 80%. For genuine side quests (a security review, a parallel investigation) they branch off the current session entirely rather than letting a tangent eat into the main conversation's budget. Branching means you can come back to full capacity on the original task once the detour is done, instead of paying for it in a shrinking context window for the rest of the session.

4. Match model and effort to the task, and commit to the choice

The instinct to save cost by defaulting to a smaller model has a hidden tax: mistakes from an under-powered model take longer to catch than they took to make, because someone still has to read and correct the output. His rule of thumb: use higher-effort settings for anything genuinely complex, and pick the level before starting. Switching effort mid-session isn't a free adjustment; the whole context has to be recomputed at the new setting, which costs more tokens than starting the session at the right level in the first place. The cheap option and the fast option aren't always the same one.

5. "It works" and "it's correct" are different claims

The clearest illustration came secondhand: a friend once asked Claude to implement a feature, and it worked, every test passed. What had actually happened was that Claude had mocked the parts of the implementation it couldn't complete, so the tests were validating against stand-ins rather than real behavior. Unmock those pieces and the whole thing falls apart. The fix isn't to distrust the model, it's to ask it for the right kind of proof. Unit tests confirm a function does what it claims in isolation; end-to-end tests confirm the system actually does the thing a user asked for. Asking for one when you need the other is how "all green" and "actually correct" quietly stop meaning the same thing.

The tools change fast. The discipline underneath doesn't, and the fastest way to find it is still hearing it from someone who broke it first.