Jeff Dean on AI's Next Phase: From TPU to Self-Evolving Agents

At YC Startup School 2026, Jeff Dean’s voice was slightly hoarse.

At the start of the interview, he explained that he had lost his voice, so his voice sounded different today than usual. But this did not distract the audience’s attention. Sitting across from him, YC partner Diana Hu swiftly listed a string of names that could each be written into computer history: MapReduce, BigTable, TensorFlow, TPU, Gemini.

Any one of these projects would be sufficient to serve as a career-defining achievement for an engineer. Yet, they are all concentrated in the resumes of Jeff Dean and a group of Google engineers around him.

Diana did not turn the interview into a retrospective of achievements. She was more interested in another question: Now that generative AI has swept through the software industry, what is Jeff Dean, the person best at rebuilding systems from the ground up, actually focusing on today?

The answer is not a larger model.

In this nearly hour-long conversation, Jeff Dean repeatedly discussed inference hardware, energy, data movement, context engineering, long-running agents, automated experimentation systems, and how startups can avoid direct competition with general-purpose models. What may seem like scattered topics actually follows a very clear underlying theme: the next phase of AI is not just about making models smarter, but about placing them within systems that can work over the long term, continuously experiment, automatically validate results, and steadily accumulate capabilities.

This also means that AI competition is shifting from “who has the larger model” to “who can better organize intelligence.”

In May 2025, Jeff Dean made a widely discussed assertion that AI capabilities have approached those of a junior engineer.

A year later, Diana asked him how the prediction had turned out.

Jeff Dean’s response was straightforward. He believes this assessment is “quite accurate.” The model’s progress in agentization, long-form coding, and complex tasks has even surpassed his initial expectations.

“He said, 'The model's ability to perform increasingly complex tasks is growing faster than I expected.'”

More notably, this capability is no longer limited to coding. An increasing number of agent systems are entering scientific, engineering, and other professional fields. They don’t just answer questions—they break down tasks, use tools, run experiments, read results, and take further actions based on feedback.

Comparing AI to a junior engineer tends to shift focus toward human replacement. But Jeff Dean is more interested in another layer of change: what happens to the way production is organized when a “junior engineer” can be duplicated dozens or hundreds of times, working in parallel for days or even weeks?

In a traditional team, junior engineers need to get up to speed on the business, understand the tools, and continuously receive feedback. The same is true for agents—except that their training materials are no longer just documentation, but include prompts, tool descriptions, skill files, testing frameworks, evaluators, and the entire contextual environment.

This has created a new division of labor in AI engineering.

In the past, engineers primarily focused on writing code. In the future, more engineers will be responsible for defining problems, setting up environments, writing specifications, designing feedback loops, and then coordinating a team of agents to accomplish tasks.

Jeff Dean’s prediction for 2027 is exactly this: he believes machine learning systems will increasingly participate in improving themselves. They will break down goals into subproblems, automatically run numerous experiments, compare results, and combine effective solutions to create stronger new systems.

Wherever there is a measurable goal, there is an opportunity for significant progress.

This sentence is the key to the entire interview.

The areas where AI automation first made inroads aren't necessarily the ones with the most knowledge, but those with the clearest feedback. Whether code passes tests, whether chip layouts reduce area, whether model architectures improve accuracy, or whether material properties meet requirements—all these questions have relatively clear evaluation criteria. As long as the evaluator is sufficiently reliable, machines can perform high-frequency iterative trials.

Therefore, in the AI era, the truly important unit may no longer be a single response, but a complete闭环: proposing a solution, executing it, measuring the results, and adjusting the direction.

Many of Jeff Dean's representative works originated from a very simple starting point: first, get the order of magnitude right.

In 2001, Google's search still relied heavily on hard drives, which offered large capacity but slow access speeds. Jeff Dean and Sanjay Ghemawat made an estimate and found that Google’s entire search index at the time could fit into the memory of all its servers combined.

Today, it sounds like just a storage medium upgrade. But at the time, it meant an entirely different system design.

If the index primarily resides on disk, queries must wait for mechanical seek times. Simply moving the index into memory drastically reduces access latency. The two quickly wrote a new version and deployed it to production within days, making Google Search noticeably faster.

This story is easiest to frame as a stroke of genius. But Jeff Dean’s account sounds more like an engineer stating the obvious: when system conditions change, a solution that previously didn’t work may now be viable—so it’s time to recalculate.

Many industry innovations occur during moments like these.

