Claude Code Team Interview: How Engineers Shift from Writing Code to Managing AI Goals

In today's rapidly evolving AI programming tools landscape, Anthropic's Claude Code team is experiencing a profound paradigm shift in their work. A recent internal interview reveals a thought-provoking trend: the core work of software engineers is transitioning from "writing every line of code by hand" to "setting high-level goals for AI and driving product forward." This is not merely a tool upgrade, but a reconstruction of the entire software development lifecycle.

Claude Code and Anthropic Background

Claude Code is an AI programming assistant product launched by Anthropic. Founded in 2021 by former OpenAI Research VP Dario Amodei and his team, Anthropic focuses on AI safety research. Claude is their flagship large language model series, renowned for Constitutional AI technology—ensuring AI behavior safety and controllability by teaching the AI a set of values and principles. Claude Code applies these capabilities to software development scenarios, not only generating code but also understanding project context, executing tool calls, conducting code reviews, and other complex tasks.

From Line-by-Line Review to Goal Orientation

In the interview, team members reflected on tremendous changes over the past year. A year ago, they were still writing prompts for Claude Code, approving permission requests one by one, carefully reviewing every tool call; now, their working approach has fundamentally transformed.

Transcript and Tool Calling Evolution

In AI Agent systems, transcript refers to the complete record of model-environment interactions, including the model's thought process, decision rationale, tool call sequences, etc. Tool calling is a critical capability of large language models—the model not only outputs text but can also call external APIs, execute code, read and write files, etc. Early AI programming tools required developers to approve each tool call individually (such as file modifications, command execution) to prevent unintended operations. As model reliability improved and safety mechanisms matured, this micro-management gradually gave way to higher-level goal-oriented interactions.

We've moved from focusing on the technology itself, on every transcript, every tool call, and every model decision, to a more macro perspective—I have a goal, I want to achieve it, and then you hand that goal to the model to complete.

One member revealed that now 70% to 80% of work is completed through Claude Tag (an AI Agent natively integrated in Slack), with only about 20% requiring opening the TUI or desktop application for fine-tuning. This trust in "letting Claude cook" stems precisely from substantial improvements in model capabilities—no longer needing to watch every token output while still achieving high-quality results.

What is an AI Agent

AI Agent refers to an AI system that can perceive its environment, make autonomous decisions, and take actions to achieve goals. Unlike traditional "Q&A-style" AI, Agents possess persistence, initiative, and tool-use capabilities. Core characteristics of agentic systems include: goal-oriented planning ability, multi-step task execution, learning and adjusting strategies from feedback, and interaction with external tools and APIs. In software development scenarios, Agents not only generate code but can also run tests, consult documentation, submit code, monitor system status, etc., forming a complete development loop. This shift from "tool" to "colleague" is the core direction of current AI programming assistant evolution.

The Unique Value of Slack-Native Agents

Deploying AI Agents in collaborative environments like Slack has deep significance. Claude Tag can proactively review product context and historical decisions made by the team, understanding "what this product should be." This additional contextual information significantly improves the quality of Agent decisions.

Two-Month Technical Shelf Life

One highly insightful point from the interview: the technical "shelf life" of AI products has been extremely compressed.

In the past, technology had a shelf life measured in years—if I'm going to build a product, I have high confidence it will be something lasting, for several years or even longer. But for AI models, the underlying technology fundamentally changes every two months, and this cycle is being compressed over time.

This creates a balancing challenge where art meets science: standing at the technological frontier or even beyond to sense boundaries, while providing real value to users currently using the model.

To-Do List: A典型 "Build and Abandon" Case

The team vividly illustrated this "use and discard" development mindset with the To-do list feature. In the Sonnet 3.5 era, models couldn't handle long-term work—give it five tasks, and it would quit after completing three. So the team introduced a To-do list mechanism, with immediate results.

