Claude has released an interview video explaining how the Claude Code team uses Claude code to keep improving Claude code, laying out how the group’s working methods have changed over the last year.
In the interview, team members described a sharp change in how they build products at a fast iteration pace. Several comments stood out: 「You must stay very unattached to the things you are building, because they will disappear quickly」; 「The layer we work at now is already one level of abstraction above the tokens Claude actually outputs」; and 「We are forced to let go and let Claude do its thing, because trust matters more than supervision」. They also said product teams have to stay at the frontier while still delivering value to people using models today, calling that balance both an art and a science.
Most day-to-day work now goes through Claude Tag
According to the team, 70%-80% of its routine work is now handled by Claude Tag, a native AI agent inside Slack. A year ago, engineers on Claude Code were still reading AI work logs line by line, checking every tool call, every parameter choice, and each reasoning step.
That is no longer the core workflow. The team said it has moved away from inspecting each tool call and model decision in detail. Instead, engineers set a goal and let the model reach it on its own. They added that the user interface has been fully decoupled from the model’s internal thinking record. In practice, that means Slack users only see the messages Claude sends through messaging tools, while the model’s internal monologue is not shown in real time.
The team described this as a somewhat frightening kind of forced letting go. Still, at this stage, it said trust has become more important than supervision.
How the team uses Claude Tag to build internal tools
The interview included a concrete example of using Claude Tag to help build Claude Tag itself. The first step starts with a prompt: if the team has an idea, who should it talk to, and who would be interested? Claude Tag then produces a list of stakeholders.
After those conversations, the second step is to have Claude Tag create a prototype mockup and implement the idea. The third step is to ask Claude Tag to add extensive instrumentation, deploy the tool internally, and observe how people use it and whether feedback comes in.
From there, Claude Tag keeps watching usage data. When feedback appears, it alerts the owner and is then told to improve the conversion funnel and figure out how to do it. The team framed this as a highly hands-off approach.
A rule for fast-moving models: do not get attached
The team said all of this has to be understood against one condition: the capabilities of the underlying model go through a fundamental jump roughly every two months. One speaker said the technical ground beneath product teams changes that often. Teams need to push past the frontier to really feel where the boundary is, while also shipping something useful for people using the models right now.
That leads to a working rule: do not become too attached to what you build. Many functions written into the harness exist only to compensate for model limitations at a given moment. Once the model gets stronger, those functions should be removed.
The to-do list feature was offered as a classic example. During the Sonnet 3.5 phase, the model could not complete complex multi-step tasks on its own, so a task list was needed. A year later, after memory became more capable, that once-essential feature was taken down like scaffolding.
Another example involved the AskUserQuestion tool. It was originally designed so Claude could actively ask users questions in the middle of a task. Later, as the model became better at generating HTML, developers shifted toward having Claude produce visual artifacts with charts and mockups and use those to ask questions more naturally.
From fixed solutions to replaceable primitives
Rather than building a full, fixed solution set for a moving target, the team said it now prefers a collection of composable primitives. The interview named Permissions, Visualizations, Verification, Code Review, and Feedback as examples.
This structure lowers the cost of replacement when one primitive becomes obsolete. It also creates room for new abilities to emerge when several primitives are layered and combined.
Human-AI collaboration is shifting to a higher level
The team said the biggest change over the past year can be summed up in one line: the granularity of human interaction with AI keeps moving upward. It started with tokens and individual tool calls, then moved to a session, then a goal, and now to a continuously running work system that can span multiple conversations.
The same rise in abstraction shows up in two parallel tracks.
The first is infrastructure. The path went from local execution to remote development machines, then to hosted containers, and then to a web version running in cloud containers. The point is to keep tasks running in the background and allow them to complete routines.
The second is code review. Human engineers are stepping away from the most repetitive review work. Claude is used first to search broadly for as many suspected issues as possible. Each suspected issue is then subjected to adversarial review, with cross-checking from three different angles, so most of the noise is filtered out and only the problems that really need human attention remain.
The team said this approach later evolved into workflows in which Claude writes code to orchestrate collaboration among multiple sub-agents, combining deterministic code logic with agent autonomy.
Software engineering still comes back to problem solving
Near the end of the interview, the team said some employees who had once been attached to careful hand-built craftsmanship have largely let go of the fear of being replaced and started enjoying the gains in performance.
Its broader point was simple. Software engineering is a profession shaped by change. The problems change, and the tools used to solve them change as well. The interview noted that 10 to 20 years ago, people were still writing JavaScript by hand without any framework. The pace is faster now, but the basic logic is the same: engineering remains, at its core, a problem-solving profession.
The MarsBit article cited a YouTube video as the reference link and said the piece originated from the WeChat public account Quantum Bit, written by Cheng Qian.