Claude Code 团队如何用 Claude Code 重塑软件开发流程

Brief Description

Members of the Claude Code team discuss how they now use Claude Code and Claude Tag for increasingly complex software work. They reflect on rapidly changing model capabilities, the role of workflows and long-running agents, how code review and verification are evolving, and why engineers are shifting from supervising individual tool calls to directing higher-level goals.

Table of Contents

• From individual prompts to goal-directed work
• Building at the speed of changing models
• Interactive tools, artifacts, and composable primitives
• Long-running agents and loops
• Code review, fan-out, and workflows
• Claude Tag as an interface for software development
• Verification and feedback in the development loop
• What engineers keep and what changes

From individual prompts to goal-directed work

Speaker 1: The team opens by noting how difficult it is to plan even a few months ahead. It has been almost a year since one participant joined Claude Code, and the contrast with the early product is striking: people used to prompt Claude Code, give feedback, and accept permission prompts directly.

Speaker 1: Now much of the work happens through Claude Tag, a Slack-native agent. The problems given to it are far more complicated than implementing a class or writing a function. Because it can look up product context and team decisions, it can make better choices about what to do.

Speaker 1: Another participant says that 70 to 80 percent of their work happens in Claude Tag. They may open the TUI or desktop app to refine something, or when they want to micromanage their Claudes. The team has moved away from caring about every transcript, tool call, and individual model decision toward expressing a goal and letting the model pursue it.

Speaker 1: Building Claude Code and the primitives that feed into Claude Tag has changed the software-development lifecycle. The team now uses these capabilities for verification, code review, brainstorming, and monitoring.

Building at the speed of changing models

Speaker 1: Every product and its underlying technology has a shelf life, but that lifetime has compressed. In the past, a team could make a product with confidence that the technology would remain stable for years. With AI models, the technology can shift fundamentally every two months, perhaps even faster over time.

Speaker 1: The challenge is to stay at the frontier, and sometimes beyond it, while still delivering value to people using current models. Building for technology that moves this quickly is a balancing act between art and science.

Speaker 1: A useful example was the to-do list feature around Sonnet 3.5. The models could not reliably do long-horizon work: give them five tasks and they might finish three, then stop. A to-do list was exactly the right support for that moment, but a year later it was less necessary because richer memory states and other capabilities were available.

Speaker 1: The lesson is to remain unattached to the things being built. Features in the Claude Code harness often compensate for present model failure modes. As models improve, the team can remove features that are no longer relevant and focus on the new tools needed to keep models coherent on larger, more demanding tasks.

Speaker 1: The Claude Code team works in a kind of hyperbolic time chamber for software development. It must follow model capability closely and sometimes make major changes quickly, such as creating a new proactive agent while also rewriting the permission system and creating supporting artifacts. Engineers in other products also need a current mental model of where model capabilities are going, and the product should help them maintain it.

Interactive tools, artifacts, and composable primitives

Speaker 1: The ask-user-question tool illustrates this rapid change. It began as a way to make Claude interactive, initially placed after planning. The designer realized it could instead be a tool Claude called itself, but it took substantial work to get the model to call it well.

Speaker 1: Once the tool began working reliably, model capabilities soon outpaced the original interaction. The speaker now often creates an artifact instead: an HTML artifact can ask questions and include diagrams and mockups. A capability that was initially difficult for the model has become routine surprisingly quickly.

Speaker 1: This is how the team approaches Claude Code: it creates primitives for permissions, visualizations, and related capabilities, then layers them together. The details of the right primitive change as model behavior changes.

Long-running agents and loops

Speaker 1: The discussion of loops begins with a practical problem. One participant used to run everything locally on a laptop, but leaving the office meant shutting it down and stopping the agent. Remote hosted developer boxes allowed work to continue without keeping the laptop on, but required SSH access and returning to a hosted surface.

Speaker 1: Claude Code on the web emerged from that need. Hosted containers can continue running in the background, though giving a container access to a development environment can be difficult to set up. The speaker considers it worthwhile and estimates that it has increased their productivity tenfold.

Speaker 1: The progression is from Claude running locally, to Claude running in the cloud, to an agent that can perform routines. For example, it can examine daily feedback, group it by importance, and fix issues it has high confidence it can resolve.

Speaker 1: This is the loop journey: instead of prompting a model inside one session, a person prompts at a level above the session boundary. The resulting agent can keep working, fixing bugs, or otherwise carrying out the user's intent.

Code review, fan-out, and workflows

Speaker 1: More generated code makes code review and security especially important. Claude can help human reviewers decide where to focus. In traditional review, a reviewer might leave a few minor comments partly to signal they had read the code. Claude can find and address many of those small issues autonomously.

