Most advice about Claude Code comes from people who use it. In September 2026 the people who build it described how they work with it themselves, and a community recap of that session is the source for this post. Four habits stand out. None needs a bigger budget. All of them need a team willing to change how it supervises, reviews and maintains its own tooling.
The common thread is that the team keeps moving its attention up a level: from watching each tool call to setting a goal, from reading every line to checking the reasoning, from building workarounds to deleting them. That is a management change as much as a technical one, which is why it matters to an Australian engineering lead and not only to the developers on the tools.
How does the Claude Code team use Claude Code?
The Claude Code team sets a goal and lets Claude run, instead of watching each tool call. One team member does 70 to 80 per cent of his work through Claude Tag in Slack and opens the terminal or desktop app only to refine. The team also deletes old harness workarounds as models improve, hands review nitpicks to Claude, and asks Claude to raise questions through mockups and diagrams.
The Slack detail is more than a preference. Claude Tag separates the interface from the transcript: the messages you see are sent through tool calls, and the execution detail sits behind a link. You read the outcome first and open the detail only when something looks off. The team's own remark was that getting good results without constant supervision showed them how far the models had come.
| Habit | What it replaces | First step for your team |
|---|---|---|
| Set a goal, check the result | Watching every tool call | Run one well-scoped task from Slack and read only the summary |
| Delete old workarounds | A harness that only grows | List every rule you added for an older model |
| Review the reasoning | Nitpicks on the diff | Let Claude do style comments; humans ask why |
| Ask with pictures | Text-only clarifying questions | Have Claude present options as a mockup or diagram |
Don't get attached to the workaround
The team gave two examples from its own history. An earlier model, Sonnet 3.5, might finish three of five tasks and stop. A to-do list fixed that. A year later the fix was no longer needed. The second example is AskUserQuestion, which took real design work before Claude called it well. Its creator now uses it less, and has Claude ask its questions through HTML artifacts with mockups and diagrams instead.
The lesson they drew: much of a harness exists to patch the weaknesses of the current model. Better models let you remove those patches. Bigger tasks then need different tools, so the harness does not shrink to nothing. It changes shape.
Most teams we see do the first half and skip the second. Rules pile up in CLAUDE.md, hooks and wrapper scripts, each added after a bad day, none ever removed. Every one of them costs context and slows the agent down. A quarterly prune is cheap. Our post on CLAUDE.md rules that stop overengineering covers which rules tend to earn their place.
Date every rule and workaround when you add it, with the model it was written for.
After each model upgrade, turn the oldest ones off for a week and watch what breaks.
Keep the ones that still prevent a real failure. Delete the rest.
Expect to add new tooling for longer tasks even as you remove the old.
Review the reasoning, not just the diff
One observation from the session will be familiar to anyone who has sat through a pull request queue: leaving nitpicks can be a way of saying "I read this". Claude can handle those comments. The human reviewer is better spent on context Claude may lack, such as why an API is structured a certain way, or why a service boundary exists where it does.
The team's review workflows grew out of this. They fan out agents to find bugs, then challenge each candidate from several perspectives to filter out false positives. Code orchestrates the agents, and a plain for loop applies the review to every item. That last point is easy to miss. The orchestration is ordinary code, not a clever prompt, which makes it repeatable and testable.
If your team is still reading every generated line, start with how to stop reviewing Claude Code output line by line, then look at the multi-agent workflow patterns that hold for the fan-out and challenge structure.
What this is worth to an Australian team
An illustrative example, not a benchmark. Take a Sydney product team of six engineers at a loaded cost of about $180,000 each. If each spends five hours a week on review comments about naming, formatting and missing tests, that is 30 hours a week, or roughly $135,000 a year of senior time spent proving the code was read. Moving that work to Claude does not remove review. It moves those hours onto the questions only your people can answer.
For teams in regulated sectors there is a second benefit. A reviewer who records why a boundary exists or why a design was accepted leaves a better audit trail than twenty style comments. If your change process has to stand up to APRA or an internal risk function, reasoning on the record is the more useful artefact.
What not to conclude
Three cautions before you copy any of this.
They build the tool. The Claude Code team knows its limits better than anyone and works in a codebase designed around it. Working mostly from Slack is a result of trust built over many tasks, not a starting point. Begin with small, well-scoped jobs and widen from there.
Less supervision is not less verification. Not watching tool calls only works when something else checks the outcome: tests, a review workflow, a clear definition of done. Remove the watching without adding the checks and you have simply stopped looking.
The work changes, and people notice. One team member enjoyed performance engineering and now says Claude is better at it. Another spent a day stacking CSS gradients to recreate old Mac OS buttons and would not do it by hand again. The recap called it bittersweet. Engineers on your team will feel the same about skills they spent years mastering. Say so openly, and be clear about where their judgement now counts most.
Where to start this month
Pick one habit, not four. For most teams the cheapest is the workaround audit: an hour with your CLAUDE.md and hooks, a list of what was written for which model, and a week with the oldest rules switched off. The review change gives the larger return but needs agreement from the whole team on what humans still own.
If you want a second opinion on your Claude Code setup, or help designing a review workflow that fits your controls, see our services or book a short call. We work with Australian teams moving Claude Code from individual use to a team practice.