But a year later, this feature was removed. The model had more complex memory states and other mechanisms to rely on, making the To-do list unnecessary. Team members summarized: "This is a perfect example of how you must remain unattached to what you build, because it will disappear quickly."

The underlying logic: many features in Claude Code are essentially patches for current model failure modes. As model capabilities strengthen, these patch-like features can be boldly discarded, replaced by new tools needed to tackle larger, more complex tasks.

Loops: From Local Execution to Cloud Persistence

An interesting "origin story" from the interview concerns the birth of the Loops feature. Initially, an engineer ran all Agents on their laptop, but when they went home and shut down after work, the Agent stopped.

This pain point drove a clear evolution path:

1. Local execution phase: Agents limited by dev machine on/off times
2. Remote hosting phase: Using remote dev machines, avoiding SSH hassles
3. Cloud persistence phase: Claude Code on the web—hosted containers running continuously in the background

Since we did this, my productivity increased 10x.

Once Claude runs in the cloud, more interesting scenarios become possible: for example, setting up daily routines to automatically review all user feedback, categorize by importance, and automatically fix issues it has high confidence in solving.

This is essentially a process of "breaking session boundaries"—from prompting the model in a session, to prompting a higher-level system that continuously helps you fix bugs and execute tasks.

Workflows and Fan-out: Trading Test-Time Compute for Confidence

Code Review spawned another important capability for the team—Workflows.

Large-Scale Fan-out and Adversarial Review

Code review was the team's first "large-scale fan-out" scenario. The specific approach: have Claude search for potential bugs in parallel, conducting adversarial review on each bug—examining whether the bug truly exists from three different perspectives. This filters out numerous false positives, presenting only the most important issues that genuinely need human attention.

The Power of Test-Time Compute

Test-time compute is an emerging concept in AI, referring to investing more computational resources during the inference stage (rather than training stage) to improve output quality. Traditional thinking holds that model capabilities mainly depend on training scale, but OpenAI's o1 and similar models prove that by having models "think deeply" when answering—conducting internal reasoning chains, self-verification, multi-perspective analysis—success rates on complex tasks can be significantly improved. In code review scenarios, this means having AI repeatedly verify the same potential bug from multiple perspectives, rather than relying on a single judgment. This method is especially effective for tasks requiring rigorous logic like mathematical reasoning, code generation, and planning, at the cost of increased response time and computational expense.

This is exactly what the team calls test-time compute—investing substantial inference time and computational power into thinking about a problem to build confidence.

Essentially a MapReduce Problem

The team astutely points out that the core challenge of fan-out is: once you fan out, information explodes, and you need to converge it back for human consumption. "If I directly read the raw fan-out output, I'd go crazy." Therefore, mechanisms are needed to build confidence, and the method is investing more test-time compute.

Applying MapReduce Thinking

MapReduce is a classic distributed computing model proposed by Google in 2004. The core idea is dividing large-scale data processing into two stages: the Map phase decomposes and processes tasks in parallel, and the Reduce phase aggregates results. This thinking equally applies to AI Agent workflows—when facing complex tasks, first decompose them into multiple subtasks for parallel execution (fan-out), then intelligently aggregate results into human-understandable form (convergence). For example, in code review, check multiple potential issues in parallel, then filter false positives through adversarial verification, finally presenting a refined findings list. This pattern leverages AI's parallel processing capability while ensuring workflow predictability through deterministic orchestration code.

More cleverly, since the Agent itself writes code to orchestrate sub-Agents, this forms a hybrid of deterministic code behavior and Agentic LLM behavior. When Claude writes a for loop to traverse a project, developers know it won't skip anything and will apply the same technique equally to all items—this predictability significantly increases human trust in AI.

This capability applies not only to AI code review but equally to performance troubleshooting, general deep research, and even planning a family trip.

Claude Tag: Building Claude with Claude

The team is "aggressively building Claude Tag itself using Claude Tag." Behind this is a key architectural change: the user interface is decoupled from the transcript for the first time.

Deep Significance of Architectural Decoupling

