The Claude Code team is really straightforward, they even spill the beans on this.

It is said that

Claude released an interview video about how the Claude Code team uses Claude Code to continuously optimize Claude Code.

During the interview, Claude's employees shared their strong feelings about the changes in their work methods over the past year.

They then focused on sharing their views on "building products at an extremely fast iteration pace".

△ (This scene is so warm that it looks like three super dads discussing how to raise children.)

This article sorts out the core content of this interview, the highlights include but are not limited to:

"You have to be extremely detached from what you are building, because they will disappear very soon."

"Our current work level is already one abstraction layer higher than the tokens actually output by Claude."

"We are forced to let go and let Claude play its part, because trust is more important than supervision."

"You must not only stand at the cutting edge of technology, but also provide value to people who use the model today. This is both an art and a science."

"Software engineering is a 'career of change'. The problems you solve are changing, but the core is always problem solving."

We hope it will inspire you who are also in the fast pace of technological iteration.

How does the team work now?

The team stated that currently, 70%-80% of their daily work has been handed over to Claude Tag, a native AI agent of Slack (the US version of Feishu).

A year ago, engineers of Claude Code were still reading line by line the AI's work records.

Including every tool call, every parameter selection, every step of reasoning and decision-making...

(What a huge workload.)

The core concept of their work now is: no longer review tool calls and model decisions one by one, but issue a goal and let the model achieve it on its own.

It is not known whether this concept is related to the product design of Claude Tag. Perhaps to make it more like a real Slack participant, they completely decoupled the user interface from the model's thinking records.

In this way, the AI's internal monologue will be hidden by the Slack interface, and every message humans see is just Claude calling the messaging tool, and its real thinking process will not be displayed in real time.

The team believes this is a kind of somewhat scary forced letting go.

At the same time, they are also aggressively using Claude Tag to develop Claude Tag itself.

Then they cited a very interesting development case of a new internal tool:

The first step is to ask Claude Tag: "I have an idea like this, who should I talk to? Who will be interested in this?"

Claude Tag delivered a list of stakeholders.

After the discussion, the second step is to directly let Claude Tag make prototype sketches and specific implementations.

The third step is to let Claude Tag add a large number of buried points, deploy the tool for internal use, and observe "how do people use this? Did anyone give me feedback?"

After that, Claude Tag will continuously monitor the usage data of this tool. Once it receives feedback, it will actively remind the person in charge, and at the same time ask it to "go and improve this conversion funnel, figure out a way by yourself".

In short, it is a purely free-range model. They said that at this current stage, perhaps trust is more important than supervision.

The core essence is "not clinging to battles"

In fact, all problems must be considered under a premise.

The capability of the underlying model will undergo a fundamental leap every two months.

"The technical foundation will change fundamentally under your feet every two months... You have to stay at the cutting edge, and even go beyond the cutting edge to truly feel the boundary. But at the same time, you have to provide value to people who are using these models today."

And this is a balance, half art and half science.

This leads to a work rule that "you must be very detached from the things you build."

After all, many of the features written into the harness are essentially designed to make up for the shortcomings of the model's capabilities at that time. Once the model becomes stronger, these features need to be removed immediately.

A very classic case is the to-do list function.

In the Sonnet 3.5 stage, the model was not yet able to complete complex multi-step tasks, so it needed a to-do list.

But a year later, the model has more complex memory capabilities, and this once life-saving function was removed like scaffolding.

Another example is the AskUserQuestion tool.

It was originally carefully designed to allow Claude to actively ask users questions in the middle of a task, but after the model's ability to generate HTML became stronger, developers naturally turned to letting Claude directly generate visual artifacts with charts and mockups to ask questions.

Faced with such a precarious reality, the team's approach is no longer to build a complete set of fixed solutions, but to build individual freely combinable "primitives".

Such as Permissions, Visualizations, Verification, Code Review, Feedback...

The advantage of this is that when a certain primitive becomes obsolete and needs to be replaced, the cost is lower.

Moreover, when these primitives are stacked and combined layer by layer, unexpected new capabilities often emerge.

The core of engineers is always Problem Solving

If we have to sum up the biggest change in the way of working in this year, in a nutshell, the granularity of human-AI interaction is constantly moving upward.

From tokens and specific tool calls at first, to a session, then to a complete goal, and now to a "continuously running work system that crosses multiple session boundaries."

The level of abstraction is constantly rising, which is also reflected in two parallel clues.

The first is the evolution of infrastructure, from the earliest local operation to remote development machines, then to hosted containers, and then to web versions that can run in cloud containers, ensuring that tasks can always run in the background and complete routine tasks.

The second is the evolution of the code review route.

People are freed from more trivial code reviews — let Claude search for as many suspected problems as possible on a large scale, then conduct adversarial reviews for each suspected problem, and conduct cross-verification from three different angles, so as to filter out most of the noise and only leave the problems that really need attention to humans.

This idea later evolved into workflows, where Claude writes code by itself to orchestrate the collaboration of multiple sub-agents, combining deterministic code logic with the autonomous judgment of agents.

At present, those employees in the Claude Code team who are keen on handcrafting with exquisite skills have let go of the obsession of "being replaced" and began to enjoy the pleasure of performance improvement...

After all, software engineering is essentially an industry all about change. Although the problems being solved are constantly changing, the tools for solving problems are also constantly changing.

Who would have thought? Ten or twenty years ago, people were still writing JavaScript by hand without any framework.

Nowadays, the speed of change is faster, but the underlying logic has never changed. In the final analysis —

Engineers are always a profession about "how to solve problems".

Reference link: [1]https://www.youtube.com/watch?v=S-sYlFiGFv8

This article is from WeChat official account "QbitAI", author: Cheng Qian, published by 36Kr with authorization.