经济增长的底层逻辑、AI生产力悖论与通用技术分析

Speaker: Growth in the economy happens either because we can add more capital and labor to the existing economic system, or because we find better ways to transform labor and capital into economic output. Economists call this latter improvement productivity growth. From a long-term perspective, the primary engine driving economic growth is precisely this advancement in productivity, which in turn has always been intimately connected with improvements in technology and organizational methods. And this is exactly where I want to start drawing parallels from historical reality to address the puzzle of AI productivity that I mentioned at the very beginning. We can look back at technological revolutions in history—such as the Industrial Revolution—to find very good benchmarks for understanding what to expect from artificial intelligence.

(Transcript Source: 経済における仕事、なぜなら私たちはできるから資本を追加するすでに経済において、またはなぜなら私たちは最高のこの変化労働と資本経済的な製品。そしてこれが経済私たちはそれを成長と呼ぶ生産性。そして長期視点メイン経済の原動力成長とはまさにこういうことだの業績生産性、今度は、改善点テクノロジー、そして組織において進歩は、彼らと繋がっていた。そしてここが私の居場所だ。引き寄せ始める実際のストーリー類似点を指摘するパズルAI生産性、私が言及した始まり。)

Speaker: The Industrial Revolution, as is widely recognized, initiated modern economic growth. However, when we observe its historical trajectory, we notice a fascinating and very similar regularity: the steam engine, which was the central foundational technology of that era, contributed almost nothing to measurable productivity growth for decades after its initial invention. In fact, more than a century elapsed from its first invention before the substantial gains in productivity and economic growth were visibly reflected in historical data.

(Transcript Source: 我々はできる、例えば、私はこう思う。非常に良い比較頭を持つAI例技術的な歴史上の革命—工業回転。ええと、産業革命すでに述べたように、現代の経済成長。しかし、私たちは私たちは何かを観察します類似していて興味深い規則性と彼女。蒸気機関、そのメイン基地テクノロジーはほとんどない何も与えなかった成長生産性多くの人にとって彼女が数十年後発明、そして実際に合格しました100年以上前見たものよりも生産性と経済成長反映されているその後のデータ発明。)

Speaker: All right, let us look at a brief slide about technology. In economic history, there is a general class of technologies characterized as General Purpose Technologies—interestingly abbreviated as GPTs. While this abbreviation happens to be a fitting match for our current conversation, General Purpose Technologies in economic literature typically possess three defining attributes. First, they are pervasive, meaning they find applications across virtually every single sector of the economy. Second, this class of technology continues to improve over an extended period of time. And the third, highly crucial point is that they possess strong complementarity.

(Transcript Source: わかりました、短いスライドについてテクノロジー。で経済史一般クラスがあります技術と表現されるテクノロジー一般的な予約は経済史、かなり面白い、GPTと呼ばれる。そしてこれこれにぴったりのマッチ会話だが、テクノロジー一般的な予約は通常３つの属性を持つ。それらはどこにでもある、つまり適用事実上すべての経済の各分野。この技術は改善する長い間期間。)

Speaker: Complementarity means that technological progress in the core innovation enhances downstream applications, and improved applications in turn increase the value of the initial technology that enabled their creation. In other words, a General Purpose Technology yields economic benefits that compound over a very long duration. And the crucial question—the answer to which lies between historical precedent and future unfolding—is whether our engineering of AI will truly emerge as a General Purpose Technology capable of realizing this full potential. While there is no definitive official list, historical examples widely regarded as General Purpose Technologies include the waterwheel, the steam engine, railways, electricity, and the computer.

(Transcript Source: そして3つ目のポイントで十分です興味深いのは、彼がつまり、持っている相補性。そしてこれはつまり技術の進歩リターンアプリケーションは改善、そして改善しているアプリケーション、これ、順番に、価値を高めるイニシャルテクノロジー彼らを助けた作成する。その他言葉で言えば、テクノロジー一般的な予約は利益を得る経済は非常に長い間。そして重要な質問です、答えは歴史か未来か、かどうか私たちのAIになるエンジニアリングGPTテクノロジー一般的な目的、能力これを実現するために。それでも公式リストには載っていない存在する、技術に対して、しばしば考えられているテクノロジー一般的な予定、例えば、水車、蒸気車、鉄道、電気またはコンピューター。)

Speaker: Furthermore, there is another key concept that I want to touch upon briefly and keep at the forefront of our minds. There exists another distinct category of technologies: those that fundamentally enhance the very methodology of conducting research and driving future development. These innovations stimulate long-term productivity growth by expanding our capacity to discover new knowledge. Historical examples of this category include the printing press, the microscope, and the institutional invention of corporate and university research laboratories. Today, we observe artificial intelligence and machine learning functioning in precisely this domain.

(Transcript Source: そして、友人もいる。私が考えたアイデア簡単に触れておきたいそしてそれを保管するために頭。これは他の種類もあります技術私たちを助けてください方法を改善する実行する研究との発展未来。だから、これらはイノベーションは私たちを助けてください刺激する成長生産性未来。そしてその中で例えば、イノベーション、例えば印刷機、顕微鏡、発明企業または大学研究私たちがまた、今ではAIの分野で、または機械技術教えること。)

Speaker: There are solid reasons to view AI as belonging to both categories of technology simultaneously. It is at once a pervasive General Purpose Technology whose potential is far from being rapidly exhausted and which will drive economic expansion for a prolonged period, and a technology applied directly to recursive self-improvement and the process of scientific invention itself. We have seen striking demonstrations of this over recent weeks, for instance in automated mathematical reasoning. When we consider how this might eventually uplift human living standards, the implications are truly breathtaking.

(Transcript Source: AIについて正当な理由があるこれら両方を考慮する技術の種類同時に。それ同時に遍在するテクノロジーほとんど速くない使い果たす潜在能力があり、刺激する経済成長長い間時間、そしてテクノロジー、どちらが使用する自己改善発明の過程。そして私はその間ここ数週間で例えば、数学。そして私は思う、これはとてもワクワクしますね。これを考慮するとレベルに応じて与えることができます人生。)

Speaker: Turning to the chart displayed on this slide, over the past 150 years the United States economy has grown at a remarkably steady rate of roughly 2% per year on a per-capita basis. You can observe how tightly the long-term trend line holds. Certain intervals saw faster growth, other periods experienced slower growth with regular ups and downs, but on average across 150 years, that 2% annual rate has remained remarkably consistent.

(Transcript Source: ところで、お元気ですか？このスライド上のグラフィック、過去150年間米国経済成長した安定した年間2％の割合で一人当たりの計算人口。分かりますか、トレンドラインが非常にぴったり合う。期間によってはより速い成長、期間によっては遅いです、浮き沈みなど。しかし平均的には、150年で十分だ安定して2％。)

Speaker: Note that the vertical Y-axis uses a logarithmic scale. Because it is logarithmic, every equal step on the axis represents a doubling in actual value. A 2% annual growth rate might not sound like a huge number in the abstract—if you invested capital and received only a 2% return in a single year, you would likely not be ecstatic. However, this is compound exponential growth operating over an extended timeframe. Consequently, over the 140 to 150 years shown on this chart, inflation-adjusted per capita income has increased roughly tenfold.

(Transcript Source: うーん、これは対数スケール、はい、Y軸です。対数なので、すべての線形変化実際には倍増。成長年率2％で、ええと、あまり良い音ではない多くの。もしあなたが投資したお金を受け取り、2％1年間なら、おそらくあまり嬉しくなかったが、これは、複雑なパーセンテージ成長中長い間。したがって、この150年間グラフィック、140年間このグラフでは、収入を見ると人物、考慮に入れるインフレなどが増加した約10回。うん。)

Speaker: And to my mind, this demonstrates precisely what is required simply to sustain that 2% annual rate. The era between 1880 and 2020 was an age of unbelievable innovation. In fact, virtually all the foundational modern technologies that we admire and depend upon today were invented during that exact window: automobiles, commercial aviation, space travel, modern biotechnology, the internet, and many others that could readily be added to the list. Yet in the final accounting, aggregating all of these profound breakthroughs together served to sustain an average per-capita economic growth rate of 2% per year.

(Transcript Source: そして私にとってそれは必要なものを示す2％を達成する成長。そうだった信じられない時代1880年から2020年までのイノベーション年。実際、すべて現代のテクノロジー、私たちは何者なのか私たちは賞賛します今日、まさにその時発明された。自動車、航空、宇宙旅行、バイオテクノロジー、インターネットはそのうちのいくつかは、そして私は思うのですが、追加できますこのリスト。そして最後に、これらすべてを合わせると、平均身長米国経済は2％減少年。)

Speaker: Looking ahead, AI could accomplish two distinct things. First and foremost, it can underwrite this historical trend, ensuring that the 2% trajectory persists over a substantially longer horizon. In my view, that in itself would already be a monumental achievement, because maintaining a constant 2% rate over time requires an ever-increasing pace of technical innovation. But the far more fascinating question is whether AI might fundamentally accelerate this growth process.

(Transcript Source: 今やAIは2つのことをする。の上-まず、彼はこの傾向を支持するそうすれば彼は続くより長い期間時間。そして私はこれがすでに大きい達成、なぜなら我々は、技術レベルイノベーションが必要だちょうど年間2％を維持する。しかし興味深いのは、おそらくこれを加速させるプロセス。)

Speaker: At present, there is no unanimous consensus among economists regarding what trajectory we should anticipate from this graph going forward. The range of estimates spans from the highly conservative—projecting an incremental GDP growth contribution of merely 0.1 percentage points per year above the historical trend—to aggressive models that incorporate recursive self-improvement and AI intelligence explosion dynamics. Those latter economic models contemplate growth potential accelerating into the high single-digit percentage points, as illustrated in the upper bounds of this projection. If we were to find ourselves operating under such a new paradigm over the coming decades, the resulting improvements in living standards would be genuinely staggering.