An old problem has persisted for so long that people have become accustomed to patching around it. Eventually, hardware costs, memory capacity, network bandwidth, or model capabilities cross a critical threshold, and the original constraint disappears. Yet most people still use the old architecture because it has become common knowledge.

What Jeff Dean excels at is turning common sense back into assumptions.

He will ask: Why must it be this way? Is today's scale the same as yesterday's? If we replace the most expensive step, would the entire system take on a completely different form?

This is also his advice to entrepreneurs: Don’t just focus on where existing solutions fall short—reexamine the problem from first principles. Can you improve performance by an order of magnitude? Can you reduce costs by two orders of magnitude? Can you stop following the industry’s default approach?

Sometimes, you just need to squint at a problem—don’t get anchored by today’s solutions; instead, think from first principles about how it should be solved.

This doesn't sound mysterious. The real challenge is that most people, after entering an industry, quickly learn all the default answers within that field. Experience improves efficiency but can also cause people to lose the ability to ask questions again.

In 2013, Google’s deep learning speech recognition began to significantly surpass older systems, halving the error rate and achieving in months what had taken the past two decades of progress in speech recognition.

The product team was naturally excited. But Jeff Dean first ran the numbers.

If speech recognition truly improves, users will be more willing to use it. Assuming each Google user uses speech recognition for just three minutes per day, how many servers would Google need to support it?

The results were not promising. At the efficiency of CPUs at the time, Google might have needed to double its server scale.

This is where TPU begins.

It wasn’t because the research team suddenly wanted to build chips, nor was it to prove that Google could make hardware—it was because a successful model was about to create a service cost that was unsustainable.

This history reveals a frequently overlooked pattern in AI products: improved model performance does not always reduce costs. On the contrary, better performance leads to greater usage and increased system strain.

When speech recognition doesn't work well, users rarely invoke it. System costs are not an issue. Once the error rate drops significantly, demand is suddenly unleashed, and the previously hidden computational constraints in the background come to the forefront.

The TPU was designed with specialized hardware for the most core computational patterns in machine learning. It does not need to run browsers or handle all general-purpose programs. It excels primarily in low-precision, dense linear algebra—computations that lie at the heart of modern machine learning.

The first-generation TPU delivered orders-of-magnitude improvements. According to Jeff Dean, it was 30 to 80 times more energy-efficient and 20 to 30 times lower in latency compared to CPUs and GPUs at the time.

There is another design consideration that is easily overlooked.

TPUs are highly specialized, but not so specialized that they can only run a single fixed model. Recognizing that machine learning algorithms would continue to evolve rapidly, the team designed the chip as a more general-purpose linear algebra system. It sacrifices the ability to run Chrome or Word, but retains the flexibility to support future algorithmic advancements.

It’s a difficult balance to strike. If you don’t specialize enough, your returns won’t be significant. If you specialize too much, a change in the algorithm can render your hardware obsolete.

Jeff Dean’s assessment of today’s inference hardware strongly echoes his earlier views on TPU. He believes the next major opportunity still lies in specialization, but the focus will further shift toward low-latency, low-power inference.

Imagine what you could do if latency improved by 50 times.

When a model takes十几 seconds to respond, people treat it as an occasional tool. Only when the delay approaches instantaneity can it truly integrate into interactive interfaces, bots, live video, operating systems, and continuous decision-making workflows.

Waiting is not a minor user experience issue. Waiting changes the product's form.

If updating "Latency Numbers Every Engineer Should Know" for AI engineers in 2026, Jeff Dean believes the focus should shift from disk seek times, cache misses, and intercontinental network latency to data flows within chips.

Engineers need to know: What is the bandwidth from main memory to on-chip memory? What is the bandwidth from on-chip memory to the multiplication unit? How much energy does one multiplication require? How are chips interconnected? And how does network efficiency degrade when scaling from 500 chips to 10,000 chips?

These numbers may seem far removed from the product, but they actually determine what products can succeed.

Jeff Dean presented a striking ratio: performing a single mathematical multiplication requires only about a picojoule of energy, whereas moving data from high-bandwidth memory to the computational unit may cost roughly 1,000 times more energy.

In other words, the costly operations in today’s AI systems are often not the computations themselves, but rather moving the data that needs to be computed.

This also explains why batching is so important.

Once a set of model weights is loaded from memory into the compute unit, if only one token is processed, the entire data transfer cost is borne by that single token. However, when processing a larger batch simultaneously, the same weights can serve more computations, spreading out the energy and bandwidth costs.

