Jeff Dean 离职前最后一谈：低估 AI 速度，给创业者的 0% 生存法则

A year ago, Google's chief scientist Jeff Dean predicted at the AI Ascent 2025 summit that by 2026 we might see AI systems capable of working around the clock with skills close to those of a junior software engineer.

A year later — six days ago, to be exact — he admitted in a YC interview that he had underestimated the pace of AI progress. The ability of models to handle increasingly complex tasks grew far faster than he had imagined then. So in Jeff Dean's view, how quickly will AI keep advancing from here? And how should startups survive in an era when general-purpose models keep pushing the boundaries of what they can do?

Early this morning, this interview took on added weight. Jeff Dean announced that tomorrow would be his last day at Google. After 27 years at the company, the legendary engineer — hailed as Silicon Valley's 'programmer's programmer' and deeply involved in Google's system architecture and AI infrastructure — will co-found Discovery Loop with longtime collaborators Sanjay Ghemawat, Oriol Vinyals, and Quoc Le. Discovery Loop is a public-benefit company focused on frontier research in machine learning, science, and engineering. Google will continue to work with them as founding investor and cloud computing partner.

According to WIRED, the startup idea only surfaced a few weeks ago. Alphabet CEO Sundar Pichai met with them multiple times, trying to persuade the core team to keep their badges. But in the end, they decided to leave the big-company system in exchange for the fun, speed, and freedom that only a startup can offer.

Screenshot from: https://x.com/JeffDean/status/2085035498222002595/photo/1

In his farewell letter, Jeff Dean wrote that he had watched Google grow from a company of just 25 people into a tech giant with more than 190,000 employees. Today, 13 Google products each have over a billion users. From search, email, translation, and video to large-scale computing, self-driving cars, and AI systems, the technologies he helped build run through nearly the entire arc of Google's history.

A major reason they left is the inertia that large companies can't seem to shake. As Oriol Vinyals put it, inside a big organization, pushing any radical change means overcoming layers of resistance; they wanted to build something different. Interestingly, the new company hasn't even had time to hire anyone or rent an office. As for who would be CEO, after a brief pause, the team turned to Jeff Dean. 'I guess it's me,' he said.

So this interview, published on the eve of Jeff Dean's departure, reads like a concentrated statement from a career turning point about the next phase of AI. In the conversation, he and YC partner Diana Hu discussed the paradigm shift from 'model-centric' to 'context engineering,' the huge opportunity emerging in inference hardware, and how founders can find a defensible space in an era where general-purpose models are getting stronger and more and more applications may simply be absorbed by them.

This article is based on the interview video and was edited by InfoQ.

TL;DR

Q: Last year you said that by 2026 we'd see AI with abilities close to a junior engineer. A year later, has that prediction been proven wrong?

A: It's held up quite well. But I underestimated one thing: models' ability to handle increasingly complex tasks has grown much faster than I expected. And that capability is spilling beyond coding — agent-based systems are beginning to really come into their own.

Q: What's your bold prediction for 2027?

A: Deep learning systems will achieve fully automatic problem decomposition and automated experiment loops: break a problem into subproblems, run experiments automatically, integrate results, and arrive at an improved system. This won't apply only to machine learning; it will work in any scientific or engineering domain with a measurable goal.

Q: In 2001, Google put the search index into memory. What's the 'fit into memory' moment of 2026?

A: High-performance, low-energy specialized inference hardware. Inference is the key to bringing agent systems to more people. Specialized hardware can deliver a 50x latency improvement and 30–80x energy-efficiency gains. Back then, we eliminated the physical latency of disk seeks; today, we eliminate the redundant steps of general-purpose computing. But the stakes are higher this time, because agents need thousands of sequential inference calls, and every bit of latency accumulates.

Q: What's the biggest misconception people have about AI right now?

A: Everyone thinks of agents as temporary tasks that run for an hour or two. But with a strong enough underlying model, you can let agents run for days or even weeks.

Q: What did the napkin math that led to the TPU actually calculate?

