Compiled by: Aying

Boris Cherny, founder of Claude Code, shared at the Sequoia Conference, providing a wealth of information, many viewpoints I heard for the first time in full. This guy really has a solid understanding of AI.

I will share my own summary.

01 Code is no longer scarce

In many mainstream development scenarios, writing code by hand has started to become an inefficient task.

In the past, to deliver a feature, an engineer would sit down, think clearly about how to implement it, and then type out the code line by line. In this process, the engineer's greatest value was whether they could write, how well they wrote, and how fast they wrote.

Now, the work method is different.

For the same feature, the engineer’s task resembles more of: clearly explaining the requirements, breaking it down into pieces for the Agent, setting an acceptance criterion, and then checking if the results produced by the Agent are correct. If not, adjust the prompts and let it run again.

AI can already handle most coding tasks. Of course, it is not 100%, as there are still many huge and complex codebases, obscure languages, or special environments where current models do not perform adequately.

Overall, the value of engineers has shifted from knowing how to write code to knowing how to break down tasks, clearly articulate goals, validate results, and manage Agents.

This change is actually very similar to the industrial revolution.

Before the industrial revolution, a blacksmith did everything from forging to polishing to assembling all by themselves. A skilled blacksmith was naturally valuable.

Then assembly lines appeared. Each worker was only responsible for one process, but the overall output exceeded the handmade era by dozens or hundreds of times.

At this point, the valuable roles in the factory were no longer the craftsmen who were best at a specific process but those who could design, manage, and optimize the assembly line.

Workers did not disappear, but their roles changed.

Software engineering is now undergoing a similar transition. Code itself is no longer a scarce commodity. Knowing how to write code is becoming a foundational skill, much like knowing how to use PowerPoint.

What is truly scarce is the ability to break down vague requirements into clear tasks, to choose the best option from the solutions provided by the Agent, and to enable a group of AI to work together to accomplish a task.

Many experienced engineers initially find this hard to accept. The act of writing code by hand itself has been the reason many people loved this profession for decades.

Handing this over to machines, for many, is not just a change in working methods but a reshaping of identity recognition.

But a trend is a trend.

02 Like the Gutenberg printing press

Coding is transitioning from a specialized skill to a foundational ability. This can be compared to the invention of printing in 15th century Europe.

Before the invention of printing, only about 10% of people in Europe were literate. These individuals were often employed by illiterate nobles to read and write for them.

Then printing emerged. Within 50 years, the number of books published in Europe exceeded the total output of the previous thousand years, and book prices decreased by around 100 times. After a few hundred years of supporting systems (education system, economic structure gradually catching up), the global literacy rate finally rose to today's 70%.

Boris believes that AI’s impact on software is an accelerated version of the printing revolution. Software will democratize completely within a few decades, becoming something anyone can manage.

Ultimately, knowing how to use software will be as natural as sending a text message.

03 What skills are the most important?

When the barrier to writing code is lowered to an extremely low level by AI, the true differentiator of a person's abilities lies in their product sense and genuine understanding of a specific domain.

For example, imagine two people who need to create a product aimed at doctors. One is an engineer who writes code quickly, and the other has worked in the hospital information department for a few years.

In the past, the engineer would have a higher probability of successfully delivering the product because they could realize the idea.

Now it’s reversed. Anyone can realize an idea. At this point, the person who truly understands the daily workflows in a hospital becomes more valuable because they know which features doctors will actually use and which ones only sound reasonable.

In other words, as AI levels the execution threshold, the gap in judgment is amplified.

This directly rewrites the meaning of the term 'generalist.'

In the past, when we talked about generalists, we usually referred to engineers who could write iOS, Web, and backend code. This kind of generalist was essentially an internal full-stack engineer.

The future generalist will be a cross-disciplinary full-stack professional.

Some will understand product, design, and engineering simultaneously. Others will understand product, data science, and engineering simultaneously. Such combinations were nearly impossible in the past because each area requires long-term specialized training.

But now, with AI lowering the execution barriers of each area, a person can span several fields and still retain depth of expertise.

The Claude Code team is like this. Engineering managers, PMs, designers, data scientists, finance, user research—everyone is writing code.

Designers can run interaction prototypes themselves to show the team, no longer just creating designs for engineers to implement.

Finance can build an analysis tool themselves, running the company’s complex financial models without waiting in line for BI. User research colleagues have started running data themselves, taking over the parts of work that used to depend on the data team.

Everyone's depth of expertise remains. But with AI assistance, coding has become a shared language for everyone.

04 The moat of SaaS is crumbling

In the past few years, there have been several almost universally accepted beliefs in the SaaS industry.

The first is the switching cost. Once a company has used your system, it gradually accumulates years or even decades of data, configurations, fields, and permission relationships.