Batch processing and low latency are inherently conflicting. To accumulate a batch of requests, the system often needs to wait. While throughput increases, individual user response times may slow down.

Therefore, many issues that appear to be at the model layer are actually hardware and system issues. The reasons large batches are used for training, KV Cache is required for inference, models pursue low precision, and systems require quantization all stem from data movement and energy constraints.

Jeff Dean has recently focused more on inference, precisely because inference is extremely sensitive to latency. A slower training task merely delays the end of an experiment, but every additional second of delay in inference directly impacts user experience and agent efficiency.

If an agent needs to call the model 1,000 times consecutively, reducing latency by 50% per call could result in a significant difference in total task completion time—not to mention that future agents may run for days or even weeks.

Therefore, AI’s “energy problem” is not a distant environmental concern—it directly determines whether models can serve more people affordably, whether agents can operate continuously, and whether startups can maintain healthy gross margins.

Over the past few years, the AI industry has measured progress through parameters, training data, and benchmark scores. In 2026, Jeff Dean places greater emphasis on everything surrounding the model.

A truly useful AI system requires, beyond the model, retrieval, tools, memory, historical information, an execution environment, and feedback mechanisms. The model must know what tools are available, when to invoke them, how to break down complex problems into sequences of actions, and be able to compare multiple approaches to determine which is most likely to succeed.

This is why "context engineering" is stepping into the spotlight.

Jeff Dean said that information seen during training is ultimately "stirred" into hundreds of billions or even trillions of parameters. It’s like a rich stew—knowledge is present, but not necessarily clear. Information provided in the current context is more direct and easier for the model to use accurately.

This presents a significant opportunity for small teams.

Training foundational models requires massive capital, data, and computational power. In contrast, prompt engineering can start with just an API. Entrepreneurs can organize domain knowledge, tools, processes, customer data, and evaluation criteria around specific business needs, enabling general-purpose models to perform more reliably in narrow use cases.

Jeff Dean cited his own example.

He and Sanjay Ghemawat frequently optimized Google’s internal core libraries. These data structures may run on millions of processes, Click Performance differences are amplified by scale. The traditional approach involves engineers first writing microbenchmarks, measuring current performance, modifying the code, rerunning the benchmarks, observing cache usage and performance changes, and then iterating further.

The two individuals documented this workflow as an Agent skill. The model learned how to run benchmarks, modify code, compare results, and further optimize based on measurements.

We simply gave it the methods that humans would use, in a form that the model can use.

This sentence can almost be considered a simple definition of context engineering.

It’s not about mysterious prompt tricks or dumping more background material. It’s about answering three questions: What steps would an expert take? What reliable tools does the system have? And how should the outcome be verified?

When this content is structured, the model gains not more knowledge, but a set of repeatable procedures.

This is why "skills" become a key asset in the Agent ecosystem. A well-crafted skill file may encapsulate years of tacit experience from a team, guiding the model on what to do first when encountering a certain type of problem, which errors are most common, which tools are trustworthy, and what constitutes a completed outcome.

The future differentiation of companies will likely not only reside in model weights but also in the expertise encoded into workflows.

Almost every team that has truly built an agent has encountered the same scenario.

The early steps went smoothly. The model could understand requirements, call tools, and write code. But by step 30 or 50, it began to forget its goal, misinterpret the state, repeat actions, or drift further down the wrong path.

Jeff Dean attributed one of the reasons to out-of-distribution issues.

The model has been trained on a large number of common tasks. As long as the task remains on its familiar "well-trodden path," its performance is typically strong. However, once a sequence of operations leads it into an unfamiliar state, performance drops sharply. The further it strays from its comfort zone, the more likely errors are to accumulate.

One solution is to provide skills and prompts to guide the model along paths it is most familiar with. Another approach is to use a multi-agent system.

Multiple agents can try different approaches, while another model acts as an evaluator to determine which directions hold the most promise. Unsuccessful branches are discarded, while successful ones are further pursued. This is essentially performing a search during the reasoning phase.

It’s not unfamiliar to how human teams operate: when facing complex problems, one person proposes a solution, another reviews the risks, and a third runs experiments. The team doesn’t put all its hopes on the first idea but reduces single points of failure through division of labor and feedback.

The longer an agent runs, the less the system design can rely on getting it right the first time.

A truly reliable long-range agent requires checkpoints, state management, rollback, branch exploration, external evaluation, access control, and exception recovery. It is more like a distributed system than an extended chat window.

This is precisely where Jeff Dean's background begins to regain its importance.