A: In 2013, speech recognition suddenly got much better, and we did the numbers: if every user spent three minutes a day talking to their phone, CPUs would never keep up. So we built the TPU. A few years later, when the Transformer appeared, it turned out to be exactly the foundation it needed.

Q: In the AI-era latency numbers list, which number should everyone remember?

A: One computation costs about a picojoule, but moving data into the processor — that short distance — costs 1,000 times more energy. That gap is why you have to do batching: process many samples together and amortize the cost as '1,000 divided by batch size.'

Q: How should founders choose what to work on?

A: Test your intended domain against the strongest current general-purpose model. If the model succeeds 0% or 1% of the time, that's a good sign. If it succeeds 20% of the time, that's a danger signal: the capability is already emerging, and the next generation of models will soon cover it.

Q: When agents write all the code, what skill becomes scarce?

A: Taste — knowing what problems you should have your agents solve. First, draw on experience solving a wide range of problems. Second, write down ten things you think might matter in the next 12 months, then review a year later which ones actually became important. Third, run crazy thought experiments, like: 'How would you design a system if transistors made a mistake 20 times a day instead of once in a million years?'

Diana: Last May at the AI Ascent conference, you said that by around 2026 we might see AI systems that can work around the clock and approach the abilities of a junior engineer. How close are we to that prediction now?

Jeff: I think models have made enormous progress on agentic long-running coding tasks. It's becoming clear that they are quite capable already — depending on exactly how you define 'junior engineer,' that prediction looks pretty accurate today.

Diana: So what did you underestimate?

Jeff: I underestimated how quickly models would become able to handle increasingly complex tasks. And beyond coding, these agent-based systems are also beginning to emerge for real. I think that's going to be an important trend.

Diana: What would your 2027 prediction be?

Jeff: I think you'll see much more automation of machine learning systems themselves. Specifically, ML systems that improve their own capabilities by running lots of experiments: breaking a problem into subproblems, running those subproblems in tight automated experiment loops, then integrating the results into an improved system. This applies not just to machine learning but to other areas of science and engineering. Basically, anything with a measurable goal can make great progress now.

Diana: In 2001, Google search still ran on disks. You and Sanjay did the math and realized that at some point the entire search index would finally fit into the memory of all running computers. You made the radical call — within days, you and Sanjay pushed a brand-new version of search built on memory, not disks, into production. That's what made Google the Google of today.

History repeats itself. So in 2026, what is the 'it finally fits in memory' moment? What's the inflection point everyone here should be thinking about and designing for?

Jeff: It's a bit different, but I'd say you're going to see more and more high-performance, low-energy inference hardware systems. Everyone now realizes that inference is the key to bringing these agent systems to more people. Latency really matters, and hardware specialization is the core way to beat general-purpose computing like GPUs or CPUs on both energy efficiency and latency.

Diana: So you're saying maybe we don't have to wait?

Jeff: Exactly. Imagine what you could do with a 50x latency improvement.

Diana: About 6,000 people are here. What assumption do they hold about AI that's already wrong?

Jeff: I think it's that people haven't fully appreciated how long agent systems can run. Everyone thinks of agents as one- or two-hour temp jobs. But in certain problem domains, with a strong enough underlying model, you can let agents run for days or even weeks, really tackling complex, long-horizon problems. That's not just a matter of waiting longer; it's a qualitative change.

Diana: So what weeks-long tasks have you actually run? What did you have agents solve?

Jeff: For example, you can have an agent implement a brand-new version of some software — rewrite it in a different programming language, perhaps with better security or performance characteristics. It can genuinely work through that task and do it pretty reliably.

Diana: Everyone knows you're especially good at napkin math. There's a story that when Google voice recognition launched in 2013, you estimated that if every Google user spent three minutes a day speaking to the voice recognition system on their phone, the server fleet would need to double. The cost was frightening. So you built a custom chip — that's the origin story of the TPU.

Jeff: At the time, the deep-learning speech models we were training had started to work really well, but they were much more expensive computationally than the old speech system. However, they cut the error rate in half. That was like compressing 20 years of progress in speech recognition into a few months — we just tweaked the model, scaled it up a bit, and got better data. So we started worrying: if speech recognition got dramatically better, people would use it much more often.

