What You Discover When an Engineering Team Documents Their Claude Code Usage Independently

A few weeks ago I asked each person on Orbitant’s engineering team to independently document their learnings with Claude Code: what worked, what didn’t, which configurations they’d adopted, and what they’d discovered on their own. No prior meeting, no sharing answers before responding — just their own notes and weeks of real usage on production projects.

The result of compiling that exercise says more about how Claude Code works in engineering teams than any best practices guide.

Because the first thing that caught my attention wasn’t any specific tip. It was the convergence. The team had arrived, independently, at the same three or four conclusions. When very different profiles land in the same place without coordinating, we’re probably not talking about personal preferences. We’re talking about real properties of the tool.

The biggest benefit wasn’t delivering faster. It was the time it freed up to do different work.

Convergence as Diagnosis

The exercise was designed this way on purpose. When you ask a team in a meeting what they’ve learned, group dynamics contaminate the responses: whoever speaks first sets the tone, minority opinions self-censor, and the result tends to look more like social consensus than a real diagnosis. Individual, written responses produce something much cleaner.

The form asked each person to document three aspects separately:

1. Their main learnings and adopted practices
2. The patterns they actively avoided and why
3. Their tool configuration and stack discoveries

When compiling the responses, three levels of convergence emerged:

• Unanimous convergence: practices that virtually every team member mentioned spontaneously, without being suggested in the form.
• Strong convergence: patterns with notable consistency across different projects and profiles.
• Context-dependent variables: decisions that depended on the stack or type of project, with no clear pattern.

That such different profiles arrived at the same place without coordinating is no small detail. In a team with very diverse backgrounds — from junior profiles to architects with years of experience in complex systems — something generating that level of spontaneous agreement is a strong signal. It doesn’t mean it’s the only way to work well with Claude Code. It means these practices aren’t optional shortcuts: they’re the path of least resistance that the tool marks out as it’s used with real intensity.

And that has direct implications. The most common mistake is treating Claude Code adoption as a matter of individual productivity: each person finds their flow, and that’s it. But if the tool rewards certain patterns regardless of the technical profile of the person using it, we’re dealing with a question of collective workflow design. And that’s managed differently.

Claude Code in Engineering Teams: The Three Principles That Emerged

Three practices reached unanimous or strong convergence. I’ll explain them in the order they have impact:

1. Plan Before Executing, Always

The phrase that came up most often was a variation of the same idea: “write a plan before firing the prompt.” The team discovered, through different paths, that structuring the problem before delegating it improves results in a non-linear way.

In practice: use planning mode for any non-trivial task, define the scope and constraints before starting, and resist the temptation to try without clear direction. The cost of planning is low and predictable; the cost of iterating over a misdirected result is high and cumulative. Those who skip this step save five minutes and lose thirty.

2. CLAUDE.md as the Project’s Source of Truth

The team treats the CLAUDE.md file not as optional documentation but as the primary mechanism for persisting context between sessions. Naming conventions, architectural constraints, domain vocabulary, and any pattern that must be consistently respected all live there.

The scale this reaches when taken seriously: some team members have more than 15 CLAUDE.md files distributed in layers — personal, organization, repository, domain — in infrastructure projects. It’s a shared knowledge system that grows with the project. Every convention not documented there is a correction that gets repeated manually, session after session.

3. Delegate at the Feature Level, Not the Line Level

The third principle is the hardest to internalize because it goes against the most widespread habit: using Claude Code as sophisticated autocomplete. What the team has learned is that this leaves most of the value on the table.

The change is about granularity: instead of asking it to complete a function, delegate the entire feature — implementation, tests, documentation — and review each diff carefully. This produces smaller, more contained changes, easier to review with the rigor that code quality requires. Quality isn’t in the initial output — it’s in that moment of review.

Smaller diffs are much easier to review in depth, and that’s where real quality comes from.

What Convergence Reveals About the Tool — and How to Adopt It as a Team

The convergence has two readings. One is that the team is on track to create its own best practices. The other is that Claude Code has a way of working that consistently rewards certain patterns, and that those patterns emerge on their own when the tool is used with sufficient intensity.

If the second is true, it changes how we should think about adoption. Working with Claude Code in engineering teams isn’t an individual discovery process that each person has to travel alone. It’s a process that can be accelerated:

• Making the principles explicit from day one shortens the time to quality results.
• Sharing the foundation — same CLAUDE.md files, same skills, same vocabulary for talking about what works — creates a collective starting point that reduces friction.
• Iterating on shared artifacts, not individual configurations, turns personal learning into a team advantage.

A technical profile using Claude Code well can multiply their productivity significantly. That’s documented. But an entire team using it in a coordinated way generates a different kind of advantage: each person’s knowledge improves everyone else’s environment. Every skill built, every convention documented, every learning made explicit amplifies the collective result. The value doesn’t grow linearly. It compounds.

At Orbitant, we’ve spent several months building that system deliberately: shared skills, layered CLAUDE.md files, and an onboarding process that starts with the principles, not the tool. In the next article in this series, I’ll go into the concrete architecture of that system: which skills have generated the most return, how the team’s CLAUDE.md files are structured, and the problems that still don’t have a clear solution.