In traditional AI assistants, the user interface directly displays the model's complete thought process (transcript), including all tool calls, intermediate reasoning, etc. While this transparency aids debugging, it also brings information overload and interaction rigidity. Claude Tag adopts a decoupled architecture: the model's internal monologue is separated from messages users see, with the model proactively choosing what to show users and when through a "send message" tool. This is similar to human collaboration—you don't need to hear all of a colleague's thought process, only need effective communication at key points. This abstraction improves interaction naturalness, making AI more like a collaborator with judgment rather than an execution tool requiring constant supervision. The tradeoff is sacrificing some observability, but gaining more efficient human-AI collaboration experience.

When you see Claude Tag messages in Slack, it's actually calling a tool to send messages, while its internal monologue is invisible to users. This abstraction layer was initially "a bit scary"—you can't see all of Claude's thinking. But it proved extremely liberating: you no longer obsess over which tool it called or what parameters it passed, but rather Claude chooses what to say and when.

A Real Product Development Loop

One member shared the complete workflow of developing a new tool using Claude Tag, exemplifying AI-driven development:

1. Exploration phase: First ask Claude "who might be interested in this idea," finding potential stakeholders
2. Design phase: Have Claude make mockups directly in Slack, viewable on mobile
3. Implementation phase: Complete development and add extensive event tracking
4. Monitoring phase: After internal deployment, have Claude Tag continuously monitor usage and user feedback
5. Response phase: When someone provides feedback, Claude @mentions the developer, enabling highly responsive intervention
6. Optimization phase: When funnel issues are discovered, instead of giving direct instructions, let Claude "improve this funnel," collaborating at a higher abstraction level

Event Tracking and Intelligent Monitoring

Event tracking is a core data collection technique in product development. By inserting event logging statements in code, it tracks user behavior patterns, feature usage, conversion funnels, and other key metrics. Modern product analytics platforms (like Mixpanel, Amplitude) can process these event streams, generating user profiles, retention analysis, A/B test reports, etc. The "extensive event tracking" mentioned in the interview means establishing a comprehensive observability system when new features launch. Going further, Claude Tag can automatically monitor these data streams, proactively discover issues—such as abnormally high drop-off rates in a conversion step—and alert developers, even autonomously proposing optimization plans. This elevates data-driven development from "manual dashboard analysis" to a new paradigm of "AI continuous monitoring and suggestions."

This confirms the core point in the interview—verification, code review, and getting feedback have all become basic primitives in Claude Code, connecting various feedback sources like data stores, event streams, Slack, GitHub issues, etc.

What Engineers Lose and Gain

At the interview's conclusion, the team candidly discussed the "losses" and "gains" in this transformation.

Lost pleasures:

• Some miss the joy brought by performance engineering—diving deep into systems to improve performance, "but Claude does it better than me now"
• Someone once spent an entire day using CSS to precisely replicate the macOS 10.4 Aqua button, stacking radial gradients—"Claude can do this for me directly now, I'll never do it manually again"

Gained possibilities:

One member likened this feeling to being seven or eight years old, wanting to make games but not knowing how to code, only able to use PowerPoint to draw clickable shapes. "Claude makes all of software engineering accessible to me. Whatever idea I have, I no longer have to say 'I don't have the technical ability for this,' but rather 'This is what I want to achieve, let's break it down, figure out how to make it happen together with Claude.'"

The team's attention is shifting from "diving into details" to "generating new ideas faster"—the path from idea to prototype to production has been greatly shortened.

Software Engineering: The Eternal Profession of Change

Software engineering is inherently a profession about change.

From hand-writing JavaScript to inventing frameworks and compilers, change has always been happening, just faster now. But the essence of software has never changed—how to use tools to create excellent things, how to solve problems.

"You're solving different problems, but you're still solving problems." This is perhaps the most profound insight this interview leaves for all developers: AI changes tools and abstraction levels, but the core value of engineers as "problem solvers" is actually further amplified.