Ultimately, what we want to teach the model is the same thing we teach children.

Article author and source: MachineHeart

Many say that in the age of AI, taste is humanity’s last moat. But Boris Cherny doesn’t agree.

He is a technical member of Anthropic and one of the core builders of Claude Code. He writes code with models every day and uses models to study models themselves. The trend he has observed is that so-called "taste" is also being rapidly learned by models.

If even "what to do" can be mastered by a model, what remains for humans?

In a recent interview, Boris discussed this topic.

How Claude Code fundamentally transforms company systems;

When models can write most of the code, is it still worthwhile to hire engineers? If so, what should be considered?

Why do many people at Anthropic hold the title of Member of Technical Staff, without clear levels or divisions of responsibility?

An counterintuitive piece of advice for all entrepreneurs: Why “hire fewer people, give more tokens”?

……

These questions may appear to be about the creation and iteration of a product, but each layer of answers points to the same more fundamental shift: the way organizations operate is being redefined by the models themselves.

Boris's answer is well worth thoughtful consideration.

How was Claude Code created?

When the host asked about the origin of Boris Claude Code, his answer was somewhat surprising.

In his account, Claude Code was not originally planned as a core product by Anthropic; in fact, it could be described as an accidental outcome.

At the end of 2024, Boris joined Anthropic’s Labs team. This team’s mandate is not to maintain existing products, but to explore future product forms. On one hand, they continuously push the boundaries of model capabilities; on the other, they seek new products that can truly unlock these capabilities.

At the time, the team had a strong sense that the model had far surpassed the capabilities of existing products, yet no product on the market was able to fully leverage these capabilities—especially in the field of programming.

At that time, AI programming tools on the market were mostly limited to two directions: one was code autocompletion, helping developers finish the next line of code; the other was a Q&A assistant, allowing developers to ask about the meaning of a piece of code or solutions to specific errors. But Boris believed that no true Coding Agent had yet existed.

The team decided to make a more ambitious attempt: instead of treating the model as an auxiliary tool, they aimed to make it the core of development itself. They wanted to see what would happen if they built a programming product from scratch, entirely centered around agents.

However, Boris also frankly admitted that the initial version of Claude Code was not user-friendly.

For a long time, it could only complete about 10% to 20% of his work; most of the code still needed to be written by him personally. The Claude Code seen today is entirely different from the product of that era.

Why does Anthropic place such strong emphasis on coding?

Many people assume Anthropic values coding simply because the programming market is large and commercially valuable. But Boris’s explanation is entirely different.

He said that if you randomly stopped an employee at Anthropic’s office and asked them why they came here, the most likely answer would be the same: AI Safety.

In Boris’s view, Anthropic’s core mission since its founding has always been AI safety. Whether through interpretability research, alignment research, or other various safety directions, the goal is fundamentally to understand model behavior. But all these studies ultimately face the same challenge: observing models in the lab is not enough—researchers must also observe what happens when models enter the real world.

And coding happens to be an almost ideal testing ground.

Unlike writing, painting, or other open-ended tasks, programming has an extremely clear feedback mechanism: code either runs or it doesn’t, a program either passes tests or it fails, and compilation either succeeds or fails—the answers are often very clear. Meanwhile, the internet provides vast amounts of code as training data. Compared to tasks like poetry creation, which may have countless valid solutions, the space of correct solutions in programming is much more constrained, making it easier to verify a model’s capabilities.

For this reason, Anthropic has placed strong emphasis on Coding, Tool Use, and Computer Use from an early stage. These areas not only hold commercial value but, more importantly, provide a natural experimental environment for studying how models interact with the real world.

From this perspective, Claude Code is never just a productivity tool for programmers. In Boris’s account, it is also an important experimental platform for Anthropic to understand future AI systems.

Why did Claude Code suddenly become stronger?

