The father of Claude Code: "Taste" is not humanity's moat; when engineers no longer write code, what should recruitment focus on?

Many people say that in the AI era, taste is the last moat for humans. But Boris Cherny doesn't think so.

He is a technical member of Anthropic and one of the core builders of Claude Code. He uses models to write code every day and also uses models to study models. And the trend he sees is that the so - called "taste" is also being quickly learned by models.

If models can even master "what to do", what's left for humans?

In a recent interview, Boris talked about this topic.

Video link: https://www.youtube.com/watch?v=RkQQ7WEor7w&t=1s

Meanwhile, he also shared his views on some other key issues, such as:

How does Claude Code fundamentally change the company's system?

After models can write most of the code, is it still worth hiring engineers? If so, what should be considered?

Why are many people within Anthropic Members of Technical Staff without clear job grades and divisions?

Why is the counter - intuitive advice for all entrepreneurs to "hire fewer people and give more tokens"?

...

On the surface, these questions are about the birth and iteration of a product, but the answers at each level point to the same more fundamental change: the way organizations operate is being redefined by the models themselves.

And the answers given by Boris are really worth a calm thought.

How was Claude Code born?

When the host asked Boris about the origin of Claude Code, his answer was a bit unexpected.

In his account, Claude Code was not the core product that Anthropic planned from the start. To some extent, it was even an accidental product.

At the end of 2024, Boris joined Anthropic's Labs Team. The responsibility of this team is not to maintain existing products but to explore future product forms. On the one hand, they need to continuously push the boundaries of model capabilities; on the other hand, they are also looking for new products that can truly unleash these capabilities.

At that time, the team had a very strong feeling: the models already had capabilities far beyond existing products, but there was no product in the market that could fully utilize these capabilities. This was especially true in the field of programming.

Most AI programming tools on the market at that time were still in two directions. One direction was auto - completion, which helped developers complete the next line of code; the other direction was a Q&A assistant, where developers could ask about the meaning of a certain piece of code or the solution to an error. But Boris thought that there was no real Coding Agent at that time.

So the team decided to make a more radical attempt: instead of using the model as an auxiliary tool, they directly made it the development subject. They wanted to see what would happen if they built a programming product completely centered around an Agent from scratch.

However, Boris also frankly admitted that the initial Claude Code was not very useful.

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. The Claude Code people see today is completely different from the product at that time.

Why does Anthropic attach so much importance to Coding?

Many people may think that the reason why Anthropic attaches importance to Coding is simple - the programming market is large enough and has high commercial value. But Boris's explanation is completely different.

He said that if you randomly stop an employee in Anthropic's office and ask him why he came here, the answer you're likely to get is the same: AI Safety.

In Boris's view, since its establishment, Anthropic's core mission has always been AI safety. Whether it's interpretability research, alignment research, or other safety - related directions, they are essentially trying to understand the behavior of models. But all these studies ultimately face the same problem: it's not enough to just observe models in the laboratory. Researchers also have to observe what happens when models enter the real world.

And Coding happens to be an almost ideal experimental field.

Different from writing, painting, or other open - ended tasks, programming has an extremely clear feedback mechanism. Whether the code can run, whether the program can pass the test, and whether the compilation can succeed or fail, the answers are often very clear. At the same time, the Internet provides a large amount of code as training data. Compared with tasks like poetry creation, which may have countless excellent answers, the solution space for programming problems is much more convergent, so it's easier to verify model capabilities.

For this reason, Anthropic has paid high attention to Coding, Tool Use, and Computer Use from an early stage. These directions not only have commercial value, but more importantly, they 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 narrative, it is also an important experimental platform for Anthropic to understand future AI systems.

Why did Claude Code suddenly become more powerful?

After introducing the origin of Claude Code, the host asked a question that many people want to know. Since Claude Code could only complete about 10% to 20% of Boris's work when it was first born, what exactly happened later? After all, Boris has publicly stated that he hasn't written code by hand for half a year. There was obviously a huge change from being able to complete only a small part of the tasks to almost completely taking over the development work.

For this question, Boris's answer was surprisingly simple. He said that the outside world often focuses on product features, but if he were to look back at the moments that really brought about a leap in capabilities, the most important reason was actually only one: the model became more powerful.