Speaker 1: The important human work becomes the larger picture: understanding why an API has a particular structure or why service boundaries were drawn in a particular place. Claude can bring that context into review and hand it to a human, allowing the reviewer to work at a higher level of abstraction instead of nitpicking line by line.

Speaker 1: Code review was also the first major use of a broad fan-out. Claude can search for many possible bugs, then coalesce the results. The team calls this test-time compute: applying substantial inference-time thought and compute to a problem.

Speaker 1: Workflows grew out of this approach. A custom harness can send Claude out to find bugs, then run adversarial reviews that assess each possible bug from several perspectives. That filters false positives and leaves the issues that genuinely deserve human attention.

Speaker 1: The same pattern can apply to performance problems or general research. For example, a trip-planning workflow could issue many searches for Tahoe accommodations and places to visit, then use agents to sort, select, and verify the results before producing an answer.

Speaker 1: Fan-out creates too much information for a person to consume directly, so it must be filtered back down. The speaker compares the pattern to MapReduce. Confidence comes from applying test-time compute, while the result remains manageable for a human.

Speaker 1: Claude can make its own harnesses by deciding the topology of the fan-out, connecting one agent's output to the next stage, and summarizing the result. Workflows combine deterministic code with agentic LLM behavior. A for loop over a set of items offers a reassuring guarantee that the same technique will be applied to every item, which increases trust in the workflow.

Claude Tag as an interface for software development

Speaker 1: The team is using Claude Tag aggressively to build Claude Tag itself. One major focus is ensuring that it has an easy development environment and dev loop, so it can do the human tasks needed to build software and test it end to end. This becomes harder as the software grows more complex and integrated.

Speaker 1: Claude Tag also represents a more complete decoupling of the user interface from model transcripts. A Slack message from Claude Tag is sent through a messaging tool; the model's internal monologue is not exposed in the primary interface, though a link can reveal full transcripts.

Speaker 1: Initially, not seeing every detail of Claude's thinking felt unsettling. Over time it has been freeing: Claude chooses what to communicate and when, and the human no longer has to monitor every tool call or parameter. The experience forces people to let Claude work and demonstrates that current models can return good results without detailed transcript supervision.

Speaker 1: One participant describes developing a new tool that needed broad buy-in. They asked Claude Tag who to talk to, got relevant stakeholders, created mockups in Slack that could be viewed on a phone, and had it help with implementation. They then added events, deployed internally, and used Claude Tag to monitor usage and feedback.

Speaker 1: The agent can tag the developer when somebody provides feedback, making them more responsive and more confident that the tool works. When the speaker saw users falling out of a funnel, they shifted from telling Claude a specific solution to asking it to improve the funnel and propose ideas at a higher level.

Verification and feedback in the development loop

Speaker 1: The group identifies verification, code review, and feedback as connected primitives. Feedback can come from a data or event store, metrics, Slack, GitHub issues, or other sources, and these are all useful building blocks in Claude Code.

Speaker 1: Verification is especially important to the team. When Claude creates a pull request for Claude Code, it tests the change and sends screenshots of what the result should look like. Those artifacts provide confidence before a human inspects the work.

Speaker 1: A participant explains that they still performed a sanity check by asking Claude to record itself using the TUI, then cloning and trying the result personally. They expect that over time they may not even need to clone it themselves, as confidence in the verification loop improves.

What engineers keep and what changes

Speaker 1: Looking back over the past year, the team added primitives such as auto mode, memory, and workflows. There is a great deal for a developer to keep track of, but the harder part of being a software engineer now is freeing mental space: understanding what is possible, automating more, and stepping back to think bigger.

Speaker 1: One participant used to get a great deal of satisfaction from performance engineering: deeply understanding a system and improving its performance. Claude is now better at much of that work, but the person still benefits from the improvements. Their attention has shifted toward generating ideas faster and moving from idea to prototype to production more quickly.

Speaker 1: Another participant enjoys detailed UI work and recalls spending a day recreating Mac OS 10.4 Aqua buttons in CSS, carefully layering radial gradients. That is now work they would ask Claude to do rather than perform manually.

Speaker 1: They compare the feeling to being seven or eight years old and wanting to make a video game before knowing how to code. At the time, PowerPoint was a tool for creating clickable elements and shapes. Claude now makes the full realm of software engineering feel accessible: a person can state what they want to accomplish, break it down, and work with Claude to make it happen without first possessing every technical skill.

Speaker 1: Software engineering has always been a profession of change. People once hand-wrote JavaScript before frameworks, compilers, and other tools changed the work. The pace is faster now, but the core remains the same: using available tools to create remarkable software and solve problems. The problems may differ, but the work is still problem solving.