After introducing the origins of Claude Code, the host posed a question many people want to know: Since Claude Code initially could only accomplish about 10% to 20% of Boris’s work, what exactly happened afterward? After all, Boris has now publicly stated that he hasn’t written a single line of code in six months. The transformation from handling only a small portion of tasks to nearly taking over all development work clearly involved tremendous changes.

Boris’s response to this question was surprisingly simple. He said that outsiders often focus on product features, but if he were to reflect on the moments that truly led to leaps in capability, the single most important reason was that the models became stronger.

Over the past year, the Anthropic team has consistently improved Claude Code itself. They have undertaken extensive engineering efforts to introduce various new interaction methods and product forms. Initially, Claude Code was only a command-line tool, but it has since expanded to desktop, mobile, Slack, GitHub, and other environments. The team has also continuously experimented with new features, such as Plan Mode and other mechanisms designed to help developers collaborate with agents. However, in Boris’s view, all of these represent incremental improvements.

What truly determines the upper limit of Claude Code is the underlying model itself.

He mentioned several key milestones—from Sonnet 4 and Opus 4 to the later Opus 4.5—each improvement in model capability directly enhanced Claude Code's performance.

The host then asked whether the experience of using Claude Code would, in turn, influence model development. Boris replied that nearly everyone at Anthropic uses Claude Code daily, including those developing the models, those building the products—everyone in the company uses it.

Therefore, there is no dedicated feedback channel. Feedback is inherently part of the company’s daily operations.

When researchers encounter issues during use, the model team immediately sees them; once the model’s capabilities improve, everyone quickly notices the changes in their actual work. Product and model are not two parallel lines—they evolve together within the same cycle.

How much productivity gain has Claude Code brought to Anthropic?

Boris says that after working in an AI lab for a while, people get used to thinking in terms of exponential growth. Many internal metrics—whether revenue, usage, or model capability—appear more like exponential curves, so they even become accustomed to using logarithmic scales to observe changes.

The code output has also shown a similar trend.

According to data previously disclosed by Anthropic, since Claude Code was widely adopted within the company, each engineer’s code output has increased by approximately three times. However, Boris specifically emphasized that this data is outdated—the actual increase far exceeds this figure.

More interestingly, this growth occurred amid the company’s rapid expansion.

According to traditional experience, the more engineers a company has, the lower its average productivity tends to be. New hires need time to learn the system, while experienced employees spend time answering questions, causing organizational communication costs to continually rise.

But Boris observed the opposite: previously, it might take a new engineer several weeks to become truly familiar with internal systems; now, this process often takes just two days.

The reason isn't that the training system has undergone a revolutionary change, but rather that people have become accustomed to asking Claude directly. New hires don’t need to know how to query a database—they don’t even need to know who to ask. Inside Anthropic, when someone asks, “How do I query the database?”, the common response is: “Open Claude and have Claude check the database.” Much of the tacit knowledge that once required senior engineers to master is now being transferred to agents. In Boris’s view, this may be the most significant change of all.

Claude Code doesn't just improve code generation speed—it's gradually reducing the cost of knowledge transfer within organizations. In the past, companies relied on hierarchical mentorship to move knowledge. Now, more and more knowledge is being directly encapsulated into models.

From punched tape to Vibe Coding, humans have simply raised the level of abstraction in programming once again.

Since Claude Code is so powerful, do the new engineers hired by Anthropic still write code? When the host posed this question, the discussion immediately shifted to: How do you define “writing code”?

In Boris’s view, the history of software engineering is essentially a history of continuously raising levels of abstraction.

His grandfather programmed using punch cards during the Soviet era, when programmers had to punch holes in paper cards and feed them into computers to wait for results. Later, assembly language emerged, followed by Fortran and COBOL, then Java, Python, and JavaScript. With each rise in abstraction level, some people claimed it wasn’t “real” programming anymore—those who wrote assembly looked down on those who used high-level languages, and C programmers thought Python was too simple. But Boris believes what’s happening today is essentially no different: humans are simply raising the level of abstraction in programming once again.