So the rough calculation was really about: what happens if people start using speech recognition more often, to dictate emails or talk to their phones? When we ran the numbers, we saw CPUs would never handle it at the time. So we built the TPU — a chip specialized for low-precision dense linear algebra, which is the core of nearly all machine learning algorithms today.

It couldn't do anything else except linear algebra — it couldn't run Chrome or Word — but that didn't matter for ML inference. When the chip came out a few years later, it was 30 to 80 times more energy-efficient than contemporaneous CPUs and GPUs, with 20 to 30 times lower latency.

Diana: You surely couldn't have predicted that the TPU would become so foundational when the Transformer architecture arrived years later.

Jeff: That's exactly why we built it as a general linear algebra system. We knew ML algorithms were still evolving, so we couldn't over-specialize. But we needed to specialize enough to get a huge performance win. So we built large multiplier units, high-bandwidth memory, and high-speed interconnect. Later TPUs could coordinate hundreds or thousands of chips on a single problem efficiently. We just iterated generation after generation, up to today.

Diana: If someone wants to be a future founder, what kind of napkin math should they do to build something as influential as the TPU?

Jeff: Think about what problem or bottleneck you see in the area you care about, then ask: is there a very different way of thinking that could make the solution an order of magnitude, or two orders of magnitude, better? Sometimes you just squint at a problem, don't anchor to how it's solved today, and reason from first principles about how you'd solve it. That's how genuinely great ideas no one else thought of come out.

Diana: Years ago, you wrote a famous list called 'Latency Numbers Every Programmer Should Know,' with timings for all sorts of system operations: how long a cache miss takes, how long a disk seek takes, how long a network packet takes to travel from California to the Netherlands... That list became a bible for distributed systems engineers. Now it's time for an AI-era update.

Jeff: If you look at what matters most in today's AI systems, first you need to know the bandwidth from the accelerator's main memory to on-chip memory and then to the multiplier units. You need to know how much energy a multiply operation consumes. You need to know the interconnect bandwidth between chips and how many chips you can connect at that bandwidth. And at an even larger scale, when you need to talk to 10,000 chips instead of 500, how much does network bandwidth degrade? These numbers are the real underlying constraints that shape how you think about problems. They directly determine what approach you take.

Diana: You've said that the measuring stick for everything now is energy. One computation or mathematical operation costs about a picojoule, but moving data — data I/O — costs 1,000 times that.

Jeff: Right. Just moving data from HBM on the accelerator into the processor, that tiny stretch where it can actually be computed on, costs three orders of magnitude more energy.

Diana: This gap is quietly deciding which products can be built and which algorithmic paths can work. Since data movement is so expensive, what if a founder comes to you saying they have a 'model problem,' but it's really an energy or data I/O problem? How do you tell the difference?

Jeff: That 1,000x difference shapes a huge number of decisions in machine learning. Without it, you wouldn't need batching at all. But in reality, you have to process many samples and tokens together to amortize the cost of data movement. Instead of paying 1,000x, you pay '1,000 divided by batch size.' For low-latency scenarios, though, batching is unfriendly. So these hardware-level energy considerations deeply influence every decision we make when building systems on top.

Diana: A very concrete example is how we train models — batching datasets and running epochs. Many people think it's a model problem, but it's fundamentally a system data I/O problem, right?

Jeff: Yes. You have to assemble batches to get hardware to run efficiently. Ideally, you'd love to train with batch size 1, but that would be terribly inefficient. So everyone uses large batches now.

Diana: I hear you have a habit of disappearing and coming back with a brilliant solution. Could you spend a few weeks and completely solve batch-size-1 training?

Jeff: Honestly, I've been thinking more about inference lately. Inference is interesting because you really want extremely low latency; training doesn't necessarily need that. And inference is exactly where batching works worst. The core is to minimize data movement as much as possible, and then think about very low-precision arithmetic — maybe you don't need to support many different precision formats. If you have a good answer for which precision you need, just hard-code it into the hardware and don't worry about anything else.