If they want to move to another system, just transferring everything as it is can be enough to make people reluctant to act.

The second is workflow lock-in. Employees’ daily operations, cross-departmental collaborations, approval nodes—all revolve around this SaaS.

Switching to another system is not just about moving data; it involves dismantling the muscle memory built up over the past few years within the whole company.

These two factors combined formed the deepest moat of the SaaS industry in the past. However, with a strong enough model, the logic of the situation begins to change.

Let's first look at the side of switching costs. In the past, wanting to switch from one SaaS to another required engineering teams to work overtime for months just to align fields and replicate the data structure.

Now, you can simply throw the interfaces and data structures from both sides to a model, allowing it to clarify the mapping relationships on its own and gradually climb toward the optimal solution. What used to take months could now produce a usable version in just a few days.

Now, looking at the workflow lock-in side, it’s even more interesting. In the past, the reason workflows could lock in customers was that these processes were complex, implicit, and depended on people.

That tacit understanding among employees about who approves what and what steps get stuck cannot be directly transferred.

But models like Opus 4.7 excel at understanding, breaking down, and rebuilding a complex process in a new environment. The version they build from scratch might even be more efficient than the original.

Therefore, the moat that was built relying on data accumulation and process accumulation is crumbling.

For those in the SaaS space, this could be bad news. But for all customers using SaaS and teams preparing to develop the next generation of SaaS, this presents a true opportunity window.

05 The best era for entrepreneurs

The startups that will truly disrupt industries in the next 10 years may be ten times more than those in the past 10 years.

The reason is not complicated.

Small teams can create products on par with or even better than large companies using AI. Conversely, large companies wanting to genuinely use AI can become negative assets.

How so?

A company with a decade-long history has developed a complete set of its own business processes, job divisions, collaboration habits, training systems, and KPI assessments. These things were assets and barriers in the past.

But embedding AI genuinely means these must be reevaluated: business processes must be re-engineered, all employees retrained, and every step forward will encounter tremendous internal resistance, requiring coordination among N departments and N layers of approval.

In contrast, a three-person startup team has treated AI as a default foundation from day one. They have no historical baggage to dismantle, no habits to change, and no one needs to be convinced. Discussing things today, they can have a demo by tomorrow and launch for users to use the day after.

This speed difference was also present before AI. Startups already had a speed advantage over large companies. But AI has multiplied this gap significantly.

Why?

The stronger AI is, the greater the leverage one person can exert in a unit of time. A small team that effectively utilizes AI today can produce results equivalent to ten people in the past, and tomorrow it might be equivalent to thirty.

Meanwhile, the organizational weight of large companies has not become lighter; on the contrary, due to the need to digest AI, it has become heavier. The stronger the AI, the larger the gap between the acceleration of small teams and the drag of large companies.

This is what Boris refers to as negative assets. It’s not that large companies lack funds, personnel, or willingness; rather, the muscle that once earned them profits is now precisely the obstacle to realizing the value of AI.

06 MCP will not die

MCP will not die.

After Skill gained popularity, many felt that MCP was no longer needed. The founder of OpenClaw shares a similar viewpoint.

But Boris disagrees. He believes MCP will become the software connection layer in the AI era.

In the past, the internet's way of connecting software was through APIs.

However, the core issue with APIs is that they are designed for engineers. To use an API, one has to read documentation, apply for a token, write code, align fields, and handle exceptions. In simple terms, APIs are written for human developers.

MCP is different. It allows models to connect directly and use them; the model can understand and adjust on its own without needing a programmer to translate.

Thus, Boris refers to APIs as Human Developer Interfaces and MCPs as Model Interface Protocols. One is for human use, and the other is for models.

This is actually very similar to the past. In the mobile internet era, it became standard for all services to be API-based. In the AI era, it will become standard for all services to be MCP-based.

07 Computer Use is still important

Many people currently discussing Computer Use may feel this direction might not work.

The reasons are quite reasonable: it consumes too many tokens, runs slowly, and is unstable. It appears more like a flashy demo, still far from practical usability.

But the perspective Boris sees is completely different.

What he truly values is that Computer Use addresses the biggest pain point in implementing AI: in the real world, there are a large number of systems that have neither APIs nor MCPs.

Especially in the corporate world.

Anyone who has been inside a company knows that many of the core systems are very old. ERP, OA, financial systems, internal approvals, supply chain backends, and various customized systems often lack open interfaces, documentation, or automation capabilities. They just exist, manually operated by countless employees every day.

So why not directly create APIs for them?

Because it’s not feasible. The vendors who developed these systems might no longer exist. The IT department lacks the motivation and budget to restructure.

The business department is even less likely to stop and wait for half a year or a year. These systems will never wait for a perfect API to save them.

In the short term, major models should still improve their Computer Use abilities.