He described the evolution of his work over the past year. At first, he was like most developers: opening an IDE, writing code, and occasionally using autocomplete—this was the traditional approach to software development.

After Claude Code emerged, his workflow changed to: describing requirements to Claude, letting Claude write the code, and then personally reviewing and correcting it. At this stage, humans still directly instruct the model—only the code is generated by the model. However, Boris believes this is merely a transitional phase.

The most interesting changes have occurred recently. He says: Now I don’t even directly prompt Claude anymore. His role has transformed into something else—he writes various automated workflows and loops that handle asking Claude questions, breaking down tasks, managing context, and coordinating work across multiple Claude instances.

In other words: previously, humans gave instructions to Claude. Now, programs give those instructions on his behalf. His role has shifted to designing these automated systems. He summarizes it succinctly: My job has become writing loops.

It seems that Boris isn't just outsourcing code to Claude—he's automating the very process of communicating with Claude. This is no longer the familiar Copilot model; it's much closer to a system of multiple agents running continuously.

Boris mentioned that in November last year, he even uninstalled his IDE. It wasn’t a symbolic gesture—he simply realized he hadn’t opened the IDE in a month. Since he wasn’t using it at all, he uninstalled it. During that time, he typically ran five to ten Claude instances simultaneously, with different instances handling different tasks, while he primarily oversaw the entire process.

If engineers aren't writing code, what do hiring managers look for?

At this point, the host posed an interesting question: If an engineer wanted to join Anthropic today, how would Anthropic evaluate them? Or put another way: In a world where fewer people are writing code by hand, what kind of people are companies really looking for?

Boris’s response almost directly led into the subsequent discussion about organizational structure. He said that the Claude Code team’s favorite type of person is actually the generalist.

The reason is simple: past software organizations had very clear divisions of labor—user researchers understood users, designers designed products, product managers planned requirements, and engineers implemented features, with everyone working in their own stage like an assembly line.

But over the past six months, the Claude Code team has found that this division of labor is rapidly breaking down. Nearly every engineer on the team is now performing a wide range of tasks that were traditionally outside the scope of an “engineer” role—some directly communicating with users, others designing interactions, and some pulling data, conducting data analysis, and building dashboards. No one is confined to just a narrow slice of work.

Boris even gave a more extreme example: Anthropic’s designers are writing code, and finance colleagues are writing code too. Satya Nadella refers to such roles as “Builders.” This term may be more accurate than “engineer,” because the real boundary is no longer “Can you write code?” but rather “Can you turn an idea into reality?”

From Boris’s perspective, AI isn’t simply replacing programmers—it’s fundamentally changing the relationship between knowledge and execution. In the past, individuals couldn’t easily take on multiple roles largely because the cost of learning was too high. Now, models are continuously reducing the cost of transferring skills between these domains. Therefore, the most advantaged people in the future may not be the deepest experts in a single field, but those who can quickly move across disciplines and continuously integrate resources.

This is why Boris believes we are entering a golden age for generalists. For those willing to do many things, this may be the best time in history.

Member of Technical Staff is not a gimmick—it's a preview of the future.

The host shifted the topic from product to culture and organizational design. He noticed that Boris’s title is not “Director of Product” or “Director of Engineering,” but rather “Member of Technical Staff,” and that many people at Anthropic hold this same title. He wanted to know: What are the benefits? Are there any drawbacks?

Boris was very candid. He said the worst part was: you message someone on Slack whose title is MTS, and you have no idea whether they’re a designer, engineer, or manager—or what project they’re even working on. But he loved the title anyway.

He recalled his experience at Meta. All software engineers at Meta had only one title: Software Engineer, with no hierarchical levels such as Senior or Principal. At first, he didn’t understand this, but later realized it was intentionally designed as part of the culture. If you give someone a “senior” title, others may hesitate to challenge their bad ideas out of deference. By placing everyone in an ostensibly equal environment, the focus shifts to competing on the merit of ideas rather than seniority.