Diana: I'm reminded of a core analogy a famous computer scientist once told me: the entire AI process is essentially a huge compression problem. To lossy-compress data and then reconstruct it, you basically have to actually understand it first.

Jeff: Right. If you truly understand the data, you should be able to compress it extremely well.

Diana: And the Transformer architecture has turned out to be a particularly good compression method.

Jeff: Credit goes to my colleagues.

Diana: In the past, when we talked about AI progress, we usually meant the model itself getting better. But in recent years, it's become increasingly clear that it's not just model scale, parameter count, or data volume. It's the surrounding capabilities — retrieval, tool use, memory, agent tools — converging into what people now call 'context engineering.'

Jeff: The model is really just one piece of the whole system. What you need is a complete system that can solve genuinely interesting problems. That system needs a model that knows how to use various tools, knows how to retrieve relevant information, and maybe keeps historical information retrieved when solving similar problems in the past, then puts all that into the model's context. The beauty of context engineering is that this information is extremely clear to the model. Unlike training data — where trillions of tokens are mixed together into a soup of hundreds of billions of parameters, everything blurred together — the context the model directly sees is far more explicit than that fuzzy training data.

Then you need to understand what tools are available, which ones can help the model solve the current subproblem, how to break a complex problem into a series of tool calls, and even try multiple paths to see which one works, then evaluate the results. That's the orchestration of complex agent and multi-agent systems, and it's going to become increasingly important.

Diana: How do you become great at context engineering?

Jeff: The best way is to just use these models, harnesses, and tools to solve real problems. As you use them, you'll see where models fail. Then you'll discover that you often don't need to adjust model parameters — which is hard to do from outside — but by writing better prompts and designing clearer context, you can get the model to perform better.

Diana: Can you give us an example of your own context engineering? What skills have you written, or what tools have you configured, that dramatically changed your workflow?

Jeff: Take something Sanjay and I did a few weeks ago. We often do performance optimization work on very low-level libraries. Google has an internal microbenchmark library you can use to measure how long different operations take — for example, how many nanoseconds it takes to pop an element from a data structure. These data structures may run on millions of Google processes, so making sure they're high-performance is actually quite important.

We wrote a skill that teaches the model to do a specific sequence of operations: first run microbenchmarks to measure current performance, then make code changes, then rerun benchmarks to verify improvements, then measure cache footprint, and then iterate. That way it can do self-improvement — essentially, we gave the model the same method we'd use as humans, in a form it can use.

Diana: So you have a skill that, if someone else got it, would let them do performance optimization like Jeff Dean? The world would go crazy for that. For some people, it's worth infinite money.

Jeff: Actually, we published a document a few months ago called 'Performance Hints,' written by Sanjay and me. It's about 30 pages covering various performance optimization techniques. People have already summarized it and fed it to various models, and they found that models did get better at reasoning about code performance issues.

Diana: Everyone here is probably building agents, and everyone has seen their agent go off the rails at step 30 or 40. What do you think the bottleneck is today? Is it the context evaluator, or is it because this is an open-loop system where errors accumulate?

Jeff: Of course we want agents to run for a long time, because that's how they can solve increasingly complex problems. But as you observed, they sometimes stop working after ten tool interactions. Sometimes it's because the model is trying to do something it lacks experience with. Once a model strays from its training distribution, performance falls off sharply, just like most ML models. The further it gets from its comfort zone, the higher the failure probability.

There are a few ways to deal with this. One is to give the model skills and prompts so it stays on a familiar, well-lit path. Another is to use multi-agent systems: let multiple agents try different approaches, and use another model or agent to evaluate which approaches look promising. Essentially, this uses inference-time compute to search the space of possible solutions, which can dramatically improve the reliability and performance of long-running agent workflows.

Diana: How do you implement this kind of workflow internally?

Jeff: We have all sorts of harnesses and a whole set of skills. Especially in Google's internal development environment, we wrote skills that teach agents how to use internal tools — code review, performance measurement, pulling log files. These skills let a base model do the job well through proper skill definitions, even if it was never trained on our proprietary systems.

