Can an LLM Replace an ECCV Panel?

I am at ECCV 2026 and have attended a few panel discussions. During these sessions, one question kept crossing my mind:

How would the answers given in these panels compare with answers generated by an LLM?

With models such as Fable 5.1 and Gemini 3.1 Pro becoming increasingly capable of synthesizing technical knowledge, I thought it would be interesting to take a question from one of the panels and put the same question to an LLM.

So, let's try it.

The question

During the DriveX Panel Discussion II: Industry Track, one of the questions was:

“In your company, in your opinion, what is the most important block needed for E2E driving?”

The panelists gave different answers. Some thought data was the most important missing piece. Others argued that it was not the volume of data, but the variation and diversity of the data that mattered. Some pointed to evaluation as the key bottleneck, while others highlighted closed-loop simulation as an important enabler.

This was interesting because there wasn't really a single consensus answer.

But what happens if we ask an LLM the same question?

Asking the LLMs

I used the following prompt:

“You are a panelist in an ECCV 2026 workshop on end-to-end autonomous driving. You are asked to comment on the following question: ‘In your company, in your opinion, what is the most important block needed for E2E driving?’ Give me a brief answer.”

Fable 5.1

“If I had to pick one block, it's closed-loop evaluation — a scalable, reactive simulator or learned world model that lets us actually measure the policy we're shipping. Everything upstream of it we know how to do: we can collect fleet data, we can train a big model end-to-end, and on a platform like ours we know how to make it run in real time on the vehicle. What we still can't do well is answer 'is this policy better than the last one?' without putting it in a car. E2E training is open-loop imitation, but the failure modes are closed-loop: covariance shift, causal confusion, compounding error. Open-loop metrics barely correlate with what happens on the road, and real-world miles don't scale to the long tail. So the bottleneck isn't the driving model — it's the thing that tells us whether the driving model is good. Whoever solves reliable closed-loop evaluation gets to iterate ten times faster than everyone else, and in this field iteration speed is the whole game.”

That's a pretty good answer. In fact, it is arguably better articulated than some of the answers I heard during the panel.

Gemini 3.1 Pro

I then asked Gemini 3.1 Pro, using its advanced reasoning mode:

“The single most important block is a Generative World Model acting as a closed-loop latent simulator.

Pure imitation learning solves the 99% of nominal driving, but it hits a wall on the long tail of edge cases. To navigate complex, multi-agent scenarios, the system must reason counterfactually—‘What will that cyclist do if I aggressively nudge forward?’ A World Model allows the policy to hallucinate thousands of branching futures and learn through model-based Reinforcement Learning before ever touching a physical steering wheel.

However, for actual productization, this must be paired with a Verifiable Safety Guardrail. E2E networks are inherently probabilistic. While the World Model provides the necessary intelligence, its outputs must be constrained by a deterministic, mathematical envelope that guarantees the vehicle never violates physics or traffic laws.”

Again, this sounds very convincing. And that's what makes the experiment interesting: the LLMs are clearly capable of producing answers that are not only technically plausible, but also aligned with many of the major discussions happening in autonomous driving today.

So, are panels doomed?

Are panels doomed in the age of AI?

My answer is no. At least not yet.

The LLM answers are on par with — and in some ways more polished than — the answers I heard during the panel. But I think something important is missing.

Experience.

An LLM can synthesize what the field currently believes. It can identify the dominant narratives: data scaling, long-tail coverage, world models, closed-loop evaluation, simulation, safety, and so on.

But when you have actually worked on a problem for years, you experience something that is difficult to capture in a single answer:

You see how the bottleneck moves.

And I think this is where the answer to the original question becomes much more interesting.

The bottleneck keeps moving

Having worked on E2E driving for a few years, I would not answer the question by picking a single block. I would describe E2E development as a sequence of changing bottlenecks.

At the beginning, the key challenge is often simply data. Once you have enough of it, you can already make considerable progress. Let's say, purely for the sake of argument, that you can get to 50% of the desired performance. At this stage, data is king.

But eventually, adding more of the same data stops giving you the same gains. You start needing more relevant data rather than simply more data: different scenarios, different environments, different interactions, different behaviors, and especially the rare cases that actually challenge the system. At some point, another hour of straight highway driving is worth almost nothing.

The bottleneck has shifted from data volume to data diversity and coverage. Perhaps this takes you from 50% to 70–80%.

Then something else happens. As the system becomes better, it becomes increasingly difficult to determine whether one model is actually better than another. You have squeezed most of the easy gains out of the data. Improvements become smaller, failures become rarer, and open-loop metrics become less representative of actual driving quality.

Now evaluation becomes the bottleneck. Perhaps this takes you toward the 90–95% region.

And throughout all of this, there is another ingredient that doesn't disappear: execution. Good data pipelines, good infrastructure, good engineering, good experimentation, good evaluation, fast iteration, and the ability to turn research ideas into a reliable product all matter. Execution sits on top of every stage.

And then things get interesting

Once you reach a sufficiently high level of maturity, the question becomes much less obvious. Beyond, say, 95% — again, these numbers are illustrative rather than quantitative claims — the field starts to diverge.

This is where some of the current debates at ECCV become particularly interesting. Different companies and research groups are making very different bets:

• World models — latent, video-generative, and otherwise
• Vision-language-action models
• Self-play and other forms of interactive learning
• Better simulation
• Better data engines
• Reinforcement learning
• New approaches to planning and reasoning

At this point, asking “What is the single most important block?” may no longer have a meaningful answer. The bottleneck has become much more dependent on the specific system, company, data, product requirements, and stage of development.

And this is where the difference between an LLM answer and an experienced practitioner becomes particularly interesting.

Knowledge synthesis vs. experience

The LLM answers are impressive because they capture the current conventional wisdom extremely well. Ask an LLM what the bottleneck in E2E driving is, and it can tell you about closed-loop evaluation, world models, long-tail scenarios, safety, simulation, and counterfactual reasoning. Those are all legitimate and important topics.

But an experienced practitioner can add another dimension:

Why did this become the bottleneck?
What was the bottleneck before?
What did we try that didn't work?
What became irrelevant once the system improved?

And perhaps most importantly:

What do we think is the bottleneck today that might look completely different two years from now?

That context is difficult to get from a single answer.

So what ultimately wins?

I don't think the answer is simply “world models,” “VLAs,” “self-play,” or any other particular technology.

Technology determines the space of possible solutions. Execution determines how far you actually get with them.

Two teams can have access to essentially the same model architecture, the same papers, and even similar compute resources, yet achieve very different results. The difference can come from the data engine, evaluation methodology, infrastructure, engineering culture, iteration speed, product constraints, and — perhaps most importantly — knowing which problem to solve next.

So if I had to answer the original panel question today, I wouldn't pick a single block. I'd say:

The most important block is the one that is currently limiting you. And that block changes as the system matures.

Early on, it may be data. Then data diversity. Then evaluation. Throughout the journey, execution. And at the frontier, perhaps an entirely new learning paradigm.

What panels are for now

Are panels still useful? Absolutely. But perhaps the role of the expert panel is changing.

The value of an expert panel is no longer necessarily in producing an answer that an LLM cannot produce. An LLM can often produce a very good answer. The value is in explaining why the obvious answer is incomplete.

An LLM can tell us that closed-loop evaluation is the bottleneck. A practitioner can tell us that it wasn't always the bottleneck, why it became the bottleneck, what we did before we had good evaluation, and what might replace it as the next bottleneck.

Perhaps that is the real value of experience in the age of AI.

Not knowing an answer that AI cannot know, but knowing why the answer keeps changing.

Back to all posts