(Transcript Source: 現在経済学者はいない満場一致の意見何が期待できるかこのグラフから未来。評価範囲はミニマルGDP成長率0.1パーセントポイント年間平均を上回る傾向。しかし、経済学者のモデル、考慮に入れる再帰的自己改善、ある種の「知的AIの「爆発的成長」は、仮定する成長機会一桁台後半パーセントポイント、ご覧のとおりこのグラフ。そしてレベルが人生は時とともに成長していくご覧のとおり、新しいモードで私たちは成長しています私たちはその間に自分自身を見つけるでしょう次の数件何年も経つと、本当に驚くほどのお買い得価格生活水準のために。)

Speaker: Let us now go back and start from the history of the Industrial Revolution, which is where any rigorous discussion about foundational technology ought to begin. The steam engine stands as the canonical technological innovation of the Industrial Revolution. In fundamental principle, it decoupled machinery from reliance on human muscle, draft animals, and the physical location of rivers, thereby making it possible to generate mechanical power at immense scale and in locations far more flexible than had ever been previously possible.

(Transcript Source: よし、じゃあ行こう。戻って歴史から始めましょう工業革命、そこからすべてが開始すべき時私たちが話しているのはテクノロジー。スチームこの車は正統派です技術的な革新工業回転。原則として彼女は手伝った別機械の作成筋肉からのエネルギーと川、そして可能になったエネルギー生成大規模かつはるかに小さい場所によって異なるこの場所よりもそれは以前のことだった。)

Speaker: The steam engine was first invented in practical form by Thomas Newcomen in 1712, and then notably improved by James Watt—whose name everyone knows—later in that same century. However, the technology required substantial time well into the nineteenth century, continuously undergoing refinement, before it could be widely adopted across the broader economy, heavy industry, and manufacturing plants. Only after high-pressure steam boilers became prevalent and energy costs plunged by orders of magnitude did we finally witness undeniable, measurable surges in productivity and GDP figures within economic statistics.

(Transcript Source: 初めてそれはトーマスによって発明された1712年のニューコメンとそして、ジェームズによって改良されましたワットという名前は少なくとも誰もが知っている、その後同じ世紀。しかしテクノロジーたくさん19世紀までの時代世紀、続く改善するために、彼女が広く実施されている経済、産業と工場。そしてその時初めて、いつ拡散したのか高圧蒸気ボイラー圧力と価格エネルギーが落ちた数桁の規模で、本当にできた成長を見る生産性と統計におけるGDP。)

Speaker: Thus, the steam engine had to become dramatically superior across a prolonged gestation before we could deploy it at full societal scale. Furthermore, it became genuinely transformative only when a dense web of complementary innovations and infrastructure was implemented around it—such as precision machine tools, railways, steamships, and a newly qualified industrial workforce. It required an entire economic ecosystem to evolve in synergy. That holistic transformation is what we truly mean by the Industrial Revolution: the revolutionary statistical metrics we observe in retrospect were driven by real changes in how ordinary human beings lived and worked every day.

(Transcript Source: それで、蒸気機関こうあるべきだった劇的に良くなった技術長期間私たちが開始することができました使用方法あらゆる規模において。そしてそれらは役に立つようになった発明とその実施追加項目—新規工作機械、鉄道、蒸気船と新しい資格のある労働力彼女の周りでは全体を発展させる経済システム、そして産業革命これは私たちが知っていることであり、変革的我々が見る変化数字は本物働くために人生を変える人々。)

Speaker: This provides a very telling historical observation: a foundational technology demands a great deal of time to diffuse and reshape the broader economic system. In the case of the steam-powered engine, first invented in 1712, notable surges in macroeconomic productivity did not materialize until around the 1830s. More than a full century elapsed before the profound ultimate results became visible in the empirical record.

(Transcript Source: よし、たぶん。これは、面白い観察。テクノロジーは非常に、たくさんの時間彼女が広がるそれは発展するだろう経済システム。で蒸気の場合車で、初めて1712年に発明され、顕著な成長生産性1830年にのみ登場年が経過しました。100年以上前私たちが見たものよりも結果。)

Speaker: Consider another historic parallel: the electrification of the United States. Thomas Edison commissioned the first central electric power station in New York, the Pearl Street Station, in 1882. Yet it took approximately 30 to 40 years before significant, pervasive electrification took hold across American manufacturing factories. And this delay was not primarily about fine-tuning the electrical generation technology itself; rather, it was driven by the necessity of completely restructuring factory architecture around where and how power was consumed rather than how it was generated.

(Transcript Source: 他の人たちへ例えば電化アメリカ合衆国。トーマス・エジソン最初のニューの発電所ヨーク、パール駅1882年にストリートで。しかし約30～40年で少なくともいくつかは重要な電化米国の工場州。そして今回は改善する必要ではないテクノロジーですが、実際には必要だった工場再編エネルギーが消費されたのではなく、作成中です。)

Speaker: Traditional factories built prior to electric motors were engineered strictly around a single central steam engine, forced to rely on one centralized power source. You can see an illustration of this in the graphic at the bottom right, which I generated using Grokbot. In that configuration, a solitary prime mover powered every single machine throughout the entire facility. Power transmission relied on an intricate web of belts, pulleys, and overhead drive shafts mechanically linked to every workstation. Consequently, factory designers had to plan the entire facility around the rigid physical constraints of mechanical power transmission, which dictated multistory vertical brick buildings where machinery clustered tightly around the central vertical driveshaft.

(Transcript Source: えっと、工場以前の蒸気機関に携わったエンジンと設計されているので1つ使用する電源。そして部分的に彼らにそれを見る下の画像右へ、私はどれですか、作成者Grokbotを使用しています。うーん、そして情報源は一つだけだった電源とは基本的にすべてを実行に移す工場にある機械。つまり、ある情報源は電源接続済みベルトとシャフトすべての車工場、えーと、その、原則として、えっと、何をしなければならなかったのですか、工場を計画して彼が答える伝達方法その中にエネルギーが宿っている。そしてまた工場では建てられた垂直に、いくつかの階。)

Speaker: Under that legacy architecture, if factory owners merely replaced the single central steam engine with a large centralized electric motor, it was hardly an optimal arrangement. The profound advantages of electricity were only truly unlocked when engineers began exploiting its unique inherent characteristics. The paramount advantage of electricity is that energy generation can be located entirely apart from the point of consumption, freeing equipment from rigid mechanical attachment to a central shaft.

(Transcript Source: えっと、でもあなたはすぐに蒸気を交換するエンジンオン電気、えーと、これ最高ではなかったある意味で工場出荷時の設定、入手可能な場合電気。えっと、そして電気本当に明らかになった彼らの最大の利点できた使ってみて個性的特徴。そして独自の利点その電気技師たちそれは生成できますそこ以外のどこかで、消費する場所。)

Speaker: This insight gave birth to the concept of the "unit drive" system, where each individual piece of machinery on the factory floor is equipped with its own dedicated electric motor. The operational benefits were immediately evident. Under the older group-drive setup, shutting down the central steam engine meant the entire factory ground to a complete halt. With individual unit drives, if a single machine needed to be turned off for maintenance, you simply switched off that one unit's motor, leaving the rest of the facility fully operational.

(Transcript Source: ええと、それによっていわゆるシステム個人理性とは、本質的には、それぞれが工場の機械には、ええと、情報源の一つは餌やり。そして私は思う、利点が非常に明白すぐに、なぜなら今、もし、あなたが、あなたができるなら1つだけオフにする車。システム内でグループドライブ、オフにすると蒸気機関、全体工場が停止する。オフにするとモーター1つ、電動モーター車の場合、これだけ車が1台必要です消す。)

Speaker: As a result, architects could begin planning factories strictly according to operational workflow logic, rather than around overhead shafts and pulleys. Facilities could be built as single-story horizontal layouts that were far easier to expand, retool, and reconfigure for new production lines. Nevertheless, this was an inherently slow and capital-intensive transformation requiring the complete re-equipment and redesign of entire manufacturing floors. It was only about 50 years after Pearl Street, by the late 1920s, that more than 80% of manufacturing energy in factories was finally derived from electricity.

(Transcript Source: だから、あなたは始めることができます工場を計画するあなたのワークフロー、そしてそれによるとそうではないパスポートはどこに保管すべきですか？そしてシャフト。あなたはできる拡張するのは簡単です。あなたはできる再装備するために、始めることができます何か別のものを生み出すために、しかし、それは遅く、費用のかかるプロセス必要あらゆるものの再装備工場ではなく工場で消費され、そして50年後には80％エネルギー消費工場、受け取った電気から。)

Speaker: Moving closer to our own modern era, we encounter the famous adage from economist Robert Solow, who famously observed in 1987: "You can see the computer age everywhere but in the productivity statistics." When he made that remark in 1987, personal computers were indeed becoming ubiquitous, and computing hardware was already being deployed widely across the economy.

(Transcript Source: 私たちは少し先に進みましょう。私たちの時代に近いえーと、まずは有名な名言経済学者ロバートソロウは、えっと、どこにいるんですか？あなたができると書いたコンピューターを見る時代は、統計生産性。そして彼は1987年にこう言った。個人的なコンピュータはすでにどこでも、そして計算十分な装備広く使用される経済。)

Speaker: As is well understood, the second half of the twentieth century witnessed astonishing innovations in computing technology. Personal computers, network communications, and the internet converged into information technology, drastically lowering the marginal costs of processing, storing, and transmitting data. Yet it was not until the mid-to-late 1990s that aggregate economic productivity began to measurably surge in response to these investments.

(Transcript Source: ええと、私も私は思うよく知られているように、20世紀後半世紀に私たちは見た本当に素晴らしい革新計算テクノロジー、個人的コンピューター、インターネットはこれらすべてを合わせると、情報提供テクノロジー、急激にコストを削減処理、保管移籍情報。しかしかかるまで1990年代半ば～後半年、生産性本当に反応したこれについて。)

Speaker: The fundamental reason was that the economy once again demanded profound structural adaptations, and this time those changes were predominantly organizational. Enterprises and employees had to overhaul business processes, master new skill sets, and cultivate effective methodologies to genuinely capture the value inherent in computer technology. This required the development of critical complementary innovations—such as enterprise software, relational databases, and the complete redesign of supply chain logistics around digital tracking and inventory control methods.