Diana: Google's uniqueness is that you co-design the full stack, from processors to products. Which layers will Google keep going deep on and compounding advantages? Where can a two- or three-person small team still win?

Jeff: Obviously Google, Gemini models, and the hardware infrastructure — we aim to build general-purpose models that can do almost everything. But in many cases, that means we can't devote much attention to specific domains. A well-designed interface, combined with a model and a set of skills, or a specialized model outside the general model ecosystem, can have a significant advantage. You can build a delightful, high-precision, high-quality product for a domain you truly love. I think that's exactly where two or three people building something they're genuinely excited about can win.

General-purpose models are indeed getting stronger across an ever-wider range. So you have to think clearly: is what you're building durable? Or will frontier models do it better in the next 6 or 12 months? Or is it something they can't do for two or three years? Judging that time window is the most important trade-off when deciding what to build.

Diana: How do you judge it concretely? How should founders reason about which domains are worth working on?

Jeff: The most important thing is to pick something you're super excited about, want to build, and think will be useful to the world. Second, test your problem domain against the strongest current general-purpose model. See how today's models perform in that domain. If they can't do it at all, that's likely a good sign. If they can already do part of it but not very well, that might be a danger signal. It means the capability is already emerging in the model, and with more training data and larger scale, it will probably get better. So you're looking for domains where the model succeeds 0% or 1% of the time, not 20% of the time.

Diana: How do you find those 0% domains? Are they essentially things outside the training set? What problem shapes fit this criterion?

Jeff: Sometimes it's because your product touches a specific type of data that the underlying general model can't access. For example, if you build a tool that helps users organize their personal information, the model itself doesn't have permission to access users' personal data. It could also be an extremely hard problem where, if you get the right training data, you can train a more specialized model than the general one. And you can do that very economically — training a niche model for a specific problem doesn't require all that much compute.

Diana: So there are really two paths. The first is subtle. Google's slogan is 'organize the world's information' — that territory is basically covered. But 'organize each person's own information' is still wide open. The second path involves specialized models in certain domains. Can you be more specific about which domains?

Jeff: Look at my colleagues' work on AlphaFold. It's a model specialized for protein folding, extremely successful, and it really handles that domain beautifully. It's not a general model; it's a very specialized one. In other areas — like materials science or chip design — this approach can also have a huge impact. You can use highly accurate but niche models to do things that are very hard to do today.

Diana: You've said before that the key to managing a group of agents is writing clear design docs or specs. How do people get good at that?

Jeff: When you work with agents, the clearer you are about what you want, the more guidelines, rules, and summaries of goals the agent has. If you don't specify much, the agent has to infer what you mean. In many cases, it infers something different from what you imagined. We've told computer scientists from the very beginning to specify what the software you're writing is supposed to accomplish before writing it. Now, specifying what you want has become even more important. In the past, you'd hand it to a very smart person who had context or could ask follow-up questions. Agents can sometimes do that too, but a clear spec is a good idea.

Here's an example: one extremely effective use of coding agents is to have today's model translate software from one computer language to another. It works very well because in that case you actually have an extremely detailed spec — you have the entire software describing what the system should do. So if you have something implemented in Python and you want a Go implementation, that's something today's models seem very good at. They can take all the Python tests, make sure they pass in the Go version, translate the tests to Go, compare behavior between the two implementations until there is no difference — and it's very efficient because that spec is so clear.

Diana: Suppose everyone learns to run hundreds of agents at once, and all the code is written by agents. What skill becomes scarce?

Jeff: I think it's truly great taste — knowing what problems you should have your agents solve. That's the core of research. A researcher can have all the tools and techniques, but most of the battle is: which problem do you spend your time on? If you pick the right problem and solve it, that's far better than executing a boring problem beautifully. This high-level wisdom of 'what to do' is extremely important, and models are unlikely to become great at it. So in the future, humans will steer massive amounts of AI-assisted compute to accomplish great things. But the essence of what you want your models to do is what you should really focus on.

Diana: In this age of agent programming, the word 'taste' comes up a lot. But it sounds mystical. How do you make it concrete? How do you cultivate taste?