In the past year, the Anthropic team has indeed continuously improved Claude Code itself. They have done a lot of engineering work, adding various new interaction methods and product forms. Initially, Claude Code was just a command - line tool, and later it gradually expanded to desktop, mobile, Slack, GitHub, and other scenarios. The team also constantly tried new functions, such as the Plan Mode and other mechanisms to help developers collaborate with the Agent. But in Boris's view, these are all incremental improvements.

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

He mentioned several key nodes. From Sonnet 4, Opus 4, to Opus 4.5 later, every time the model's capabilities were improved, it was directly reflected in Claude Code's performance.

The host then asked whether the experience of using Claude Code would in turn affect model research and development. Boris's answer was that almost everyone within Anthropic uses Claude Code every day, including those who research and develop models, those who develop products... The whole company uses it.

So there is no dedicated feedback channel. Feedback itself is part of the company's daily work.

When researchers find problems during use, the model team will see these problems; after the model's capabilities are improved, everyone will immediately feel the changes in actual work. The product and the model are not two parallel lines but co - evolve in the same cycle.

How much productivity improvement has Claude Code brought to Anthropic?

Boris said that after working in an AI laboratory for a long time, people get used to thinking in terms of exponential growth. Many internal indicators - whether it's revenue, usage, or model capabilities - seem more like exponential curves, so they even get used to using logarithmic coordinates to observe changes.

And the code output also shows a similar trend.

According to the data once publicly disclosed by Anthropic, since Claude Code has been widely used within the company, the amount of code output by each engineer has increased by about three times. But Boris specifically emphasized that this is outdated data. The actual growth far exceeds this figure.

What's more interesting is that this growth occurred during the rapid expansion of the company's scale.

According to traditional experience, the more engineers a company has, the lower the average productivity tends to be. Newcomers need to learn the system, and old employees need to answer questions, so the organizational communication cost will keep rising.

But what Boris observed was the opposite. In the past, it might take a new engineer several weeks to really get familiar with the internal system. Now this process often only takes two days.

The reason is not that the training system has undergone a revolutionary change, but that people are already used to asking Claude directly. Newcomers don't need to know how to query the database. They don't even need to know who to ask. Inside Anthropic, when someone asks "how to query the database", the answer they often get is: "Open Claude and let Claude query the database." A lot of implicit knowledge that originally needed to be mastered by senior engineers is starting to be transferred to the Agent. In Boris's view, this may be the most important change.

Claude Code doesn't just improve the code generation speed. It's gradually reducing the cost of knowledge transfer within the organization. In the past, enterprises relied on a hierarchical mentoring system to complete knowledge flow. Now, more and more knowledge is being directly encapsulated into the model.

From punch cards to Vibe Coding,

Humans are just raising the abstraction level of programming again

Since Claude Code is so powerful, do the newly recruited engineers at Anthropic still write code? When the host asked this question, the focus of the discussion shifted to: How do you define "writing code"?

In Boris's view, the development history of software engineering is essentially a history of continuously raising the abstraction level.

His grandfather programmed using punch cards in the Soviet era. At that time, programmers needed to punch holes in paper cards and then feed the cards into the computer to wait for the results. Later, assembly language appeared. Then Fortran and Cobol came out. After that, Java, Python, and JavaScript emerged. Every time the abstraction level was raised, some people would think: This is no longer real programming. People who write assembly language look down on those who write high - level languages, and those who write C think Python is too simple. And Boris believes that what's happening today is essentially no different. Humans are just raising the abstraction level of programming again.

He described the change in his work process over the past year. At first, like most developers, he opened the IDE, wrote code, and occasionally used auto - completion. This was the traditional software development method.

After Claude Code appeared, his work method became: describing requirements to Claude, letting Claude write code, and he was responsible for checking and correcting. At this stage, people were still directly instructing the model. It's just that the code was generated by the model. But Boris thought this was just a transitional stage.

The really interesting change happened recently. He said: Now I don't even directly prompt Claude anymore. His work has taken on another form. He writes various automatically running processes and loops. These loops are responsible for asking questions to Claude, breaking down tasks, managing the context, and coordinating the work among multiple Claude instances.

In other words: In the past, people gave instructions to Claude. Now, programs give instructions to Claude on his behalf. And his work has become designing these automatically running systems. He summarized it in a very concise way: My work has become writing Loops.