(Transcript Source: そしてまた、経済特定のものが必要変更、そして今回はそれらはほとんど組織的。したがって、企業と従業員は彼らのプロセスを開発するスキルと正しい方法を実行するさらに、本当に理解する恩恵を受けるコンピューターテクノロジー。そしてこれかつては、例えば、開発…まあ、他の企業にとっては作成する必要があった企業ソフトウェアソフトウェア、データベース技術、サプライチェーン必要再設計使用デジタル手法商品の会計処理。)

Speaker: Naturally, this also entailed the extensive rollout and organizational integration of countless individual pieces of hardware and software packages across the labor force. In practice, the organizational transformation of business operations progressed at a vastly slower pace than the invention of the raw computer hardware itself. Yet it was ultimately this painful organizational restructuring that finally enabled modern computing to impact the economy in an undeniably significant manner.

(Transcript Source: えーと、もちろん、それも受け入れを意味するおよび実装たくさん、たくさん個々のユニットハードウェアとソフトウェア規定従業員経済。そして実際ははるかに遅い変換組織よりも彼ら自身の発明のみコンピューター最終的に-ついに私たちに役立ちましたこれを使うテクノロジーは本当に重要な経済的な方法で、この接続)

Clemens: Is it this connection, or is it the pattern we are developing and observing here—what is often described as the 'investment J-curve'? To implement a new technology initially, the necessary investments—training on new processes, purchasing new equipment, reorganizing workflows—actually decelerate productivity growth at first, only for it to speed up significantly later down the line. And I also want to touch upon another dimension: technology is often out of sync with other macroeconomic factors, namely the capital markets. Throughout history, truly revolutionary technologies have always possessed the power to attract enormous amounts of capital and early resources during their inception, long before we actually figure out how the technology begins to tangibly stimulate real economic growth.

Clemens: I would like to highlight two historical parallels alongside the current rollout of AI and compare them, at least in terms of relative economic scale. The first is the 1840s in Britain—the Railway Mania. Over those pivotal years, Parliament authorized the construction of hundreds of new railway lines. What took place was remarkable: a desperate hunt for cheap capital driven by sheer investor fervor, occurring simultaneously alongside a genuine surge in freight transport demand—particularly for coal—and the pressing need for inland cities to connect to the national economy via rail. Together, this triggered an unprecedented investment boom with virtually no historical precedent. It stands as one of the largest capital booms in history, with railway investment reaching an astounding 5% to 7% of British GDP in a single year during the 1840s.

Clemens: Another closer historical example comes from digital technology in the late 1990s—computers and the internet. In the late 90s, the commercial internet began expanding rapidly. The deployment of major long-haul fiber-optic networks enabled broadband access on a massive scale. Major deregulation was taking place in the United States, spawning an influx of new telecom operators and enterprises that laid vast amounts of fiber-optic cable, driven by expectations of unending exponential data demand that resulted in drastic infrastructure overbuilding. That boom represented approximately 1% to 1.5% of US GDP in 1999. Today, if we compare this to the expansion of AI: investment in artificial intelligence infrastructure has already reached roughly 1.8% of US GDP. That means this year it has already surpassed the peak fiber-optic boom, and projections indicate that by 2028, AI infrastructure capex will reach around 3% of US GDP. In other words, AI infrastructure is already on par with the very largest investment booms witnessed in all of economic history.

Clemens: Now, does this mean we are in a 'bubble'? To be frank, I cannot give a definitive conclusion, and no one truly knows for certain. But in my view, there is a vital historical observation to keep in mind: regardless of what ultimately happens to the private returns of the investors pouring money into this infrastructure today, the ultimate result may prove to be extraordinarily durable and productive for our future, even if this is indeed a bubble right now. Just as with the surplus railway tracks in the 19th century or the 'dark fiber' left behind from the dot-com era, those massive investments subsequently provided vastly cheaper transportation and directly enabled streaming and mobile telecommunications decades later, precisely because that infrastructure was already built out and made cheap.

Clemens: This brings me to a clear model that I hope to convey: technology develops along two distinct, mismatched timelines. The first timeline is fast: it is the technology schedule of pure innovation, rapid prototyping, and transformative model releases. The second timeline is substantially slower: it is the schedule of real-world implementation, where technology must become deeply embedded into enterprise structures and the macroeconomy as a whole. In the age of steam, early breakthroughs were engines, but the real impact required decades of fundamental engineering diffusion. With electricity, it wasn't just generating power, but inventing entirely new factory designs and assembly lines to complement the technology. And for computers, the true gains were primarily driven by massive organizational restructuring, new skills, new operating workflows, alongside the extensive rollout of hardware and software.

Clemens: We are now four years into the era of Generative AI, and I want to invite all of you to reflect on what is truly missing for AI to finally drive measurable productivity gains and widespread economic growth for everyone. Is it a breakthrough in foundational technology and basic models? Is it deeper enterprise adoption across sectors of the economy that currently remain largely untouched? Is it supplementary work at the applied application layer? Or is it comprehensive workforce retraining? I do not pretend to possess all the definitive answers, but I would be thrilled to discuss this with anyone here over the next two days of this event.

Clemens: To summarize, I hope I have made the case that technological invention creates initial opportunities, but converting those opportunities into real growth requires far more: diffusion, sustained capital investment, complementary additions, and organizational change. That is what translates raw technology into tangible productivity and improves living standards for all people. The implementation of AI inside enterprises, changing operating principles, workforce retraining, restructuring how individuals work, and launching entirely new companies from scratch around novel ideas—that, in my view, is how technology truly moves forward. And that should be an incredibly encouraging message for everyone in this hall, because I believe most of you spend your days doing the vital work of restructuring this economy for this new technological paradigm. Thank you very much for your time. Have a wonderful conference.

Host: Thank you, Clemens! Give him another round of applause, please. Wonderful. I always love examining how we can extrapolate from the past to understand and predict the future, and Clemens provided great perspective on how we should contextualize the present. Our next speaker is going to tell us about the future—in fact, our next two speakers will be discussing the future. The next speaker truly needs no introduction. If you spend time on social media networks, if you are active on X, you have undoubtedly seen his razor-sharp commentary. He describes himself as a 'thought leader'—I still don't quite know what that means, but let's just roll with it, alright? So please, give a warm welcome to Balaji! Congratulations, welcome to the stage!

Balaji: Alright, awesome! This setup might be glitchy, but let's give it a shot and make it work. Boom, slides are up. Can everyone see them clearly? Perfect. I just realized the gravity of this introduction—it makes me sound like some revered 'thought master.' But in reality, we built this entire community simply to tinker with cool things, and I will share more about that in just a second. Can we kill the background music? Is there music playing? Great, music is off. Fantastic. Look, I am essentially a child of X. If you know me from X, we probably agree on a whole lot of things, and we have likely argued over plenty of others as well. I could easily show twenty slides; in fact, just a few minutes ago while ordering an Uber, I thought: you know what would be fun? I'll just drag the cursor over here, click start, and dive right in.

Balaji: Usually, across about 39 conferences, I talk in detail about specific products I build. This time is completely different: I am presenting just a single slide. If you are someone who enjoys tinkering with local LLMs, hardware hacking, self-hosting, and home labs, we run an awesome community called tinker.club. The URL is right up there. In fact, pretty much everyone attending this event is an embodiment of that ethos. It is fascinating to see such diverse people unite around shared technical obsessions—ranging from raw hardware and 3D printing all the way to AI, SaaS, and building their own ventures. If you want to join, head over to tinker.club.

Balaji: At the previous AI Engineer conference, I gave a talk titled 'From Vibe Coding to Vibe Engineering.' We were already navigating a major transition back then. If I delivered that exact presentation today, it would still be entirely relevant, because a massive number of people are only now making that journey from chaotic vibe coding to disciplined vibe engineering. But I can already sense the next fundamental shift happening within myself, inside my own applications, and across the developer ecosystem. I watch everything unfolding on Twitter, and we are gradually moving into a completely different echelon of AI engineering. You have likely heard buzzwords like 'software factories,' or what I affectionately call 'slop factories.' Throughout Q4 of this year and into next year, the conversation will shift entirely away from old-school vibe coding toward something radically new.

Balaji: Before we unpack this 'something new,' we need to take a step back and examine where we have been over the past year. Plenty of people are still using Copilot—pressing the Tab key to trigger an autocomplete, thinking, 'Wow, this is AI.' But for us, that feels like a lifetime ago. For a long period, we were stuck in the manual loop of copying and pasting back and forth with ChatGPT. If you recall, a couple of years ago the models couldn't even finish long functions; you had to literally plead with them: 'Please, just finish the function!' You waited anxiously for the second half, copied it, and stitched it together. Then came the agonizing battle for pure JSON: 'Can you please omit the markdown formatting? I just need raw, parseable JSON.' And it would invariably respond: 'Sure thing! Here is a little markdown and some JSON inside.' Developers who are just getting started with modern AI tooling today have no idea how utterly spoiled they are.

Balaji: Then came the phase of focused in-line editing. Mind you, there were no autonomous agents yet; we were simply using AI that could directly modify your local files, and our immediate reaction was: 'Whoa, this is dangerously powerful. It can touch my filesystem!' Soon after, agents arrived. Yet initially, we were extraordinarily paranoid, meticulously checking every single permission prompt and warning ourselves: 'Careful, don't let it touch anything critical!' Fast forward just one year to today: when an agent asks, 'Can I execute this shell command?' who among us actually reads it? You think, 'Where did that even come from? Do I really care? Yeah, sure, whatever, just finish the job.' Now everyone is running in full-blown YOLO mode. I literally do not know a single engineer today who doesn't grant agents unrestricted system access: 'Here, take my local database, take my customer data, forget GDPR compliance, just take everything and get the job done.' That is the reality of where we have arrived.

Balaji: Looking at the developers currently building with AI, they primarily fall into a few distinct archetypes. First, we have the 'Garbage Grenade Throwers'—and let's be completely honest, most of us belong to this category to some degree, even as we try to pretend otherwise while hurling these grenades across the office. Second, we have what is brilliantly referred to as 'Meat Substitutes.' Have you heard this term before? It is easily one of my absolute favorites that has emerged recently; I love it. And finally, there is a tiny minority of true, disciplined software engineers, and we are all collectively striving to transform ourselves into genuine AI engineers.

So what exactly does a 'garbage grenade thrower' do? It is what people do all day long: because AI is so blazingly fast and frictionless, you throw a half-baked prompt at an agent, it generates a giant pile of unvetted garbage, and without even reading it, you immediately chuck it over the fence to your colleague. You say, 'Shipped! Good luck! Hope production doesn't blow up, figure it out yourself!' And then you have the 'meat substitutes'—when someone doesn't actually understand what needs to be built, but simply acts as human middleware sitting between a manager or executive and an LLM. Whatever leadership asks for, they take the request verbatim, feed it straight into the model, and take whatever hallucinatory output comes out, barely glancing at it before passing it along...

演讲者: それを返してください。だからあなたはあなたはただ役を演じているだけです「肉の代用品」、そして今ではとても多い企業、そしてこれ変更する必要がある、それらはレイヤー、レイヤー、そしてさらに単なる「肉」の層「プロキシ」通信するあなた自身。そして私は思う来年は残酷なのは、多くの人が目覚めるのは誰この現実の鏡に近づき、「ああ、しまった」と言うだろう。そして彼らリリースされます。それ必然的に。私は話しました。これについて彼らのスピーチ、そして私は思うこれはどこかで起こるだろう来年。真のエンジニア本当に頑張っていますビルドシステム彼ら自身の周りでプロセスではないが、そこにいないのは誰？適切なシステム。この会話は私がここまでたどり着いた方法。

演讲者: 私私は二つの陣営の人々を目にする。。それは常に分裂の原因だった。つまり、私たちは「「デスクトップ」の人々は CLIの人、ハッカー、思想家たち ...物事、私はいつもターミナルが大嫌いだった。私 CLIは昔から大嫌いだった。私大嫌いだった。ほら、私にちょうだい。素敵なインターフェース、どれを押せばいいですか？。私はいつも嫌いだったこれらを本来あるべき場所に置く何かが絶えず私をひねる驚くべきことに

演讲者: 過去 3年間非常に多くのものが現れたオーケストレーターからカーソルを指揮者などに移動します。全て。そして誰もしようとしているより良い。簡単だ。コピー＆ペースト同じレイアウト。左側サイドパネルグラフ。あなたの真ん中にグラフ。おっしゃる通りです。 git diffを取得できます。そしてみんなはこう言う、「私たちはただ 3700万ドルを調達新しいオーケストレーター」。そしてスクリーンショットでは、あなたはこうなっています。「これはコーデックスですか？これはカーソルですか？これは…これは「同じことか？」いつも。そして誰も試みる。私お見せしてみます。あなたの選択肢スピーチの最後に、見てみましょうきっと気に入るよ。あなた使用一般的なツールそして私は常に私はあちこち移動する。

演讲者: デスクトップを起動しますアプリケーション、そして私は CLIに戻ります。そしてまた本物がありますクレイジーだわ、もしあなたが「オーマイパイ」という言葉は聞いたことがありません。グーグルで検索すらしないでこれで終わりだ。しかし、「オーマイパイ」って何？牧畜民の中で、「オーマイチェーン」の中で、内で仮想マシン、 Proxmox内部。そして彼らに何を尋ねますかリリースされ、彼らは「でも私の「工場は稼働しているようだ。」だから私はこれらすべてを批判した。私いつもあれらが嫌いだった自撮りをする人ホスティング。私はいつもは Vercel、鉄道または他の誰に対しても。ないどうぞご自由に自分を騙してください。そして私は完全に反対側へ渡ったシンカークラブと共同で。のために人数が増えるほどそれについて書く、私ももっと欲しいです。作る。だから私は Linuxマシン、Tailscaleおよびナンセンスの集まり、エッセンス。

演讲者: そこで、ツールと方法。話し合いましょう。方法についてですが、 2種類ありますツール : CLIとデスクトップ。そして私たちには実際に方法があります。私はそれらすべてに目を通し、今からお話しします。それは止まった。 1つチャットしてプロンプト勝利。これはまるで、私は開けるのをやめる。多くのチャットさまざまなタスク、そしてそのままにしておきます。特にスマートなコーデックスに封印する、私はもう諦めてもいいよ。キューに並んだたくさんのもの、そしてどこにいるのかさえ分からない。圧縮されています。

演讲者: どうやらそれは報告しない圧縮を実行します。だから、簡単なことなんです。働き、世話をする次のタスク、そして次のもの、そしてまた次のものへと続きますさらに遠く。効果があり、結果を生み出すが、タスク間に時間がない管理なし、例えばサブ検証のためのエージェント、そしてもう 1つはテスト中。あなたはただそう願うすべてを確認しますタスクを完了するみんな。私はそれが好きです。好き、そして同時に、それほど多くもない。次に、次の選択肢があります。 1対 1のチャットあなたが持っているタスク Codex内のフォルダ、または他の場所、そしてすべての人々のためにあなたにタスクを新しいチャットを開始する。しかしそうでない場合は使用ワークツリー、あなたは推測するかしないか機能が追加されます衝突する、または使用ワークツリー、そして次に床での別の会話これらによって、何らかの形で従業員を管理する木々。それで、少し散らかっている。さらに遠く私たちは木々を育て、より良い。ちなみに、誰もワークツリーについてはまだ知らなかった 7週間前、はいなぜ黙っているのですか？さあ皆さんワークツリーを使用する、みんなが Gitになったエンジニアの皆さん、よくある話ですよね。しかし問題は、それはまだ完全に孤立しているシステム。それはまるで別の Gitは確かに存在するが、破壊することもできるデータベースだけでなく、 Gitを使用せずにワークツリー。それからこれらはすべて私がよく使う用語私はそれが嫌いです。あらゆることを学ぶこれは非常に疲れる。例えば、聞いたことがありますか？「ガントレットループ」について？最初はサイクルが始まって、みんな「何？」って感じ。「.そして今、それは聞こえる「ああ、私はただそれをするためにガントレットループを使用する。私たちは常に私たちはたくさんのものを発明します用語、それらのいくつか役に立つものもあれば、そうでないものもある。それでおしまい。そして最後に、私たちは「ソフトウェアファクトリーソフトウェア」。もしあなたはどんな質問でもするでしょうどのボットを調査すべきかこれらに関するすべての記事工場では、感銘を受けたが、あなたは読むだけです半分にして言うでも、とにかくそれを私にください。

演讲者: プロンプトを書いてください。あらゆることのために "聖人。" "私にさせて私はそうしなければならない仲介者」なぜならこれは本当に素晴らしい。見てみればより広く、ほとんど誰も本当のソフトウェア工場、人々すべてを集める山積みにして、私たちは私たちは合意に達することができます。これは何ですか？これは水平である企業組織？すべてのエンジニアは彼の工場では、その結果、私たちは混乱を引き起こしているのだろうか？見てみるとどれでも GitHubのリポジトリ、誰かがそこにプルリクエストを作成しました法学修士（LLM）の助けを借りて。そこには素晴らしい READMEファイル絵文字と段落。私たちは決して心配さえするテキストの強調表示 GitHubでは太字で、そして今段落全体があります。セパレーターとすべて他の。そして彼らはまだ応答中より美しい景色。さらに長い。彼らは突然方向転換細部への注意、そしてあなたはこう考える。「あなたはこれをする」「俺は書いてないぞ、この野郎。」。これが何なのか、あなたは分かっているはずだ。 AIが書いた。したがって、今は 2つあります人々の仲介者、 2人分コミュニケーションをとる LLM彼らの間では誰もこれに気づかず、最後にタスククライアントによって提出された、またはボスですよね？そして誰も気づいていない：私たちは一体何のためにここにいるのだろうか？私たちは何をしているのでしょうか？私たちには必要だこれを解き明かすために、あれを実は予見されるのは私たちが何者であるかを理解してください私たちは婚約しました。だから私は私はそれに応じて投げ返した。私の AIがあなたの AIをチェックします AIなど。結局、彼らはどこかで待ち合わせをする真ん中で、しかし私たちは解決策を見つける必要があるそしてプロセスを強制する進化。私のやり方これより前 :から端末からデスクトップアプリケーションそしてターミナルに戻り、最近

演讲者: CLIに戻りました。誰がこれについて聞いたことありますか？聞いた話それ？わかりますか？え？牧夫？忘れて。あなた理解した。だから、もしあなたはそれが何なのか知らないこのように、tmuxのようなものです。遠隔操作を可能にするあらゆるコードに対応するデバイスではセッションは中断され、端末は問題ありません。配置すると事実に見落とされなかったする。そして皮肉なことに、私はたくさん試しました設定、独自のオーケストレーターだが、過去または先々週私はセットアップしたばかりヘルダーは、最も単純なものとしてターミナル。そして私は最も多くリリースされた製品、そして考え：私たちもそうかもしれない私たちはこの全体を複雑にしていますソフトウェアファクトリー「セキュリティ」だが、これはそれは本当に状況。あなたは働いていますか？人と？幾つか人々？何チーム？あなたは働いていますか？一人で？または具体的に何をリリースするのですか？

演讲者: 私 Raspberry Piに切り替えました。円周率は急勾配だ。自分私は円周率が好きです。私もみんなを笑った、円周率を使った人。私は言った、「ただ人間らしくあれ。クラウドを活用しよう。コーデックスを使用してください。何を使うか "何でも。"その後、私のノルマが終了しました、クラウドのクォータについて消えた。そして私は CLI Codexに切り替えましたまたは Codexデスクトップ版、もしくは他のもの何か。彼らは行動する全く違う。彼らのやり方発売しますサブエージェントとして圧縮を実行する、彼らはこれをどのように行うか、あれをどのように行うか。だから私は常に CLIを切り替えてカーソル、クラウド、コーデックス。そしてなぜなら私はそれらを切り替えて、彼らは行動した全く違う。そしてこれそれは私を狂わせた。だから私が建てるときオーケストレーター、私は構築しますこの３つに加えて。しかし、それは非常に難しい。オーケストレーターを作成するこれは、これらすべて、そしてそれは CLI。彼らは異なる方法を用いている。タスクを完了する。

演讲者: そして Piでは CLIしか使えません。どれが「型破り」なのか何もしない。それで、あなたが望むなら圧縮には、プラグインをインストールしてください。あなたが望むならサブエージェントを実行するインストールする必要がありますプラグイン。そしてあなたは完全にプロセスを制御する。これは Linuxのようなものフレームワーク。そして私は、あなたが言っているように聞こえるのは、「ああ、はい。くそっ、そうだ。私はしたいもっとスタイリッシュなもの Linuxですよね？ハーダーはまた、良い機能があります。追加されたようです最近：もしハーダーがすべてにインストール済みあなたの車、あなたすべてを見る 1か所に—MacBook Pro、 Mac Studio、Linux VPSなど。なかなか良いですね。私に切り替えました使用ノートパソコンのみリモコン管理。

演讲者: 始めたクラウドから、そしてもう一つ、私はもう先に進みます。自分の決定、ノートパソコンまたはスマートフォンこれらは単なるリモコンです何が起こっているのかクラウド上で。だから私はこのような状況に陥ったウサギの穴、なぜなら牛乳がこぼれるカクテルは各自でノートパソコン、そして私は 1台持っていた GitHubのリポジトリ、私には時間がなかったダウンロード。幸いなことに全て保存されていたが、私はすでに彼が終わり。 1ヶ月の仕事消えてしまうかもしれないこれに加えてラップトップなので、私は気づいたすべてを移動させる職場環境働く場所どのデバイスからでも。今でも私は私は 10- 1年前の MacBookから遠隔で接続するあなたのセットアップとタスクを実行する。まず最初に試してみましたすべてを Macに移行するスタジオで、 Macと macOSは完全には適応リモートエージェント。 15年後、考えてみると私は考えず、決めた。「わかりました、Linuxを試してみます。そうなるかもしれない最良の選択

Speaker: ...It was an option. I started renting a VPS for 128 euros a month and thought to myself: "If this actually brings in money, then what a massive difference it makes." Later, I did the math on the costs. If I were to pay this kind of monthly fee for two years, that total amount would easily allow me to buy and build my very own dedicated Linux computer.

And before you know it, suddenly you have your very own Linux server showing up right there in your basement. But then I remembered my existing gaming PC. It had Windows and games on it, but I'm just not into that anymore. What I am truly interested in is this—this is infinitely more fun than playing video games today. I don't want to play video games; I don't want to sit around watching TV series. I just want to play with and build alongside these agents.

So earlier on, I made the decision: I am going to completely format this PC. I was going to put this "terrible" Linux on it, right? Windows was still sitting there, but even though it worked reasonably well, I sorely missed having more RAM.

So that was when I started hunting for components. Far before developing the actual production product for customers, the rabbit hole just kept getting deeper and deeper. I looked at it and thought, "Look, 32 gigabytes." I needed way more than that, but upgrading the memory meant I also had to upgrade the motherboard: "I want this, and I want that." And as a direct result, a second Linux PC materialized. Yes, I ended up building a second Linux computer completely from scratch.

Speaker: And then someone chimed in and said, "Why are you debating over which Linux distribution to install? You could just install Proxmox!"

Who among you here is enough of a hardcore nerd to configure Proxmox from scratch on your own? Let's see a show of hands. All right, I understand. Proxmox is an incredibly cool piece of tech for monitoring everything across the stack, just as we discussed, because previously I would find myself digging endlessly through configuration files and clicking all over the place trying to adjust settings.

Therefore, for everything mentioned here, just leave it as it is. I am certainly not smart enough to deal with all of this entirely by myself. I simply turned to my agent and instructed it: "Hey, a friend recommended that I use Proxmox, so please go ahead and set it up and run with it." And boom—right there, it had the entire environment completely configured.

This is truly remarkable, because in reality, out of just a single computer—suppose you only own one PC—you can install an operating system at a higher hypervisor level, and then spin up Linux, Windows, or even legacy Windows XP as virtual machines. Everything runs like a charm, and all your agents operate smoothly.

You don't even need to configure things manually anymore. They can function seamlessly as virtual machines or containers. So essentially, you have an entire fleet of independent computing instances made available right inside your local network. You can run fully completed, standalone virtual machines.

That is why my agents operate this way: here is Hermes, and there are the others. I carved out and assigned dedicated little virtual machines for them, ensuring that even if they go rogue or do something completely stupid, their footprint is strictly contained within these mini-computers running inside my physical machine.

So, how did I get it "Proxmoxed"? I plugged in a KVM switch, turned to Codex, and said: "Please finish this up. I don't even want to look at this." And that was that. It worked away, executed the steps, and succeeded. I looked at the result and thought: "Great, it worked, and I don't have to keep touching this constantly."

Speaker: People often start getting into remote programming, and I see the kind of screenshots they send me—riddled with weird, raw IP addresses and all sorts of chaotic junk.

In reality, you can build a very, very clean and pleasant environment if you are working remotely. You can simply tell your agent to set up Traefik—however you choose to pronounce it, Traefik—along with PM2. Magically, your processes and services will be gracefully mapped and guided under convenient, readable URLs.

You can have your own primary domain, whatever domain it might be, and leverage structured subdomains to manage your entire development pipeline.

That way, whenever you want to check what your landing page currently under development looks like, you can simply navigate to something like my-beautiful-landing-dev.dot-my-URL-dot-whatever. You will instantly recognize it, remember it, and bookmark it. It won't be some arbitrary, accidental raw IP address.

This is a fantastic piece of advice you should definitely adopt. The agent is entirely capable of configuring all of this for you.

The essence of all this is that people keep asking me: "What exactly is written inside your configuration files?" And I reply: "Yes, well... honestly, I have no idea." I haven't directly looked at a configuration file with my own eyes for two whole years. I simply state my intention or make a wish, and everything materializes as if by magic.

Speaker: Next, I found myself constantly pushing against the hard boundaries of limits and rate caps, which of course is a shared struggle we are all navigating together.

Here, let me share a neat little trick with you. I am paying for four separate $200 monthly subscriptions. That expense is trivial—it is vastly cheaper than hiring human staff, so it is completely normal and justified.

However, you must manage and orchestrate each of them across varying time intervals. In short, it comes down to what you might call a Codex load balancer. You might wonder: "What? Are you guys telling me you don't use load balancers to distribute your workload?" I genuinely assumed this was already common knowledge and industry standard, where everyone would simply respond: "Yes, absolutely, that's exactly how I do it."

In practice, there is only a single unified endpoint exposed to your tools. But whenever you make a request against it, the balancer intelligently decides: where should it source the necessary resources right now? It has full awareness of your quota limits—weekly caps, daily thresholds, any timeframe. And in truth, my quotas have never run out... well, at least until they rolled out Astra, which completely disappeared down the drain within a single day. Astra is indeed pretty brutal in that regard.

As a massive bonus: through this very same terminal endpoint, you can engage in real-time voice communication and simultaneously generate images on the fly. You can present this exact endpoint to your client programs, and they simply interact with the load balancer.

And things get even better. This handles Codex, but what about other tools? You have Cursor, Gemini, and countless others. Hidden behind all of them is a lightweight API proxy CLI, which itself functions as another robust load balancer.

Hovering above all of this is our AI-Router, serving as the master terminal hub. Whenever I want to write code, I interface exclusively with this router, and it autonomously determines which specific service among all these available tools to dispatch the work to. Almost nobody has formally released something like this yet. As I advance to the next slide, you will see how tools like PiHerder and others can skyrocket your productivity.

Every single model becomes a singular, globally accessible endpoint. This produces entirely new capacity. Instead of manually scraping a tiny bit of quota from Claude here and a few crumbs from Codex there, does it actually work in practice? It works brilliantly. Thus, all my connection pipelines are consolidated neatly into one single problem domain.

Speaker: And this is one of those slides that is worth taking out your phone to snap a photo of. Make sure you remember its name: Executor.

If you haven't configured an Executor yet, this is precisely what I am advocating. Even more so than OpenClaw, because this is absolute pure fire.

The single best thing about it is that it grants me the freedom to effortlessly change my configuration. Whenever I want to test out something new—whether it's Grok Bot, Meta Muse, or whatever new system just dropped—previously I had to manually reconnect Gmail, Calendar, GitHub, Cloudflare, and all those respective connectors every single time. Yes, every single one of those integrations.

The definitive solution here is to house all connectors under a single MCP provider. Everything is plugged directly into the Executor.

Now, if I want to give Muse from Meta a spin, all I have to tell it is to consume just this one single MCP—which is my Executor. That performer then bridges out and talks to every other underlying service on its behalf.

This makes switching back and forth between Pi, Claude, Codex, and other bots infinitely easier, rather than undergoing constant reconfigurations. It is remarkably straightforward.

Speaker: From there, I open-sourced this project's codebase. It is listed right on my GitHub under the name Skillbox.

I came to realize that the way we were managing skills was fundamentally flawed—keeping skills trapped inside markdown files. Previously, I maintained a custom script where GitHub synced skills across various workspaces. But it ultimately proved to be an absolute mess and incredibly confusing.

Whenever I sat down to set up a brand new computer, I would inevitably run into: "Oh great, I don't have that skill over here." That got me thinking: "If we already have an overarching executor actor for MCP that encapsulates all my MCPs, why on earth don't I consolidate all my skills into a single, unified MCP?"

So I went to work on this, and they ultimately adopted it into the formal specification. In the official MCP specifications today, there is a recognized concept: "Skills matter more than MCP."

Instead of having 30,000 loose markdown files scattered all over the place, you simply tell your bot: "Hey, I'm using Skillbox." It immediately hands you a polished graphical interface URL, and boom—all your skills are right there.

Furthermore, you can segment and organize them into modular "Skill Bundles"—a bundle for your personal assistant agent, another bundle for coding agents, and so forth.

My personal agent only ever requires 4 specific skills, whereas my coding agent might utilize 20 distinct skills, and neither of them needs to be aware of the other's toolset.