Jeff: It's genuinely hard, and in many cases taste has no measurable objective standard. I think part of it comes from experience: having solved a wide variety of problems in the past teaches you what kinds of problems might be interesting in the future, or what might be achievable by combining previous methods. Another method: write down a bunch of things you think might matter in the next 12 months. Maybe you pick one of them to work on, but 12 months later, come back and evaluate: which of those other things actually became important? Which were done by other people in the world? Which hasn't anyone touched yet? That provides a lot of samples for cultivating your own taste.

Diana: I think there's a third way, which we talked about before: running really crazy thought experiments.

Jeff: Oh right, that's another good method. Sometimes, don't take for granted the things most people take for granted. For example, a few days ago I ran a crazy thought experiment with colleagues: for 60 years, the entire silicon chip design and manufacturing industry has done a huge amount of work making transistors smaller and less error-prone. Because our assumption is that every manufactured chip should be identical to every other chip, and you don't want any bit flips. But at the macro scale, when we build large distributed systems, we don't make that assumption. We build reliable distributed filesystems out of unreliable components. A single disk may fail, but your data should be safe. So here's an interesting thought experiment: what if you tried to build systems with transistors that make mistakes 20 times a day, instead of once every million years? That would be a very different design point, and it could open up very interesting possibilities on the manufacturing side.

Diana: That's crazy. It starts to resonate with neuromorphic computing or how the brain works.

Jeff: Exactly. Signals in the brain aren't particularly reliable when traveling from one place to another. So in the brain, when there's truly important information to convey, there are multiple pathways to make sure it gets through.

Diana: Is there a crazy assumption you abandoned that eventually led to building an influential system?

Jeff: The TPU is a good example: customizing hardware for a problem area before it looked as important as it does today. The origin of MapReduce is another. Sanjay, some colleagues, and I had written a lot of hand-parallelized code with heavy checkpointing to make things robust on hundreds or thousands of machines. But that code tended to get mixed up with the simple thing you were trying to do — like 'I want to look at the contents of all web pages and compute a mapping from URLs to page languages' — buried under tons of parallelization and reliability code. We remembered our functional programming training and realized we could squint at these problems and abstract out MapReduce, pushing checkpointing and reliability mechanisms down into the underlying library, then build everything on top of it. So MapReduce was born from that thought experiment: 'If we squint, can we find a large class of problems that fit this abstraction?'

Diana: Now AlphaChip is laying out chips, and AlphaEvolve proposes solutions, evaluates them, and keeps what works. It looks like you're building a system that can compound on itself — AI building AI.

Jeff: More broadly, this is the basis of the scientific method: propose an experiment, run it, evaluate it, get results. There are more and more problem domains where you can run not just a few experiments but huge numbers of them, because you can automate the loop and make its latency extremely low. That lets us tackle many different problem domains in science, engineering, machine learning, model design itself, and engineering tasks like chip design. If you can automate all that, and you have an orchestration framework that decomposes high-level goals into subproblems, where each subproblem is an automated exploration loop, and then the orchestration framework integrates the subproblem solutions into an overall solution, that's going to have an enormous impact. It will accelerate machine learning, science, and engineering.

Diana: It sounds like many domains with good evaluators, or domains that can be formally verified, are well-suited to AI self-improvement.

Jeff: Right. And often your evaluator needs to be faster. For example, my colleagues did some work in quantum chemistry about ten years ago. If you want to understand the properties of a molecule, you can generate a molecular configuration and then run a very expensive density functional theory simulator to find its properties — that could take a whole night of compute to give you an answer. What my colleagues did was take a large number of simulation runs — input molecular configurations and outputs from the expensive simulator — and train a neural approximator to replace the simulator. They built an evaluator that was 300,000 times faster than the original simulator, with almost the same accuracy. That completely changes how you do science. You can screen 10 million candidates during lunch instead of spending six months scraping together compute to run all the simulations. In many fields, faster verification models have enormous room to grow.

Diana: Which fields are you most excited to see this superfast scientific method tackle?