Of course, he acknowledges that levels don't truly disappear just because the title is gone—you still know someone is an L7, even if it's not written out. But interestingly, many times you genuinely don't know.

He shared a story about when he was an L4 engineer at Facebook. He had an idea, went directly to the VP in charge of connectivity, and said, “Here’s my idea—let’s do this together.” The VP had no idea what level he was. He approached another VP and failed again. On the third attempt, he succeeded. They formed a team and started building the product.

Boris says that now, every day on the Claude Code team, he sees the same thing: senior engineers with 20 or 30 years of experience must spend months unlearning—letting go of outdated habits that no longer apply. Meanwhile, a recent college graduate joining the team can actually teach him how to use Claude Code more effectively, because young people naturally think in terms of model-based reasoning.

With every new model released, everyone must recalibrate. Experience in this era is not linearly cumulative—it can sometimes even be a liability.

So, the seemingly ambiguous title "Member of Technical Staff," in Boris’s view, is a preview of an impending reality: by year’s end, the boundaries between engineers, PMs, designers, and user researchers will largely disappear. Rather than passively accepting this change, he uses the title to proactively bring everyone into the same role: Builder.

Advice to all founders: Hire fewer people, issue more tokens.

The moderator asks Boris to offer a general piece of advice to the founders and companies present, from Anthropic’s perspective: How should organizations adjust their mindset before the end of 2026?

Boris’s first remark came with a joke: “Give everyone as many tokens as possible.” It’s like Jensen Huang’s famous line: “The more you buy, the more you save.”

This is not a joke. He is serious. His specific recommendations are two things:

First, provide as many tokens as possible to encourage everyone to experiment freely.

Second, deliberately under-staff each project. If you think a project needs four engineers, assign only two, and give them a large amount of tokens to figure it out themselves. You’ll find that they’re very likely to succeed. They’ll automate everything possible, and because it’s automated, the next time they do it, it will be faster and cheaper. This creates a compounding effect.

The host summarized the suggestion concisely: use fewer people and shift the budget from salaries to tokens. This increases your upfront cost but significantly reduces ongoing costs—similar to pre-compiling: you do the hard work once, and every subsequent execution is nearly free.

Boris fully agreed. The host then asked a more pointed question: In the past, people took great pride in their discipline—product managers took pride in the articles they wrote, and designers took pride in their exquisite portfolios. Does this mean that within 12 months, everyone must abandon their identity as “someone specific” and become merely a “flexible, token-consuming bag”?

Boris said: "I might word it slightly differently, but... yeah, pretty much like that."

Will taste also be eroded by models? In the end, only "values" remain.

The host mentioned a topic previously discussed with Jared, another member of Anthropic, and wanted to hear Boris’s perspective: How do you understand “taste”?

Boris’s answer was very candid. He said that every time he thought he had some “special taste” in programming, he was ultimately proven wrong.

He once loved functional programming and languages like Haskell and Scala. In the early codebase of Claude Code, he established a rule: no classes allowed, only functions. Engineers would secretly submit code with classes on weekends, only to have them rejected on Monday. Later, as the model began generating code at scale, it started writing classes directly. After studying it for a long time, he finally said: “Alright, maybe the model is right. My obsession may have been meaningless all along—the business results were achieved faster, and the code wasn’t any worse.”

Then he made a more bold inference. Everyone now says, "Product taste is the last alpha." But he believes this alpha is also disappearing rapidly.

He currently has hundreds of Claude instances running simultaneously. Some are scraping Twitter feedback, others are reviewing GitHub issues, and some are monitoring Slack, then autonomously analyzing what features to implement next. Most ideas are still bad—about 20% are good. But with the next model, in another 3 to 6 months, most ideas could become good.

The host pressed further: So, what unique qualities will humans ultimately retain? Is there anything that models will never be able to do?

Boris thought for a moment and said: "Values."

He said that ultimately, what we must teach the model is the same thing we teach children: how to be a good presence—how to do the right thing, not just do things right.