Consequently, if I am configuring something like Open Cloud Hermes, I simply point it to its designated skill bundle. It operates exclusively within that perimeter, never getting confused or randomly asking: "Wait, what on earth is Cloudflare?"

Previously, my skills were technically accessible to anyone, but they were trapped inside a single folder burdened by a mountain of markdown files. Now, my entire infrastructure is completely portable.

I can effortlessly pick it up, plug it into any other setup, and everything works seamlessly out of the box. I am currently working on something even newer, and I will definitely see it through to completion.

Speaker: It's essentially adding another layer of abstraction on top, because while our skills have MCPs, the implementation inside Codex refers to this tier as "Plugins," right?

So if you come over to Codex and install a development plugin on macOS, it automatically installs both the underlying MCP and the corresponding skills for you. Because of this, I believe we need a fresh term for it—perhaps something like a "Playbook."

I have a tremendous amount of ideas around this concept. Perhaps I will present this topic in detail in my next presentation; you can keep tabs on it through my Twitter.

The central thesis, however, is that Skillbox and Executor can be harmoniously united, packaging all configurations several layers higher and allowing you to simply transfer the entire bundle anywhere else.

This is very similar to Cody from KenshoDogs. If you've seen Cody, it operates on virtually the same foundational philosophy. They wrap it in Cloudflare Workers and a heap of sophisticated, complicated buzzwords, but I saw right through to its core essence: the core idea is to decouple and extract the "brain" of the agents, package it securely into Cody, and then freely transport that brain wherever it needs to go.

So Cody is essentially a convenient, higher-level companion to Skillbox and Executor. And the upcoming version of Executor will be released in an even friendlier form, functioning quite similarly to Cody.

It is undoubtedly difficult to track and absorb all these rapid developments simultaneously, but I want to plant a seed in your minds today so you recognize the massive trajectory of where things are heading on the move.

Our own biological RAM and human brains simply cannot juggle and retain all this complexity at once. Yes, that is the reality. We have compute capacities, subscriber tiers, load balancers, proxies, and on and on.

And so I reached an unavoidable conclusion: if you do not build yourself a dedicated orchestrator to systematically organize and tame this mess, everything will inevitably collapse into total chaos. Nothing will work smoothly. Chaos is guaranteed. Therefore, everything...

Speaker A: Based on what we discussed regarding your workflow, that is exactly why I came here today. In our previous setups, I noticed that within a single chat session, as the context window continuously shrinks and shifts, you easily lose track and ask yourself, "Where am I right now?" As a result, many tasks end up getting discarded along the way, leading nowhere because you run into so many conflicts. Then another alternative is having multiple separate chats, but they often interfere with one another. And then there is a third option: utilizing worker options with Git worktrees, but that introduces its own set of problems as well.

Speaker A: That was when I came across an article—which is included right here in my slides—advocating the rule: one chat, one worktree, and one PR. A lot of developers have adopted this pattern. For me personally, as an independent developer working solo, I historically did not use pull requests at all. I used to just push everything directly to the main branch, which led to endless circles and messy iterations. But now I understand that in order to genuinely improve code quality, I need pull requests that pass all the checks: type checking, linting, and various other automated verifications. And I want to automate this entire process rather than doing everything manually.

Speaker A: What triggered me to change was a real incident that occurred. I had started using strictly worktrees, and one of the agents running inside my worktree somehow deleted our production Git database during execution. Fortunately, I had a backup copy to recover from. When I investigated, the agent essentially said, "Oh, sorry, I was trying to seed the database for testing, but instead of testing inside an isolated container, I was running tests directly on your host machine." As a consequence, it wiped out everything. That taught me a hard lesson: a Git worktree alone is definitely not a real sandbox.

Speaker A: Here on the slide, we have Orbs. That guy from Ampcode—Thorsten or a name like that—he was talking about Orbs. Initially, my brain felt completely overwhelmed by all of this, and I thought, "Can we just move on without Orbs? Is that really necessary?" I even saw people arguing on Twitter multiple times, saying: "Orbs are just a marketing invention. They do not exist in the dictionary. Shut up and stop talking about Orbs." But actually, his underlying philosophy is spot-on: for every task, your agent needs a dedicated mini-sandbox, a mini-VM, or a mini-computer where it can safely operate. And while it is doing its job, it opens up a single tunnel URL. You can open that URL to inspect the app and verify what it is doing.

Speaker A: When you think about it, you are acting as a tester, right? Our roles are shifting right now: we are becoming testers for AI. At first, I scoffed at that idea; I thought that would never happen. But after going through everything from start to finish, observing what he demonstrated, I now genuinely believe: "It is Orb time." He had this catchphrase, and awkward as it sounded, it really is Orb time. I realized this is by far the most stable way to build anything—properly tested, strictly isolated, and routed through an automated software factory pipeline.

Speaker A: My rule of thumb is: one task gets one disposable mini-environment at a time. I mentioned Proxmox earlier; my Proxmox setup provisions containerized environments similar to Docker or lightweight VMs. Every time an agent requires an Orb, it spins up a mini-VM equipped with everything it needs: a seeded database, browsers, and dependencies, running strictly under isolated conditions. I personally use Podman, and the environment is isolated from outside credentials and production data. My machine maintains a task execution queue because it can only sustain around eight concurrent Orbs before tearing them down. So tasks simply wait in line: an Orb spawns, executes, dies, and the next one takes over in a smooth, continuous cycle.

Speaker A: Now let us look at what goes inside for code quality. As I mentioned earlier, when you run multiple tasks inside unstructured chats, there are virtually no hard fuses. You might look at ESLint and realize the agent disabled half the configuration just to report: "Work completed, zero errors!" Did it really fix the issues? No, it simply commented out five lines of your linting configuration. If you do not install strict, unbypassable hard fuses, your pull requests will devolve into complete garbage and slop that nobody can use or maintain.

Speaker A: To solve this, here is my winning combo: ESLint, Ultra-Linter, and the Anti-Slop library created by Dylan Monroe. These three components operate together seamlessly. I encourage you to take a photo of this and instruct your agents to configure it. They guarantee that every incoming pull request strictly adheres to your established rules. When rules only live inside your head, you must extract them and encode them into linters and validation systems; that is the only way to reliably get the exact output you desire.

Speaker A: I also realized that many of my architectural rules do not easily fit into OXLint or ESLint; they simply are not traditional lint rules. So I asked my agent: "Can you create a custom CLI policy enforcer? Let us call it the 'Cop'." With it, you can enforce specific guidelines such as: "Never use custom raw buttons; always use the Shadcn button component." You cannot easily configure this inside a standard linter. But my agent wrote the checker, and now it enforces a stack of customized constraints that effectively prevents the agent from doing anything foolish in the codebase.

Speaker A: And finally, we have Jev. Jev is remarkably cool. It was created by Jevrabbit on GitHub under the name Rabbit. With it, you simply describe in plain English the negative rules and anti-patterns you do not want to see in your code. It provides an exceptionally fast and inexpensive review of every pull request, without leaving useless or nonsensical comments. Instead of handcrafting complex lint rules, you literally state your requirements in plain English, and Jev verifies each PR against those natural language rules. It adds another layer of high-level validation right from the sky.

Speaker A: Based on these concepts, I built my own software factory, and I really wanted to show you how it works in practice. It integrates everything we talked about: state recall, load-balanced Orb generation, and automated testing as core pillars of the system. Looking at the countdown timer, I am running out of time, but let me take a minute or two to show you what it looks like. Software factories in the future must look something like this. Give me a moment to switch screens. This is arguably the first genuinely well-designed agent orchestrator you will see in action.

Speaker A: It is loading up now. As you can see, the UI is very clean—beyond the light theme, there is no clutter. It feels like what Steve Jobs might have created if he woke up and decided: "Let us build an orchestrator." On the left sidebar, it neatly organizes all my projects. For example, looking at the Workbench project here, I have a clear backlog of tasks I want done, detailed plans, and issue lists. When you click into the "Factory" tab, you can observe the pipeline in real time: every task passes through code-generating bots, automated browser testing, and thorough verification by tester agents until the work is fully checked off.

Speaker A: If I return to one of my project views and need something done, I just look at the to-do list, specify the work, and hit enter. The item moves straight into "Ready" and traverses the entire factory pipeline while you watch. With an interface like this, you genuinely feel like you are managing an industrial software factory, rather than just conversing with an oversized chat bubble or a bloated orchestrator. My time is up, but this tool—called Workbench—will be announced shortly on my Twitter. It fundamentally changed how I work; I no longer rely on CLI commands or heavy local apps. Even from a phone or a low-spec device, I can effortlessly oversee the entire factory. Thank you very much for listening, I have a flight to catch. Thank you!

Host: Thank you again, everyone, give him another round of applause! I forgot to mention to the audience—this speaker is actually the most popular presenter on the AI Engineer YouTube channel. If you browse through the channel, you will see his talks consistently rank as the highest viewed and most popular. His insights were fascinating, and I personally resonate deeply with many of the practical issues he described. By the way, I work at Replit, where we build infrastructure for creating and running applications. Now, let us continue our conversation about the future of AI.

Host: At this moment, we are excited to hear from the Vice President of Engineering at Mistral AI, who was also the third employee to join the company. Please join me in giving a warm welcome to Lélio Renard Lavaud to the stage!

Lélio Renard Lavaud: Hello, everyone. Thank you so much for coming tonight; it is incredible to see such a massive crowd here. Today, let us talk a bit about what Mistral is preparing, what is new, and hopefully give you some genuine insight into what our engineering team is actively working on behind the scenes.

Lélio Renard Lavaud: For those in the room who might not know us yet, we are Mistral. We are Europe's leading artificial intelligence laboratory. Our journey began about three years and four months ago. Back then, we were just a tiny company. Today, we have already expanded to over 1,300 people, experiencing tremendous growth along the way.

Lélio Renard Lavaud: We operate with a very clear mission: to place cutting-edge AI directly into the hands of our customers and transform how enterprises conduct their daily operations. We are not blindly chasing artificial general intelligence (AGI) for the sake of it. We are focused on delivering tangible business value, utility, and real-world profitability.