It seems that Boris is not just outsourcing code to Claude, but also automating the process of "communicating with Claude" itself. This is no longer the familiar Copilot mode. It's closer to a system with multiple Agents running continuously.

Boris mentioned that in November last year, he even uninstalled his IDE. The reason was not a symbolic gesture, but because he found that he hadn't opened the IDE for a month. Since he didn't use it at all, he naturally uninstalled it. During that time, he usually ran five to ten Claude instances simultaneously, with different Claudes responsible for different tasks, and he was mainly responsible for supervising the whole process.

Engineers don't write code anymore

What to look for in recruitment?

At this time, the host asked a very interesting question: If an engineer wants to join Anthropic today, how will Anthropic evaluate him? Or rather: In a world where people write less code by hand, what kind of people is the company looking for?

Boris's answer almost directly led to the subsequent discussion about the organizational form. He said that the type of people the Claude Code team likes the most is: Generalist.

The reason is simple: In the past, software organizations had very clear divisions of labor - user researchers were responsible for understanding users, designers were responsible for designing products, product managers were responsible for planning requirements, and engineers were responsible for implementing functions. Everyone worked in their own section, like an assembly line.

But the Claude Code team has found in the past six months that this division of labor is quickly breaking down. Every engineer in the team is doing all kinds of things that originally didn't belong to the "engineer" scope of responsibility almost every day. Some directly communicate with users, some design interactions, some pull data, do data analysis, and build dashboards. No one only does a narrow task.

Boris even gave a more extreme example: Anthropic's designers are also writing code, and finance colleagues are also writing code. Satya Nadella calls this kind of role a "Builder". This term may be more accurate than "engineer" because the real boundary is not "whether you can write code" but "whether you can turn an idea into reality".

From Boris's perspective, AI doesn't simply replace programmers. What it really changes is the relationship between knowledge and execution. In the past, the reason why a person couldn't take on multiple roles at the same time was largely because the learning cost was too high. Now, the models are constantly reducing the migration cost between these capabilities. Therefore, the people with the most advantages in the future may not be the deepest experts in a certain field, but those who can quickly cross different fields and continuously integrate resources.

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

Member of Technical Staff is not a gimmick,

It's a preview of the future

The host shifted the topic from the product to culture and organizational design. He noticed that Boris's title is not "Product Director" or "Engineering Director", but Member of Technical Staff, and many people in Anthropic have this title. He wanted to know: What are the advantages? Are there any disadvantages?

Boris was very honest. He said the worst thing is that when you send a message to someone on Slack and their title is MTS, you have no idea whether this person is a designer, an engineer, or a manager, and you don't know what project they're working on. But he really likes this title.

He recalled his experience at Meta. All software engineers at Meta have only one title: Software Engineer, without senior or principal levels. At first, he didn't quite understand it, but later he found that it was actually a cultural design. If you give someone a "senior" title, others may be too polite to refute their bad ideas. But putting everyone in an apparently equal field will force people to compete with their ideas rather than their seniority.

Of course, he admitted that the hierarchy doesn't really disappear just because the title is gone. You know someone is at L7, it's just not written in the title. But interestingly, many times you really don't know.

He told a story about when he was an L4 engineer at Facebook. He had an idea and directly went to the VP in charge of connectivity and said: This is my idea, let's do it together. That VP had no idea what his level was. He then went to another VP and failed again. The third time, it worked. They formed a team and started working on the product.

Boris said that now he sees the same thing every day in the Claude Code team. Senior engineers with 20 or 30 years of experience have to spend several months "unlearning" - forgetting the old habits that are no longer applicable. And a newly graduated college student joining the team can even teach him how to use Claude Code better because young people naturally think in terms of models.

Every time a new model comes out, everyone has to recalibrate. Experience in this era is not linearly cumulative. Sometimes it's even a liability.

So in Boris's view, the seemingly vague title of Member of Technical Staff is a preview of an upcoming reality: the boundaries between engineers, PMs, designers, and user researchers will basically disappear by the end of the year. Instead of passively accepting this change, it's better to actively push everyone into the same role through the title: Builder.

Advice for all founders:

Hire fewer people, distribute more tokens

The host asked Boris to give a more general 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 sentence was a bit of a joke: "Give everyone as many tokens as possible." Just like Huang Renxun's famous words: "The more you buy, the more you save."

This is not a joke. He was serious. The specific advice he gave was two things: