Claude Code began as a small terminal prototype and gained internal traction after file tools made local repositories easy for Claude to inspect and edit.
2
Siddharth Bidasaria argues that coding products should keep their harnesses lean because model improvements can make carefully built features unnecessary.
3
Verification remains difficult outside areas with strong feedback signals, so comprehensive unit testing is currently the most practical way to increase trust in generated code.
Summary
Siddharth Bidasaria describes Claude Code's path from a terminal experiment inside Anthropic's labs team to a product that quickly attracted internal and external users. The addition of local file-reading and file-writing tools made the system feel low friction because developers could use their existing repositories without synchronization or setup. He explains why the team deletes tools and features when the model can handle the same work through a simpler abstraction, such as Bash. The conversation then moves through model improvements, verification, hooks, and subagents. Bidasaria says verification has two parts: the model must know when to check its work, and it needs tools that provide useful feedback. He sees unit tests as the most practical current route for coding agents. He is excited by multi-agent systems, while remaining uncertain whether complex agent topologies improve results. He also describes dynamic permissions and observability as unresolved problems when many agents act in parallel.
Claude Code started as a terminal prototype inside Anthropic's labs team
Siddharth Bidasaria says Anthropic's labs team was created to prototype products and see what worked. His colleague Boris built a small terminal program that called Anthropic's API. It initially had no coding ability or tools, then gained Spotify control and file-reading and file-writing tools. The file tools changed Siddharth's reaction because Claude could work directly with a user's local repository. The team hacked on it for a few weeks, released it internally, and reached about 300 daily active users when Anthropic had roughly 600 employees. After a small external early-access program, users became attached to it and the product spread on social media.
Local files made coding assistance easier to start and easier to continue
Siddharth says earlier products often required users to synchronize files, copy a repository to a virtual machine, build a Docker image, or grant access to a Git repository. Those setups also made collaboration awkward because a developer had to retrieve the agent's work before editing it. Claude Code could start wherever the files already existed. A user could ask it to read files and explore the repository in a way that felt closer to how a human developer works. Siddharth describes this as a low-friction experience that felt different from web applications and other coding surfaces.
The team uses task lists to keep models working through longer jobs
Siddharth names the to-do list as his favorite feature. He says it gives the model a way to stay on track during longer tasks. For example, when asked to rename 100 files, the model previously might handle 30 and stop. With a to-do list, it can break the work into batches of 10 and check them off as it proceeds. The result is still not fully deterministic, but it is more predictable than before. Demetrios Brinkmann compares the experience to watching a deep-cleaning video because the user can watch work happen without doing the repetitive task themselves.
New model releases can invalidate a developer's assumptions about what is possible
Bidasaria says Claude 3.5 was capable, while Claude 3.7 brought a noticeable change in the complexity of tasks it could handle and the way it moved through complicated structures. Because he uses models throughout the day, small changes in behavior stand out to him. He says developers build an intuition about which tasks an agent can handle and which require close human involvement. A stronger model can overturn that intuition, forcing users to update their expectations. He also discusses the idea of keeping a model on distribution, allowing it to follow patterns it naturally handles well instead of forcing it into a human's preferred method.
Claude Code tries to delete harness code when the model can use a simpler tool
Bidasaria says the team likes deleting code and features because model behavior changes quickly. Early Claude Code versions included separate tools for listing files and other file-system operations. The team removed them after seeing that the model could perform those tasks through Bash, an abstraction it understood better than custom tools. He describes the product harness as a way to give the model useful capabilities, rather than a system that heavily directs every step. The team still has to balance present usefulness with future flexibility, so experiments should be easy to remove when a new model makes them redundant.
Verification requires both model self-checking and tools that expose mistakes
Bidasaria breaks verification into two problems. The model must learn to check its work and correct course when it is going wrong. It also needs tools that let it inspect the result. For web development, a Puppeteer MCP server can open a browser, take a screenshot, and return it to the model, giving feedback about elements such as button positions or colors. Animations, interactive behavior, and low-level performance work are harder because screenshots do not capture every relevant outcome. Bidasaria calls unit tests the most practical route for covering a broad coding surface and making generated code easier to trust.
Power users are inventing multi-agent workflows that shaped subagents
Bidasaria describes one user running 10 to 12 Claude instances on a single problem. The user used the file system for communication, assigned different personas such as backend engineer and frontend engineer, and gave each instance a separate folder. He says this setup strongly influenced Claude Code's subagent feature. He is interested in designs where several agents work independently without a parent agent, but questions remain about message buses, direct communication, timing, shared writes, and read-only access. He is hesitant to add complex topologies without evidence that they improve results, since the complexity also makes the product harder for users to understand.
Many-agent systems make observability and permissions difficult to manage
Bidasaria says parallel subagents can ask for permission whenever they encounter a tool they cannot use. That works for the current, relatively simple implementation, but it would not scale to complicated agent topologies. Developers would need to know what agents can observe, which permissions they hold, and whether permissions should be passed to other agents. Demetrios Brinkmann points out that permissions may need to expire rather than remain active forever. Bidasaria expects better models to help interpret user intent and provide dynamic permissions. He also warns that application scaffolding cannot become too complex, because a system that solves today's problem may be difficult to remove after a model improves.