One of the core problems MapReduce addresses is how to achieve reliable computation using a large number of unreliable machines. Today’s agent systems face a similar contradiction: individual model calls are not perfect, and tools may fail, yet the overall task must still be completed as stably as possible.

The next-generation agent platform may inherit many distributed systems principles: tasks can be split, results can be verified, failures can be retried, state can be recovered, and local errors should not crash the entire process.

When Jeff Dean says agents will run for days or even weeks, he is not describing a longer chat—he is describing a new computing infrastructure.

In the context of Startup School, the most pressing question is naturally entrepreneurial opportunity.

Google can co-design chips, data centers, models, and products. General-purpose models like Gemini are rapidly expanding their capabilities. How can a team of two or three people possibly compete?

Jeff Dean's response was not romantic.

Opportunities for small teams often exist in specific areas where general-purpose models have not yet paid sufficient attention. Entrepreneurs can combine product interfaces, proprietary data, workflows, and domain expertise to deliver higher accuracy and a better experience within a narrow use case.

But he immediately issued a warning: general-purpose models are rapidly growing stronger. Features that seem independent today may be directly covered by foundational models in six or twelve months.

Therefore, entrepreneurs need to assess whether their advantages are sustainable.

Jeff Dean provided a specific screening criterion: look for tasks where current general models have success rates close to 0% or 1%, rather than those already achieving 20%.

If the model completely fails, that might be a good sign. If it can already do part of it, just not very well, that may not necessarily be a good sign.

The reason is simple: 20% means the capability has already begun to emerge; more data, larger models, and longer reasoning will likely quickly push it to usability. 0% or 1% suggests the task may be missing critical data, specialized tools, domain feedback, or a capability that a general-purpose model cannot easily acquire in the short term.

This can be called Jeff Dean's "1% rule."

It is not suggesting that entrepreneurs focus solely on the hardest problems, but rather on problems where general models have structural blind spots.

There are roughly three types of these blind spots.

The first category is proprietary data. General-purpose models can organize global information, but they may not have access to a user’s complete personal profile, a company’s internal processes, or real-time data generated by a specific device. Once a startup product gains access to this data, it can develop a perspective distinct from foundational models.

The second category is professional evaluation. Many industries don’t lack generation capability, but rather reliable judgment. Fields such as healthcare, materials science, semiconductors, manufacturing, and scientific research all require high-quality validators. Whoever can define “what is correct” can enable agents to continuously improve.

The third category consists of narrow and deep models. AlphaFold is not a general-purpose chat model; it has developed highly specialized capabilities for the problem of protein structure. Similar opportunities may arise in materials science, chip design, and other specialized fields.

This evaluation is not easy for entrepreneurs. It requires the team to understand both the boundaries of the model’s capabilities and the deep-rooted challenges within the industry. Only understanding AI may lead to features that are quickly absorbed by platforms. Only understanding the industry may cause underestimation of the speed of model advancements.

The real opportunity lies at the intersection of both.

Diana proposes a hypothesis: If, in the future, every founder can simultaneously manage 50 or 100 agents, and all code is written by agents, what skills will become scarce?

Jeff Dean's response was "taste."

More precisely, it’s about determining what the Agent should do.

He believes that the greatest value of research does not lie in how perfectly an experiment is executed, but in whether a worthwhile problem has been chosen. A team can use the most sophisticated methods to complete an insignificant study, or they can tackle a critical issue whose resolution could transform the entire field.

After the agent reduces execution costs, the importance of question selection will increase further.

In the past, a vague idea would naturally fade away due to high development costs. In the future, with enough agents mobilized, many ideas can be rapidly prototyped. The world won’t automatically see more great products as a result—only more products.

Specifications will also become more important.

Jeff Dean said that when collaborating with virtual agents, the clearer the goal, the higher the success rate. In the past, ambiguous requirements were handed to a senior engineer who could ask follow-up questions and rely on shared context to fill in intent. Although agents can also ask questions, they are more likely to make assumptions when context is lacking.

A typical high-success-rate task is migrating software from one programming language to another. The reason is not that the migration is simple, but because the specifications are extremely comprehensive. The old code defines the behavior, tests define the boundaries, and the agent can systematically compare each item until the new version behaves identically.

Now agents can write software for you, but it’s more important than ever to clearly explain what you want.

This statement has direct implications for so-called AI-native organizations.

Future managers won't just assign tasks—they'll define clearer goals and acceptance criteria. Design documents will no longer serve merely as team communication tools but will also become inputs for machine execution. Testing, metrics, constraints, and examples will shift from the end of the development process to the task definition stage.

