How the Claude Code team moved from supervising steps to setting goals

Thariq Shihipar notes that a year earlier the team was prompting Claude Code, providing feedback and accepting permission requests. He asks Robert Boyce and Sid Bidasaria how they work with it now.

Boyce says he does much of his work through Claude Tag and gives it much more complex problems than implementing a class or writing a function. Because the agent lives in Slack, he says, it can look up product context and past team decisions and use them when making choices.

Bidasaria estimates that 70–80% of his work happens through Claude Tag, with the terminal or desktop app used for some refinement or closer supervision. He says the shift is from watching transcripts and individual tool calls to expressing a goal for the model to pursue.

Shihipar reflects on how the software development cycle changed as the team built Claude Code and components that came together in Claude Tag. Those components support verification, code review, brainstorming and monitoring.

Asked how this product differs from earlier software, Bidasaria says the underlying technology once had a shelf life measured in years; AI models can change fundamentally in a matter of months. The team has to explore the frontier while providing value to people using today’s models.

Bidasaria recalls to-do lists as an example of matching a tool to a model’s abilities. Around the time of Sonnet 3.5, a model might complete only three of five requested tasks, and a list helped. About a year later, he says, more advanced memory and other capabilities made that particular list less necessary.

Boyce says engineers must be willing to discard features that compensate for current model failures as models improve. At the same time, larger and harder tasks create new needs: the tools must help a model stay coherent and perform well over a broader scope.

Shihipar says the Claude Code team has to track model progress closely and sometimes make large changes quickly, such as creating a proactive agent while also reworking permissions or artifacts. He thinks most products do not have such a short technology shelf life, although engineers generally still need a mental model of changing capabilities.

Asked about the AskUserQuestion tool, Shihipar says he wanted Claude to be interactive. He initially placed questions after planning, then made asking a tool the model could call. Getting it to use the tool well was difficult at first, but the model improved; more recently he has sometimes used an HTML artifact with questions, diagrams and mockups instead.

Bidasaria traces loops back to agents running locally on his laptop. Closing it to leave the office also stopped the work. Remote development boxes let agents continue without the laptop, but reconnecting to those environments added friction.

Hosted containers in Claude Code on the web made background work easier to reach, though setting up access to a development environment remained a challenge. Bidasaria says it was worthwhile for his productivity. Cloud execution also enabled recurring routines, such as collecting daily feedback, ranking it and fixing issues the agent has high confidence it can address.

The team describes this as moving beyond a single prompted session: a person sets an instruction at a higher level, and recurring work can continue to find or fix issues.

Shihipar asks how code review has changed as more code is generated. Boyce says Claude can help reviewers decide where to spend their attention. Instead of leaving small comments merely to show a person read a change, reviewers can have Claude find and address minor issues.

Boyce says people can then focus on the larger picture, such as why an API or service boundary was designed a particular way. The model may not have internalized that context when writing a change, so bringing it into review and handing relevant information to a person is valuable.

Shihipar says code review was an early use of a broad parallel search for bugs followed by consolidation of results. The extra computation at the time of the task helped inspire workflows.

Bidasaria describes a workflow that sends multiple agents out to find possible bugs, then examines each finding from several perspectives to challenge whether it is real. The goal is to filter the results and surface the important issues requiring human attention. He says similar approaches can be used for performance problems or research.

As an example, the team considers planning a trip: several searches can collect candidate places, other agents can sort and verify them, and a final step can summarize the result. Bidasaria says the challenge after a broad search is filtering the volume of information back down for a person to use.

Boyce values the mix of deterministic code and model reasoning in these workflows. If Claude writes a loop over a set of items, he says, the code gives him confidence that the same method will be applied to each item rather than one being skipped.

Asked about building Claude Tag, Boyce says the team uses Claude Tag itself heavily. His focus is making the development environment and feedback loop usable by Claude, so it can build the software and test the integrated result end to end. That becomes harder as the product grows more complex.

Boyce says the Slack interface is more separated from the underlying transcript than before. Claude chooses when to send a message through a tool; the full transcript is available through a link, but its internal steps are not the primary interface. Although he initially found this uncomfortable, he says receiving useful results without monitoring every step has changed his confidence in the models.

Shihipar describes developing a new tool through Claude Tag. He first asked who might be interested, then had it create mockups and implement the tool in Slack. After deploying internally and adding usage events, he used Claude Tag to monitor usage and alert him to feedback.

When he noticed users were not completing the intended flow, Shihipar first considered asking Claude to implement his own idea. Instead he asked it to propose ways to improve the funnel, using his idea as an example. He says working at that higher level made the approach click for him.

The team connects that process to verification, code review and feedback from event data, Slack or issue trackers. Shihipar says that when Claude creates a change for Claude Code, it tests the change and sends screenshots. One colleague also asks it to record itself using the terminal interface, then tries the result personally as a sanity check.

Looking back over the year, the team says additions such as automatic permissions, memory and workflows created more for developers to keep track of. Shihipar thinks the continuing challenge is to step back, reconsider what is possible and decide what else can be automated.

Asked what he misses about earlier software engineering, Bidasaria says he enjoyed performance engineering and digging deeply into systems. He thinks Claude is now better at that work than he is, while he still benefits from the performance gains. His attention has moved toward generating ideas and getting from idea to prototype and production faster.

Boyce also enjoyed detailed design work. He recalls spending a day recreating old macOS Aqua buttons in CSS with layered gradients; now, he says, he would let Claude do it. As a child he used PowerPoint to make an interactive game before he knew how to code, and he sees a similar expansion in what he can attempt today.

Boyce says he can start with an outcome, break it down and work with Claude even when he lacks a particular technical skill. The team closes by describing software engineering as a profession of change: the tools and problems evolve, but the work remains problem solving.