Jeff: Obviously machine learning itself is one. Could you have a model that improves itself by running lots of experiments? Today, large research teams improve models by people coming up with ideas, running a bunch of small-scale experiments, seeing what works, scaling up the most promising ones, evaluating, and integrating them into a new recipe. But there's no real barrier to turning that into a more automated loop, where the model decides what to explore, or at a high level a human nudges it with something like 'why not try a new model architecture idea that includes this,' and then it runs lots of experiments, sees what works, and integrates faster. Essentially, you're optimizing for discoveries per unit of compute input.

Diana: In 2014, you, Geoff Hinton, and Oriol Vinyals wrote a paper on distillation — using a large model to train a smaller, more efficient model. Now it's a technique everyone in the industry uses, but the paper was rejected by NeurIPS.

Jeff: Yes. I don't blame the program committee. Often a paper gets three reviews, and someone glances at it and says 'unlikely to have significant impact.' But when we wrote it, we saw it as a super important problem, because we knew that making cheaper, stronger models from larger-scale models was something we urgently wanted to do. We wanted to serve models to more people in many domains, like speech and vision. But sometimes reviewers don't have that experience. They may not be thinking about large-scale AI serving; they're thinking, 'Is this a fundamental advance?' So getting rejected occasionally is fine. We put it on arXiv, people read it, used it, and all was well. We do use distillation to make our flash models, distilling from our larger pro models. That's why our Gemini flash models are so competitive at the same size and speed.

Diana: When you joined Google in 1999, it was still a 20-person startup. If you transported young Jeff Dean from then to now, with your skills, what would you do? Would you join a frontier lab, or start a company?

Jeff: For me, the most important question is: Is this something you truly care about? Can you make progress with a group of people you enjoy working with, and can it change the world in some positive way? What you should aim for is to have a positive impact on the world, work with people you like, work hard, and do your best. Whether you join a frontier lab or start a two-or-three-person company is a different experience. In a big institution, you have a huge number of excellent colleagues, a huge number of interesting problems, and you already have a platform to make your work affect a lot of people in the world. As a small startup, you have to have something you're passionate about, and you're taking a big risk on that particular problem, but it can also be very rewarding. Whichever path you take, ask yourself: if I solve this problem and the best possible outcome happens, does the world become much better? Or would the world say, 'Oh, cool, but who cares'? If it's the latter, it's not worth your time.

Diana: You've been a mentor and manager to many engineers, and you've built massive systems. What's your experience with working with smart people and finding them?

Jeff: You always want to find people with truly outstanding skills in the areas you need, but you also want to find people you enjoy being around, because you'll spend a huge amount of time solving very hard problems together. You want people with low ego, team spirit, and skills that complement yours. I've always felt that in a small team, someone knows things I don't, and I have some skills others don't. That's super interesting, because you're building something together that none of you could build alone. In the process, you actually gain a lot of new knowledge and skills, and so do they. You should view your engineering or research career as a toolbelt of techniques. You always want to add new tools, because you never know when you'll encounter a problem, and having more tools makes it more likely you can solve the problems you face in the future.

Diana: I'm pretty sure someone in this audience will eventually build something as influential as MapReduce, TPU, or distillation. What problems do you hope they work on?

Jeff: I'm particularly excited about new approaches to hardware, or more efficient inference hardware. I think there might be fundamentally different machine learning algorithms that are far more data-efficient than what we use today. Today's models see perhaps a thousand times more data than an 18-year-old has ever seen. Yet an 18-year-old is on par with or better than frontier models at many things, despite having seen far less data. So can you come up with more data-efficient systems that can learn continuously from their own behavior? Continual learning is a very interesting direction, and multi-agent interaction is also interesting. Creating ways for people to have better conversations, helping people around the world meet each other based on shared interests — these could all be interesting. There are a lot of cool things in the world, and we should all work toward making even cooler things happen.

Original interview video: https://www.youtube.com/watch?v=CxXgV54KzpQ

Reference links:

https://x.com/FakePsyho/status/2085076119103909966

https://x.com/JeffDean/status/2085034604172603724

https://x.com/DiscoLoopAI