As for how to train "taste," Jeff Dean's approach is very practical.

Write down a list of things you believe will become important over the next 12 months. You don’t need to do all of them. Revisit the list after 12 months to see which predictions came true, which were accomplished by others, and which made no progress. By continuously accumulating predictive samples, people gradually calibrate their judgment.

Taste is not entirely innate; it can also be developed through reflection and practice.

In the second half of the interview, Jeff Dean shared a rather wild thought experiment.

Over the past 60 years, the semiconductor industry has pursued transistors that are smaller, more stable, and have lower error rates. It has been assumed that chips manufactured from the same design should be as identical as possible, with fewer bit flips being better.

In large distributed systems, engineers have long accepted that individual components will fail. Hard drives can break, machines can crash, and switches can malfunction. System reliability does not come from every component being flawless, but from replication, checksums, redundancy, and recovery.

So Jeff Dean asked: What if transistors made 20 errors per day instead of one error every few million years?

This is not a realistic product plan. He is simply trying to remove a taken-for-granted assumption. Perhaps extremely unreliable transistors could be manufactured in a completely different way, with the system ensuring results through multiple paths and high-level redundancy.

Most thought experiments never become products. Many industry practices have persisted for decades for good reasons. But Jeff Dean believes these reasons should still be periodically re-examined.

MapReduce comes from a similar process.

Early Google's crawler and indexing system contained extensive hand-written parallel code, checkpoints, and fault recovery logic. The actual business computations were often simple, such as reading all web pages and determining their language. However, the vast amount of system code obscured these simple intentions.

Jeff Dean and Sanjay Ghemawat drew inspiration from functional programming. They abstracted large-scale tasks into Map and Reduce operations, and delegated parallelization, scheduling, fault tolerance, and retry mechanisms to a unified framework, allowing business developers to focus solely on expressing the computation itself.

This design doesn't make the machine error-free; it makes errors absorbable by the system.

Today, agent engineering may also be at a similar stage. Many teams are still manually orchestrating prompts, retry logic, and tool calls for each task. In the future, will a simple abstraction—like MapReduce—emerge, making decomposition, validation, recovery, and parallel exploration of long-range agents underlying capabilities?

This may be the opportunity for the next wave of infrastructure companies.

Jeff Dean is most excited about automating the scientific method itself.

The traditional scientific research process involves formulating a hypothesis, designing an experiment, conducting the experiment, analyzing the results, and then generating the next hypothesis. The speed of this cycle has long been limited by experimental costs and verification delays.

AI can change two parts.

Part of it involves automatically proposing and conducting more experiments. Another part involves turning expensive validators into inexpensive approximation models.

Jeff Dean cited an example from quantum chemistry: researchers wishing to determine the properties of a molecular configuration can run density functional theory simulations, which may take an entire night for a single run. Google’s researchers trained a neural network approximator using a large set of simulation inputs and outputs. This approximator achieves accuracy close to the original simulator but is approximately 300,000 times faster.

After the verification speed changes, the form of scientific questions also changes.

Previously, screening 10 million candidates might have been a project requiring months of computational power. Now, the system can complete the initial screening in the time it takes a researcher to have lunch. Experiments are no longer precious one-time bets but have become high-frequency searches.

This is the underlying logic behind systems like AlphaEvolve and AlphaChip: the model proposes solutions, tools execute them, and evaluators filter the results, with high-quality outcomes progressing to the next round. As long as the feedback loop is fast enough, the system can continuously explore vast solution spaces.

Machine learning itself will also become the subject of this automated science.

Today, large research teams typically involve humans proposing new architectures or training methods, running small-scale experiments first, and then scaling up promising approaches. Jeff Dean believes there is no fundamental barrier preventing models from taking over an increasing number of these steps—humans provide high-level direction, while the system automatically explores architectures, data recipes, and training strategies, then combines successful experiments into new models.

In the future, the metric for measuring research efficiency may no longer be just floating-point operations per second, but rather "how many meaningful discoveries are generated per unit of computational power."

Computing power is certainly important. More important is how to convert computing power into discoveries.

In 2014, Jeff Dean, Geoff Hinton, and Oriol Vinyals submitted a paper on knowledge distillation. Today, knowledge distillation is a foundational technique in model compression and capability transfer, where large models act as teachers, transferring their capabilities to smaller, faster, and more cost-effective student models.

This highly influential paper was rejected by NeurIPS at the time.