Speaker A: が私たちが作った理由ですチームがに従事している実用的なもの、パイロットの転向労働者のためのプロジェクト決断。これは実際には、会社が何をしているか今、何をしているのか。覚えているなら前回のAIエンジニアサミット1年前、私はとてもコイエブが喜んでいる私は招待されました。それ以来、多くのことが起こった。起こった。登録済み700名以上の参加者。今日私たちはスピーカーが50個なので、信じられないほどイベント。

Speaker A: コイエブに関しては、私たちを招待しました昨年、今彼らはミストラルの一部となり、質問できます：なぜ私たちはそれらを買ったのか？なぜなら私たちはでは次に進みましょう派遣労働者整数へのロードエージェントネットワークには、非常に論理的チームを引き付けるために専門としているのはまさにそのようなものを作り出すシステム。これは完全にただサーバーを管理するあるいは、それに類するもの。

Speaker A: これは「サンドボックス、計算単位、必要なもの作業開始ロードイン規模。これはイアンが昨年述べた。うまくいけばね。と初日「「鉄」高い品質を確保するため生産性妥当な経費。私たちはサポートします数十人の仕事数千のアプリケーション10の「むき出しの」鉄各地世界。そして彼らはミストラルに参加して、これを構築するインフラストラクチャー。私たちは私たちは確認したいのです、それは私たち自身の必要に応じてタスクを実行する安全で信頼性が高く、高速バックグラウンド実行すれば、彼らのテクノロジー。

Speaker A: また、5月に発表しましたEmiAIの買収について。エミこれは、専門としているのは物理的なAIモデリング。引用しますヨハネス：「統合する生態系における経験ミストラルAIワールドレベルが上がると、革命を起こす重要な点で研究と開発」。私たちは共に私たちは基本的なものを作ります情報が必要デザインと次世代を創造する航空機の世代、車と半導体。

Speaker A: つまり、それは全員を巻き込む機会、シミュレーション、それらすべて理解を助け、世界をモデル化するために、モデルに戻すと、より効果的かもしれない私たちの産業顧客。今年の初めに私たちは発表エアバスとのパートナーシップ1億5000万ドルドル、そしてこれがその一つですケースそのような存在専門知識会社を助ける私たちは構築します最もモダンな専門このようなモデル顧客。

Speaker A: 過去今週は他にも発表しました資金調達ラウンドDシリーズ。これは最大ですラウンド技術的なヨーロッパの企業—3社数十億ユーロ。私たちは私たちは、彼が団結させた多くの投資家ヨーロッパから世界中から信頼する世界の我々にはこの使命がある。AIは便利で、変身企業、そしてこれは、私たちの仕事は過去3年間本当に効果的です。しかし、私はまた同じことをするだろう。時間。あなたは自分。私ではありません。もしこれが次に何が起こるか一度、あなたは知るでしょうそれは私です。ええと、手短に済ませます。あなたにお話しします仕事の未来とこれに対する私たちのビジョン。これはまた、私たちは安全を重視していますエージェント。私たちは少し話しましょう主権、そして私たちの働き方について新型モデルについて。皆さんが「le」について聞きに来ました「シャトンの脂肪」。私はそうではない私はそれを発表します。今日、しかし我々が一生懸命働くこれを実現するために。したがって、うーん、それは複雑だもちろん、その瞬間だ。はい、素晴らしい。

Speaker A: したがって、仕事の未来、少々お時間をください。私たちの今日のセット製品と当社のビジョン。我々は持っています強力な製品開発者スタジオと呼ばれる場所で、私たちはたくさん作りますプリミティブを上にモデルそのもの。したがって、今日はとても多くのモデルがありますが、これだけでは不十分です実装のために生産なので、スタジオを開発しました。巨大なものを追加するフロアの価値これ。必要なもの本当に必要だった仕事のために生産。労働者のことを考えてみてくださいプロセスなど長期実行、サンドボックス、私が言及したこと以前。すべてのプリミティブあなたが必要とするもの、つまり、それは本当にうまくいった。

Speaker A: また、当社にはVibeという製品があります。最終版ユーザーこれら全てを使用する機会問題解決生産性エンドユーザー、特に企業ユーザー。もちろん、また、強力な意思決定チームが素晴らしいものを作り出すすべてのケース顧客だけでなく科学チームは生成的なものを構築し、また専門的誰にとっても魅力的なモデル。しかし、私たちは私たちは本当にそこに行きたいのです、ここにないのでコントロール、すみません、ここ。こちらはスティーブンです。スティーブンはとてもいい人だ。男。彼は財務部ミストラル。そして彼は答える。私たちの収入のために使用されたきちんと。スティーブンはある人はこう言うかもしれない何でも屋、しかし、残念ながら彼は収集する時間がない新しいワークステーション地下室で一人でいる。前

Speaker A: 彼は必要としているツール彼に許さないシンプルに言うと質問ですが、アプリケーションを作成する。彼はアクセス権を必要としている。ツールへ彼に許すだろう、例えば、作成する分析アプリケーションそしてクロスデータチェック湖から来るデータ、Excelテーブル、またはワークスペース考え、そうすれば彼はこれをアプリにコンパイルするそしてそれを共有します同僚たちと共に。それ、つまり、私たちが話しているのは以前にも話したが、彼は企業環境によっては特定の規則に関してちゃんとしたデータ使用量。そしてこれは統一された私たちが開発中のVibeのバージョン私たちは今取り組んでいます:どのようにそのようなものを作るためにユーザー-開発者普通ユーザー、しかしより良いスタートを切るアプリケーションを理解し、モデルの使用作成する役に立つもの、効果的に当社の製品群。

Speaker A: それ典型的な自動化我々が主にエンジニア向け。私たちは元気ですか？移動Slack通知について真夜中に何かがうまくいかなかった、調査エージェント。私たちは気にかけています次のものについてエンジニア電話がかかってきた。目を覚まして座るコンピューター用に、すでにすぐに使える情報に応答する問題。通常これはのおかげで私たちのVibeスタック、なぜなら私たちはすぐに発売します非同期エージェント容器の中でを介して接続されています当社のコネクタ—GrafanaSentry、GitHubへPRとは何かを理解するにつながる可能性がある回帰分析、そしてオファーエンジニアのためのヒント素早く理解する問題が発生した。そしてそして、明らかに、結果を送信するSlackで。そうすれば可能になる対話をし、勤務中のエンジニア何かから押し退けるのではなく、使いすぎる時間。

Speaker A: これは実際には、例。手に入れる初回通知セントリー、そしてエージェントはすぐに妨害する情報彼が見つけたものエンジニアを支援する理解してください起こっている。場合その前にしなければならなかったたくさんする技術的な作業調整する相互作用複数のシステム。必要があるエージェントが起動しましたサーバー上のどこか。あなた必要これらを設定する接続、示す、どのコネクタにアクセスが必要です。そしてだから私たちは私たちは、この統一されたバージョン。あなたは始めていますこのような要求から、十分に単純で、だから私たちの愛しいスティーブンがそれを手に入れるかもしれない入場する。レビューインタビューについて不足しています、送信個人的リマインダー面接官へやるのが忘れていました。そして必要ない考える繋がり必要なMCPはATSシステムか何かそんな感じ。

Speaker A: 私たちは私たちは取り組んでいますそれがほぼ全てだった必要なもの作る。なぜなら、すべては今見たのは前のプレゼンテーションには、複雑で、その他の考察。しかし私たちの企業ユーザーは開発者と何も知らないLinuxまたは仮想車が欲しいだけそのようなものを送るリクエストとすべての必要なコネクタ企業用ツール手作業で。こちらがバイパーですこの意図を理解し、エージェントを作成する背景には、コード、テストを実行する、デプロイおよびホストする彼らと、そして独立して反復処理分または数時間あなたは手に入れることができません最終結果、これはシェアする同僚適切な権利を有するアクセスとは必要企業向けソフトウェア。

Speaker A: そしてこれは最も興味深いことです。なぜならこのようなケース使用どこにでも見られる:人々はそれを関連付けます何でも、代理人へアクセスするデータなし制御できない実は不可能にするこのような実装ソリューションを実運用へ。私たちは確信しています仕事の未来結合することから成るこれら全ての役割を一つにまとめるそしてそれがまさに私たちなのです私たちは投資します。それで、代わりにソフトウェアソフトウェア、なぜなら私たちのユーザーは間違いなく知っているそれを作るために、なんとかやりくりしているエージェント。我々は持っています単一の統一インタフェース。したがって私は私は発表します別の製品あなたはどこで働いていますか？金融、法律部署はありますか？エンジニア。製品とモデル対応適応するもの彼らは使用するそしてショーは、統一異なるインターフェースプラットフォーム。

Speaker A: となることによって以前見たもの、まさにそれが私たちは働く：そうすればセッションを開始する地元で自分でノートパソコン、転送ネットワークに送って実行する「サンドボックス」では、チェックするアプリ内の電話とそれさえも管理できる。彼はできるGitHubにプッシュします。彼はできるCIを確認してください。彼作業できるこれを繰り返し行う。そしてここにある唯一のもの統一ツールキットとてもよく機能します、ビジネスだからユーザー必要なのは複数のプロセススプレッドシート、可能になる使ってみて気づかないうちに違い。

Speaker A: したがって、プラットフォームは明らかに回数を重ねるごとに価値が増し、誰かがそれを持っているとき使用例。誰かスキルを作成する、誰かが作成するアプリケーション、彼らはそれらを共有チームの残りのメンバー。私たちはまた、改善するスキルを向上させ、プロンプト。通常私が今言ったように、見ることができます一週間働いた後この研究エージェントが働いたなどなど。多分、GrafanaMCPを呼び出す方法元々は間違っているのは彼はこれを理解していなかった書類不備オプション。分析するトレース、スキル今ならもしかしたら独立して修正してどのように示すか右これを使うコネクタ入力将来、彼がより効果的だったトークンに関してもっと早く。

Speaker A: これは残念だ。私たちを安全な場所へエージェント、なぜならこれらはエージェントは非常に強力で、彼らはパフォーマンスする多くのタスクがありますが、もちろん、リスクはあります。そして私は確信していますあなた方一人ひとりには家族の中で、過去10日間AIが人を殺すかどうか尋ねられた世界。さて、ミストラルはこれやらない、それだけだだからこそ私たちは活動しているのです私たちはセキュリティに投資しますエージェント。

Speaker A: 短い何がエージェントの安全性は？もしさまざまなことについて話す脅威モデルエージェント、彼らは通常持っている特権多くのものへのアクセスコネクタ、大型データ量とそれらを使ってできること何でも。なぜならそれらは非決定論的である非常に難しいハードに設定制限により「もしあなたがこれをやるなら、やめた方がいいやれ。」これは難しい、なぜならその間次回の打ち上げ彼はこれができる絶対にやらないでください。そして、もちろん、入力

Speaker: Data, controlled attackers, prompt injections we talk about. We all know that they are becoming increasingly complex, and while efforts are being made to implement protections in the model itself, each of them has its own vulnerabilities. As long as you process user data or external data, this is always a threat and can cause problems at any time. So how can we protect ourselves against this?

Part of the work has to be done by the model. You want the model to maximize its understanding of what an injection is, what the instruction tree and origins are from the user and safe contexts. Of course, you also want to restrict the privileges of your agents. You want to make sure at runtime they can only do what they need to do. And this dynamically changes permissions depending on the step and the work process.

Speaker: Obviously, the sandbox here is very important. And underneath, there are safety rails at runtime. Do you have everything you need to observe the behavior of that agent? Displaying traces, not just low-level traces, the sandbox is also very important. You can display all system calls, all network requests, and based on this, is it possible to derive heuristics and understand what the sandbox is actually trying to do? Whether it follows the nominal agent template or if it is something abnormal.

Speaker: The problem is that if you add all these guardrails everywhere, you basically destroy all options to use it. Because you had a powerful agent, powerful tools, but now by restricting everything because you fear everything, you make it useless. Therefore, this is clearly a dilemma that we have to deal with.

So we resolve this dynamically using collaboration and ensuring that we provide the required amount of desired privileges only at the moment they tell you it is necessary and there is a valid justification to grant them. We can also filter what kind of operations should be allowed and why.

In a very quick, typical demonstration with prompt injection, let's ask VibeCLI to complete a task, reviewing an issue on GitHub. It goes through very quickly, but looking back, that GitHub issue contained a prompt injection that actually made it publish a comment containing stolen secret keys, simply because you fetched the content of an issue published by a malicious user.

Therefore, we have prompt-injection rules where you can configure a set of classifiers. You choose whether you want to detect personally identifiable information (PII), secrets, enterprise knowledge, and so on. You decide the sources, determine the thresholds—meaning you decide the type of moderation you want to apply—and also define what should happen afterwards.

Speaker: Once you set your rules, you can now add policies. Policies allow you to decide where to apply this across product surfaces, whether it is the web version, mobile applications, or command-line interfaces. So this is the ultimate enabler for enterprise administrators to rule this. You determine the thresholds here and apply them, and then you just need to activate it.

Now, even if you use the web interface and perform the exact same action, it is stopped at the network level without the user needing to configure anything. That is the power of enterprise control: users never have to give separate consent for protection; this policy is defined and implemented at the enterprise level. This is the kind of work we are doing in terms of security guidelines.

Speaker: But security alone is not enough; AI must be sovereign. So what is sovereignty?

There is data sovereignty: Where is your data? Where is your user and customer data stored? Where is it kept, and who has access to it? What hyperscaler or what company, through jurisdictions or other reasons, can actually read this data?

Intellectual sovereignty also involves analyzing model behavior, trying to fix or fine-tune what is happening. And also computation: this covers all output processes (inference). When you run inference, even if everyone buys ZTRs everywhere, data still passes through specific locations. Understanding this is very important for operations, because your enterprise needs to know with certainty what is happening from a security, audit logging, and compliance perspective.

Speaker: Therefore, we answer this directly: this is the data center that we are currently building. Mistral continues to push forward; recently starting as a model development company, then growing into an enterprise-ready company, and now we are building our own data center.

Roughly speaking, this facility near Paris represents about 10 megawatt-hours, equipped with Nvidia B200 chips. It is one of the largest data centers with such advanced Nvidia hardware in Europe. This is where we run critical internal workloads—like Le Chat serving articles and user queries—but it is also where we host the most confidential customer workloads. This is exactly how we deliver a fully sovereign pathway from beginning to end, offering agent security, inference, and training to our customers.

Speaker: But of course, to make everything work smoothly, you also need the models. This is essentially the family of general-purpose models we have, across various sizes for diverse tasks. I know everyone is looking forward to the next big foundation model, and I can assure you that we will deliver it very soon.

However, we are also paying tremendous attention to specialized models. There are two types of specialized models: first, dedicated models useful for various specific purposes (we will talk about OCR and Vox shortly); and second, models where we retrain specifically for particular clients and proprietary datasets.

Think about low-resource languages, or companies that use proprietary in-house programming languages that nobody else has heard of. Obviously, default models are not very strong at this kind of coding. Before founding the company, we sat down and discussed this, and specialized models truly make a massive difference. We also have experimental models that allow us to push scientific boundaries, like Leanstral for formal proofs, and Chillstral, which we announced a month ago. Everyone talks about general-purpose models, but Chillstral responds specifically to moderation issues extremely fast with a very clean architecture for security purposes.

Speaker: Delving a bit deeper into specialized models, let's talk about Vox, our family of audio models. We have text-to-speech models, and I want to demonstrate this. As I stated last year as an AI engineer, our mission has truly been to offer open models and code execution to make AI accessible to the masses, while maintaining compatibility with enterprise-grade solutions and strong focus.

When we build at Mistral and analyze this data, observing how people actually do their work in enterprise contexts, it is crucial to understand how employees organize their day and what operational processes they execute. Can you guess which one was generated by artificial intelligence? The other one was actually me. This type of voice cloning capability is an area where we are actively investing to create highly useful models. The second sample was entirely my voice, and this represents the capability we are developing.

For speech-to-text conversion, we are working on increasing accuracy. We do everything to capture voices and various accents in any operating condition. In speech-to-text, we already have advanced models, and we are significantly improving them. We are working on real-time diarization to provide live stream transcription during meetings with accurate speaker identification, expanding the number of supported languages, providing precise timestamps, and ensuring robust stability in noisy environments.

Speaker: In the banking sector, there is a very critical and lengthy process known as KYC (Know Your Customer). Mistral AI partnered on a specific corporate KYC process with a Belgian customer, developing two dedicated agents. We succeeded in reducing the share of incomplete files sent back to the back office from 80% down to 10%. As a result, customer applications operate dramatically faster.

This was not a gimmick; it was real-time transcription and document processing powered by our latest models. We are actively working to make this even more beneficial for customers, and this philosophy is key to our approach. We don't just chase benchmark nuances; we strive to build capabilities that transform the operational reality of our customers.

Briefly touching upon OCR 4.1, which we released this summer: this modern OCR model is capable of recognizing any handwritten text as well as old scanned documents, such as papers from the 1960s. Even with highly complex document markups, it distinguishes captions, headings, body text, tables, and images, allowing you to extract everything cleanly. It is an extremely powerful model used extensively in our document libraries.

In our Vibe document libraries, when you load massive amounts of unstructured documents—terabytes of files—they pass through this OCR pipeline, providing instantaneous access to any piece of data. This serves as our advanced RAG pipeline for customers with these specific configurations. We are persistently refining it to make it even more reliable, supporting more languages with high noise resilience. These state-of-the-art models are where we actively invest because they solve real enterprise problems and directly upgrade production workflows for our customers.

These playgrounds are available for testing. We invite you to visit Mistral Studio to test these models yourself—whether testing our audio models or our OCR models. We have extended access by another month, so please go ahead and try them out.

Lélio: And it allows execution based on all these very difficult scenarios. So, in other words, we are working on a new vision of work—trying to escape the limitations of simple chat assistants and build something genuinely useful that unites end users and developers. We are also working very hard on agent safety to ensure that, while keeping these agents extremely powerful, we guarantee the protection of enterprise knowledge. And what do we have for that? The right set of tools.

Lélio: We are working extremely hard on sovereignty, ensuring that we provide every customer with the level of control they require, backed by massive investments in data centers across France and perhaps all of Europe for the entire AI lifecycle. And we continue the hard work of improving our models. Our science team has never been larger, and there is so much happening across all these different fronts at this event. LLMs clearly continue to be one of our primary directions that we are actively pursuing. And I hope that very soon we will have something very exciting that we can share with you.

Lélio: Thank you so much for coming. I hope you enjoyed the Summit! Each of our teams is here today. Some of them are wearing orange shirts, so please don't hesitate to reach out and talk to them. Remember, there are 1,300 of us here today, but we are actively hiring employees—so go ahead and say hello!

Lélio: And thank you to all the speakers. I also want to thank Jen, Alice, Dar, and the entire DevRel team for organizing this event, and, of course, Ralph, who has been our presenter this evening. Thank you all very much. Enjoy!

Ralph: Perfect! Yes, thank you, Lélio. Let's do it one more time—a round of applause for Lélio! Yes. Yes, definitely, that was well deserved. I think we should also thank Jen, Alice, and the entire Mistral team for organizing this event.

Ralph: Alright, so I have one piece of bad news. The sad news is that tonight is already over, right? You can go and get some rest. But I also have two pieces of much better news: we will be back again tomorrow! There are so many things we are going to embrace tomorrow. You will hear talks from Black Forest Labs, you will hear from Nvidia, and many others. So tomorrow's program is going to be truly extraordinary, alright?

Ralph: By the way, who is coming back tomorrow? I see all of you! Yes, wonderful. So see you tomorrow—but for today, the reception is over at the exhibition area, right? So let's all slowly head over there, enjoy, meet people, and take your time chatting with everyone. Our speakers will be there, and our sponsors are participating as well. Come on, let's join! See you in the exhibition hall in about a minute. Alright, everyone, thank you so much. You've been wonderful today. Yeah.