One reviewer believed it was “unlikely to have a significant impact.” Interested readers can visit “Rejected Doesn’t Mean Failure! These High-Impact Papers Were All Rejected by Top Conferences.”

Jeff Dean spoke about this experience without anger. He said the reviewers may not have understood the real-world challenges of scaling AI services. For Google, transforming expensive large models into smaller ones capable of serving hundreds of millions of users was clearly crucial. To reviewers focused solely on theoretical novelty, it may not have seemed sufficiently "fundamental."

After the paper was rejected, the team posted it on arXiv. The industry still read it and still began using it.

Today, Gemini's Flash model maintains strong capabilities with smaller size and lower latency, and distillation is one of the key methods enabling this.

This story is not just an inspirational tale of “perseverance leads to success.” It illustrates that evaluation systems always have blind spots. The value of a solution is sometimes immediately apparent only to those who have personally experienced the system’s bottlenecks.

This is equally important for entrepreneurs.

Negativity from the market, investors, and peers may indicate a wrong direction—or it may simply mean they aren’t facing the same problem. The difference lies in whether the team has sufficient, concrete evidence to understand why this problem matters and why it can be solved now.

Jeff Dean does not encourage blind persistence. He encourages understanding the problem, continuously validating, and not treating a single review as the final judgment on the world.

Near the end of the interview, Diana posed a imaginative question.

If young Jeff Dean, who joined Google in 1999, were transported to 2026, would he join a cutting-edge lab or start a company with two or three friends?

Jeff Dean did not provide a standard answer.

Large organizations have structure, platforms, and many talented colleagues. Within them, individuals can access knowledge they don’t yet understand and leverage mature products to impact users worldwide. Smaller teams offer greater freedom but also carry higher risks. Founders must genuinely believe in a problem and be willing to endure uncertainty for years.

The criteria he provided are more fundamental than "joining a big company or starting a startup."

If I solve this problem and the best possible outcome actually happens, will the world noticeably improve, or will people just say, “Cool,” and move on?

If the answer is just “pretty cool,” it may not be worth investing your most precious resource—time.

He also emphasized the importance of teammates—seek individuals with complementary skills, low egos, a willingness to collaborate, and a positive attitude. Truly difficult challenges often require long-term collaboration. Team members should each bring unique tools others don’t have, and continue expanding their own “tool belt” through joint work.

This remark has a simple, old-school engineer's charm.

The AI industry loves to talk about exponential growth, superintelligence, and massive funding. But in the end, Jeff Dean returns to three simple things: work on a problem you truly care about, collaborate with people you like, and do your best to make the world a better place.

Throughout Jeff Dean's career, there have been many legendary stories that are repeatedly told.

He and Sanjay Ghemawat rewrote the search system in a few days to load the index into memory. A three-minute voice estimate spurred Google to build the TPU. MapReduce concealed large-scale parallelism and fault tolerance behind a unified abstraction. Knowledge distillation evolved from a rejected paper into an industry-standard technology.

These stories easily make one imagine him as a genius constantly inspired.

But from this interview, it’s clear that his approach has been highly consistent.

First, clarify the order of magnitude. Then identify the real bottleneck. Next, challenge default assumptions and create a simpler abstraction. Finally, use measurement and feedback to drive continuous iteration of the system.

The AI industry today is experiencing a similar turning point.

The model is already strong enough to handle tasks at a junior engineer level. What ultimately determines real-world productivity is not just the model’s intelligence, but also reasoning cost, context organization, tool quality, verification speed, and long-term operational reliability.

Agents will increasingly resemble team members. But they require clear specifications, skills, checkpoints, evaluators, and a system that accommodates failure.

Opportunities for startups won’t disappear—they’ll just become more demanding. Instead of tackling tasks that general models can already accomplish 20% of the time, seek out problems where success rates are still near 0% or 1%. There, you may find proprietary data, specialized evaluators, narrow-domain models, or entirely new system abstractions.

As code generation becomes cheaper, the real cost will be the problems themselves.

What is worth doing? What constraints are outdated? What changes have just crossed the tipping point? What system would become an entirely different product if it were 50 times faster?

Jeff Dean did not provide a list of opportunities for 6,000 entrepreneurs. Instead, he offered a more enduring way of thinking.

Don't rush to chase the hottest answer.

First, calculate the issue.

Reference link

https://x.com/ycombinator/status/2082938685071491219

https://www.ycrootaccess.com/p/jeff-dean-the-1-rule-for-building

This article is from the WeChat public account "Machine Heart" (ID: almosthuman2014), authored by Panda.