Der 10-Millionen-Dollar-Bug, den eine KI schrieb – und warum ich ein Unternehmen gründete, um ihn auszurotten

Ich erinnere mich genau an den Moment, in dem ich beschloss, Veriprajna zu gründen.

Es war kein Geistesblitz. Es war ein Telefonanruf. Die Art, bei der in den ersten fünf Sekunden niemand spricht, weil die Person am anderen Ende versucht herauszufinden, wie sie sagen soll, was sie sagen muss. Ein Design-Team – Leute, die ich respektierte, Leute, die ihre Arbeit wirklich gut beherrschten – hatte gerade das erste Silizium eines maßgeschneiderten RISC-V-Beschleunigers aus der Foundry zurückbekommen. Der Chip war tot. Nicht „braucht einen Workaround"-tot. Nicht „wir können ihn in der Firmware patchen"-tot. Unbrauchbar. Unter einer spezifischen, seltenen Kombination aus thermischem Throttling und Speicherverkehr mit hoher Bandbreite ging das Arbitrierungsmodul in einen undefinierten Zustand über, und das Ganze geriet in einen Deadlock.

Die Ursache war eine Race Condition. Eine einzige, subtile Diskrepanz zwischen Blocking- und Non-Blocking-Zuweisungen im RTL – die Art von Sache, die perfekt simuliert, ohne ein Wispern durch den Linter läuft, jeden Regressionstest besteht, den man ihr entgegenwirft, und einen dann im Silizium verrät, wo es keine zweiten Chancen gibt.

Der Maskensatz für diesen 5-nm-Chip kostete rund 10 Millionen Dollar. Weg. Aber der eigentliche Schaden waren nicht die Masken. Es waren die sechs Monate, die nötig waren, um zu diagnostizieren, zu beheben, neu zu verifizieren und neu zu fertigen. Im Markt für KI-Beschleuniger, wo Produktgenerationen etwa 18 Monate halten, kann ein Verzug von sechs Monaten 50 % des gesamten Lebenszeit-Bruttogewinns eines Produkts aufzehren. Für ein Unternehmen, das 100 Millionen Dollar Umsatz anpeilt, kostete diese Race Condition nicht 10 Millionen Dollar. Sie kostete 50 Millionen Dollar.

Und hier ist der Teil, der mich nachts wachhielt: Der Code, der sie verursachte, wurde von einem LLM generiert.

Der Goldrausch, den niemand hinterfragt

Gerade jetzt befindet sich die Halbleiterindustrie mitten in einem Goldrausch. Alle – und ich meine wirklich alle – wetteifern darum, Large Language Models in den EDA-Workflow (Electronic Design Automation) einzubinden. Das Versprechen ist unwiderstehlich: Designzyklen, die früher Jahre dauerten, auf Monate zu komprimieren. Das Chipdesign zu demokratisieren. Die KI die mühsame Codierung auf Register-Transfer-Ebene übernehmen zu lassen, damit sich Ingenieure auf die Architektur konzentrieren können.

Ich verstehe den Reiz. Ich habe ihn selbst gespürt. Als ich zum ersten Mal beobachtete, wie ein LLM aus einem natürlichsprachlichen Prompt ein syntaktisch korrektes Verilog-Modul generierte, dachte ich: Das ändert alles.

Aber dann begann ich genauer hinzusehen, was „syntaktisch korrekt" eigentlich bedeutet, wenn man Hardware statt Software schreibt. Und mir wurde klar, dass die Industrie auf einem Fundament aus Sand baute.

Die Werkzeuge, die gerade den Markt überschwemmen, sind das, was ich „Wrapper" nenne. Sie nehmen ein universell einsetzbares LLM – GPT-4, Claude, Llama – umhüllen es mit einer Chat-Oberfläche und ein paar Verilog-gewürzten System-Prompts und verkaufen es als „Chip-Design-Copiloten". Manche davon sind wirklich beeindruckende Demos. Der Code sieht sauber aus. Er kompiliert. Er simuliert sogar.

Aber hier ist, was diese Werkzeuge grundlegend sind: stochastische Token-Prädiktoren mit einer Hardware-Hülle. Sie verstehen keine Schaltungstopologie. Sie verstehen kein Timing Closure. Sie verstehen keine Metastabilität. Sie sagen den nächsten wahrscheinlichen Token auf Basis statistischer Muster in ihren Trainingsdaten voraus.

Wenn ein LLM in Software halluziniert, bekommt man einen Laufzeitfehler, den man über die Luftschnittstelle patchen kann. Wenn ein LLM in Hardware halluziniert, bekommt man einen 10-Millionen-Dollar-Briefbeschwerer.

Diese Asymmetrie ist der ganze Grund, warum Veriprajna existiert.

Warum schreibt KI schlechten Hardware-Code?

Das ist die Frage, die mir am häufigsten gestellt wird, meist von Software-Ingenieuren, die gesehen haben, wie LLMs vollkommen funktionsfähiges Python schreiben, und nicht verstehen, warum Verilog anders ist. Die Antwort geht tiefer als „Hardware ist schwerer". Es ist eine grundlegende Diskrepanz zwischen der Denkweise von LLMs und der Funktionsweise von Hardware.

LLMs werden überwiegend auf Software trainiert – Python, Java, C++, JavaScript. Das sind imperative, sequenzielle Sprachen. Zeile A wird ausgeführt, dann Zeile B. Der Zustand des Systems wird durch die Reihenfolge der Operationen definiert. LLMs haben dieses Paradigma so tief verinnerlicht, dass es im Grunde ihre Muttersprache ist.

Verilog und VHDL sind deklarativ und nebenläufig. In einem Hardware-Modul wird jeder always-Block, jede assign-Anweisung, jede Modulinstanziierung gleichzeitig und kontinuierlich ausgeführt. Die Reihenfolge der Zeilen im Quellcode hat oft null Einfluss auf die Reihenfolge der Ausführung im Silizium.

Ich habe das in Echtzeit während eines unserer frühen Experimente miterlebt. Wir baten drei verschiedene Frontier-LLMs, ein einfaches dreistufiges Pipeline-Register zu implementieren. Alle drei verwendeten Blocking-Zuweisungen (=) statt Non-Blocking-Zuweisungen (<=). Der Code sah vollkommen vernünftig aus, wenn man ihn wie C-Code betrachtete. Aber in Hardware bedeuten Blocking-Zuweisungen in einem getakteten Block, dass stage2 sofort mit dem Wert von stage1 aktualisiert wird, und zwar unmittelbar, und dann bekommt stage3 den neuen Wert von stage2 – wodurch eine Pipeline über zwei Zyklen effektiv auf einen Zyklus zusammenfällt.

Eine meiner Ingenieurinnen, Priya, starrte eine Minute lang auf die Ausgabe und sagte: „Es schreibt C mit Semikolons an den falschen Stellen." Sie hatte vollkommen recht. Das LLM hatte eine sequenzielle Verzerrung – es behandelte Verilog wie eine Programmiersprache, obwohl es eigentlich eine Beschreibungssprache ist. Der Unterschied ist syntaktisch subtil und physikalisch katastrophal.

Und es kommt noch schlimmer. Hardware-Design beruht auf strikten Schnittstellenprotokollen – AXI, AHB, PCIe, TileLink – mit komplexen zeitlichen Regeln. „Ready darf nicht auf Valid warten." „Grant muss innerhalb von 5 Zyklen ausgelöst werden." LLMs können Code generieren, der diese Regeln in 90 % der Fälle einhält, was großartig klingt, bis man erkennt, dass die 10 %, bei denen es falsch liegt, genau die Grenzfälle sind, die Chips töten. Ein AXI-Master, der WVALID vor AWREADY in einer bestimmten Unterklausel-Verletzung auslöst, wirft keinen Syntaxfehler. Er kompiliert, simuliert und hängt sich dann auf, wenn er im Silizium mit einem konformen Speichercontroller verbunden wird.

Das Problem der Trainingsdaten verschärft alles. Das Volumen an hochwertigem, produktionstauglichem Verilog, das zum Training verfügbar ist, ist um Größenordnungen kleiner als das von Python oder JavaScript. Ein Großteil des Open-Source-Verilogs auf GitHub sind Studentenprojekte, aufgegebene Prototypen, Spielzeug-Implementierungen, die niemals eine Tape-out-Prüfung überstehen würden. Wenn man auf mittelmäßigen Daten trainiert, erhält man mittelmäßige Ausgaben – Ausgaben, die professionell aussehen, aber die DNA von Amateurfehlern in sich tragen.

Die Regel, die jeden Chip-Designer verfolgt

Im Halbleiterdesign gibt es eine Faustregel namens „Zehnerregel", und sobald man sie versteht, versteht man, warum ich so besessen davon bin, Fehler frühzeitig zu erwischen.

Die Kosten, einen Defekt zu beheben, steigen um das Zehnfache bei jeder folgenden Stufe des Design-Lebenszyklus. Ein Fehler, der während des RTL-Designs erwischt wird, kostet etwa 100 Dollar zur Behebung – jemand bearbeitet eine Datei und lässt eine Prüfung erneut laufen. Derselbe Fehler, der während der Block-Verifikation erwischt wird, kostet 1.000 Dollar. Bei der System-Verifikation 10.000 Dollar. Wenn er bis zur Post-Silizium-Validierung entkommt – wenn man tatsächliche Chips im Labor debuggt – reden wir von 10 Millionen Dollar oder mehr für einen Respin. Und wenn er im Feld beim Kunden ankommt? Das ist der Bereich von 100 Millionen Dollar. Rückrufe, Klagen, Markenzerstörung. Fragen Sie Intel zum Pentium-FDIV-Bug.

Die Wrapper-KI-Werkzeuge arbeiten fast ausschließlich auf der RTL-Designstufe. Sie helfen Ingenieuren, Code schneller zu schreiben. Aber weil ihnen jegliche Verifikationsfähigkeit jenseits von „kompiliert es" fehlt, injizieren sie Fehler, die durch die Block- und System-Verifikation segeln, nur um im Silizium zu detonieren.

Hier ist die grausame Ironie: Indem sie die Geschwindigkeit der Codegenerierung erhöhen, ohne die Strenge der Verifikation zu erhöhen, beschleunigen diese Werkzeuge die Injektion kostenintensiver Defekte in die Pipeline. Man bewegt sich nicht nur schnell und zerbricht Dinge. Man bewegt sich schnell und backt Fehler in 10-Millionen-Dollar-Maskensätze ein.

Branchendaten belegen das. Nur 32 % der Designs erreichen First-Silicon-Erfolg. Die verbleibenden 68 % erfordern mindestens einen Respin, und die Hauptursache sind Logik- und Funktionsfehler – genau die Art von Fehlern, die LLMs erzeugen, wenn sie Protokolle halluzinieren oder Nebenläufigkeit missverstehen.

Ich habe das einmal einem Investor erklärt, früh in unserer Finanzierungsrunde. Er hörte geduldig zu und sagte dann: „Können Sie nicht einfach GPT-4 mit besseren Prompts verwenden?"

Ich rief das Beispiel des Pipeline-Registers auf. Ich zeigte ihm den Blocking-Zuweisungs-Bug. Ich zeigte ihm, dass er das Linting bestand, die Simulation bestand, jede automatische Prüfung bestand, die die Wrapper-Werkzeuge boten. Dann zeigte ich ihm, was er im Silizium anrichten würde.

Er fragte nicht mehr nach besseren Prompts.

Was, wenn man Code als korrekt beweisen könnte, statt ihn nur zu testen?

Hier wendet sich die Geschichte. Denn die Antwort auf das Problem der LLM-Halluzination sind nicht bessere Prompts, größere Modelle oder mehr Trainingsdaten. Es ist ein grundlegend anderer Ansatz zur Verifikation.

Die traditionelle Verifikation beruht auf Simulation – man schreibt Testbenches, lässt Millionen von Zyklen laufen und prüft, ob das Design das tut, was man erwartet. Das ist, als würde man die Bremsen eines Autos testen, indem man tausendmal um den Block fährt. Wenn die Bremsen nicht versagen, geht man davon aus, dass sie sicher sind. Aber was, wenn sie nur versagen, wenn es regnet, man genau 100 km/h fährt und das Radio auf eine bestimmte Frequenz eingestellt ist? Simulation kann nur die Szenarien verifizieren, die sie explizit testet. Alles andere ist ein Gebet.

Die formale Verifikation führt das Design überhaupt nicht aus. Sie wandelt das gesamte Design in eine mathematische Formel um und verwendet SMT-Solver (Satisfiability Modulo Theories) – Werkzeuge wie Microsofts Z3 –, um erschöpfend zu beweisen, dass eine Eigenschaft unter jeder möglichen Eingabekombination und jedem internen Zustand gilt. Jeder einzelnen. Keine Stichprobe. Keine statistische Näherung. Ein mathematischer Beweis.

Simulation fragt: „Funktioniert das in den Fällen, die ich getestet habe?" Die formale Verifikation fragt: „Gibt es irgendeinen möglichen Fall, in dem das fehlschlägt?" Der Unterschied ist der Unterschied zwischen Hoffnung und Beweis.

Wenn der Solver „UNSAT" – unerfüllbar – zurückgibt, bedeutet das, dass kein Gegenbeispiel existiert. Die Eigenschaft ist mathematisch garantiert. Wenn er „SAT" zurückgibt, übergibt er einem eine spezifische Folge von Eingaben, die das Design zerbricht, bis auf den genauen Taktzyklus.

Die formale Verifikation existiert seit Jahrzehnten. Der Grund, warum sie die Industrie nicht übernommen hat, ist, dass das Schreiben der formalen Eigenschaften – SystemVerilog Assertions, kurz SVA – notorisch schwierig ist. Es erfordert ein spezialisiertes Kompetenzprofil, das die meisten Design-Teams nicht haben. Die Assertions sind der „Vertrag" für die Hardware: „Wenn Request auf High geht, muss Grant innerhalb von N Zyklen folgen." „Aus Adresse X gelesene Daten müssen mit den zuletzt an Adresse X geschriebenen Daten übereinstimmen." „Die Pipeline darf niemals in einen Deadlock geraten." Diese korrekt zu schreiben ist eine Kunstform, und es gibt nicht genug Fachleute, die sie beherrschen.

Genau hier wird KI nützlich – nicht zum Schreiben des Hardware-Codes, sondern zum Schreiben des Beweises.

Das „Formale Sandwich" – Wie wir das tatsächlich gebaut haben

Ich habe monatelang mit meinem Team über die richtige Architektur gestritten. Die Debatte war heftig und, im Nachhinein betrachtet, klärend. Ein Lager wollte ein LLM feinabstimmen, bis es standardmäßig korrektes Verilog generierte. Das andere Lager – dasjenige, dem ich mich schließlich anschloss – argumentierte, dass Korrektheit durch Training eine Fantasie sei. Man kann Halluzination nicht wegtrainieren. Man kann sie nur abfangen.

Wir landeten bei dem, was wir das „Formale Sandwich" nennen – eine neuro-symbolische Architektur, in der das LLM die kreative Engine ist und ein formaler Verifikations-Solver der unnachgiebige Kritiker. Keiner von beiden funktioniert allein. Gemeinsam vollbringen sie etwas, das keiner von ihnen unabhängig vollbringen kann.

So funktioniert es in der Praxis. Ein Designer stellt eine Spezifikation bereit – „Entwirf eine APB-zu-AXI-Bridge" oder sogar den Screenshot eines Timing-Diagramms. Unser Spec-Analyzer-Agent zerlegt diese in funktionale Anforderungen. Dann kommt die entscheidende Innovation: Statt nur Code zu generieren, generiert das LLM zwei Artefakte gleichzeitig.

Artefakt A ist die RTL-Implementierung – der Verilog-Code selbst. Artefakt B ist die formale Spezifikation – eine Reihe von SVA-Eigenschaften, die aus denselben Anforderungen abgeleitet sind. Wenn die Spezifikation sagt „Grant muss Request folgen", generiert das LLM die Zustandsmaschine und die Assertion, die beweist, dass die Zustandsmaschine tut, was sie behauptet.

Dann lassen wir den Solver los. Er nimmt Artefakt A und versucht, es mithilfe von Artefakt B zu zerbrechen. Zuerst eine Vacuity-Prüfung – um sicherzustellen, dass die Assertions nicht trivial wahr sind (eine „faule" Generierung, bei der die Auslösebedingung nie eintritt). Dann Bounded Model Checking, das tiefe Zustandsräume erkundet – 50, 100 Zyklen tief – auf der Jagd nach Deadlocks, Race Conditions, Protokollverletzungen.

Wenn der Solver einen Fehler findet, kennzeichnet er ihn nicht nur. Er erzeugt eine Gegenbeispiel-Trace – eine präzise Wellenform, die genau zeigt, wie sich der Fehler manifestiert. Und hier schließt sich die Schleife: Wir speisen diesen Trace als Prompt zurück in das LLM. „Dein Design ist fehlgeschlagen. Hier ist der Trace: Zyklus 1, Reset wird aufgehoben. Zyklus 2, Request geht auf High. Zyklus 10, Grant ist immer noch Low. Der Grant kam nie an. Repariere die Zustandsmaschine."

Das LLM analysiert den Trace, identifiziert den fehlenden Zustandsübergang, schreibt den Code um. Der Solver prüft erneut. Diese Schleife wiederholt sich automatisch, bis das Design als korrekt bewiesen ist.

Ich habe über diese Architektur viel ausführlicher in der interaktiven Version unserer Forschung geschrieben, aber die Kernerkenntnis ist einfach: Wir nutzen KI, um den Beweis zu schreiben, und Mathematik, um die KI zu prüfen. Keiner vertraut dem anderen. Beide machen den anderen besser.

Die Fehler, die mich zum Überzeugten machten

Ich wurde zu einem echten Überzeugten dieses Ansatzes nicht durch Theorie, sondern durch konkrete Fehler, die wir erwischten und die nichts anderes gefunden hätte.

Die Open-Source-RISC-V-Community hat wirklich exzellente Prozessorkerne hervorgebracht – Ibex (verwendet in Googles OpenTitan-Sicherheitschip), die PULP-Plattform der ETH Zürich. Das sind stark geprüfte Designs mit echtem Ingenieurstalent dahinter. Und sie enthalten trotzdem Fehler, die nur die formale Verifikation finden kann.

Axiomise, ein Beratungsunternehmen für formale Verifikation, fand im Ibex-Kern einen Fehler, bei dem eine Debug-Anfrage, die zu einem bestimmten Zyklus während einer Branch-Instruktion eintraf, den Kern in einen Deadlock geraten oder die falsche Instruktion ausführen lassen konnte. Denken Sie darüber nach – ein sicherheitskritischer Kern, geprüft von Dutzenden Ingenieuren, und ein formales Werkzeug fand einen Fehler, den die Simulation vollständig übersah.

In der PULP-Plattform wurde ein Fehler gefunden, bei dem die AXI-Interconnect einen Bus-Master unter einem bestimmten „Busy"-Muster von AWVALID- und AWREADY-Interaktionen unbegrenzt aushungern konnte. Ein klassisches Liveness-Versagen – das System stürzt nicht ab, es macht einfach keine Fortschritte mehr. Man würde niemals einen gerichteten Test für dieses spezifische Interaktionsmuster schreiben. Es gibt zu viele mögliche Muster, um sie aufzuzählen.

Wenn wir Veriprajna auf eine RISC-V-Load-Store-Unit ansetzen, generiert es automatisch Assertions für die Schnittstellenkonformität („wenn Valid ausgelöst wird, muss es High bleiben, bis Ready kommt"), die Datenintegrität („aus Adresse X gelesene Daten stimmen mit dem letzten Schreibvorgang an Adresse X überein") und den Fortschritt („die Unit muss letztlich eine Antwort zurückgeben"). Das sind keine nachträglich an den Code angeschraubten Überlegungen. Sie werden neben dem Code aus derselben Spezifikation generiert und durchgesetzt, bevor eine einzige Zeile RTL unser System verlässt.

Für die vollständige technische Aufschlüsselung unserer Methodik und der Engine für formale Verifikation siehe unser ausführliches Forschungspapier.

„Aber formale Verifikation skaliert nicht"

Bei diesem Punkt gibt es immer Widerspruch, und ich verstehe, warum. Die formale Verifikation hat den Ruf, rechnerisch explosiv zu sein – der Zustandsraum eines modernen SoC ist astronomisch groß, und naive formale Ansätze verschlucken sich an allem, was größer ist als ein Spielzeug-Design.

Wir haben erheblichen Aufwand darauf verwendet. Unser System nutzt automatisierte Abstraktionstechniken, um formale Methoden im großen Maßstab handhabbar zu machen. Black-Boxing erlaubt uns, die Glue-Logik zu verifizieren, während wir große Teilblöcke wie RAMs oder komplexe ALUs als abstrakte Entitäten mit definierten Schnittstellen behandeln. Cut-Points durchtrennen Valid/Ready-Handshake-Pfade, sodass wir die Flusskontrolle unabhängig von der Datenverarbeitung verifizieren können. Symmetriereduktion erlaubt uns, eine Eigenschaft für einen Kanal eines Multi-Port-Routers zu beweisen und sie mathematisch für alle N Kanäle zu induzieren.

Ist es vollständig gelöst? Nein. Analoge Physik wird immer Herausforderungen bieten, die formale Methoden nicht berühren können. Aber die Logikfehler – die Race Conditions, die Deadlocks, die Protokollverletzungen – werden im generierten Code mathematisch unmöglich. Und das sind die Fehler, die Respins verursachen.

Der andere Einwand, den ich höre, betrifft die Geschwindigkeit. „Verlangsamt das Ausführen eines formalen Solvers nicht den Designprozess?" Ja, es verursacht Rechenkosten. Aber ich tausche jeden einzelnen Tag Rechenzeit gegen Terminsicherheit. Ein formaler Solver, der eine zusätzliche Stunde läuft, ist unendlich viel günstiger als ein sechsmonatiger Respin.

Die unbequeme Wahrheit über „KI-designte Chips"

In der Branche gewinnt eine Erzählung an Zugkraft – dass KI bald Chips durchgängig entwerfen wird, dass wir uns von Computer-Aided Design zu Computer-Automated Design bewegen. Ich glaube, diese Erzählung ist in der Richtung korrekt, aber gefährlich unvollständig.

Wir arbeiten auf agentische Workflows hin, in denen autonome KI-Agenten zusammenarbeiten – ein Architekten-Agent für die Partitionierung auf hoher Ebene, ein RTL-Coder für die Implementierung, ein Verifikationsingenieur zum Schreiben von Testbenches und Assertions, ein Manager, der den Ablauf gegen Leistungs-, Performance- und Flächenvorgaben orchestriert. Wir nutzen Retrieval-Augmented Generation (RAG) nicht nur für Code, sondern für Wissen – wir ziehen spezifische Protokollregeln, Constraints des Process Design Kit und interne Codierungsstandards heran, damit das LLM konformen Code generiert, ohne zu halluzinieren.

Aber nichts davon funktioniert – nichts davon – ohne ein Rückgrat aus formaler Verifikation. Je autonomer die KI wird, desto entscheidender ist es, dass jede Ausgabe mathematisch verifiziert wird, bevor sie stromabwärts weiterwandert. Ein KI-Agent, der schneller Code generiert, ist nur dann wertvoll, wenn dieser Code korrekt ist. Ein KI-Agent, der schneller Code generiert und ihn als korrekt beweist? Das ist die Zukunft.

Das Problem der Halbleiterindustrie ist nicht, dass KI zu langsam beim Schreiben von Hardware-Code ist. Es ist, dass KI zu schnell beim Schreiben von Hardware-Code ist, der subtil falsch ist.

Wir sind kein Copilot. Wir sind kein Chatbot. Wir sind eine Foundry für formale Verifikation, die zufällig generative KI als Frontend verwendet. Die Unterscheidung ist wichtig, weil sie bestimmt, worauf man optimiert. Copiloten optimieren auf Geschwindigkeit. Wir optimieren auf Korrektheit. In einer Welt, in der ein einziger entkommener Fehler 10 Millionen Dollar an Masken und 50 Millionen Dollar an entgangenem Umsatz kostet, weiß ich, welche Optimierung ich wählen würde.

Die Entscheidung ist bereits gefallen

Die Halbleiterindustrie kann sich den „Generieren-und-Beten"-Ansatz nicht länger leisten. Die Zehnerregel ist keine Empfehlung – sie ist Physik und Ökonomie, die sich verschwören, um jeden zu bestrafen, der unverifiziertes Silizium ausliefert. Bei 5 nm und darunter, mit Maskensätzen, die sich 20 Millionen Dollar nähern, ist die Fehlermarge auf null geschrumpft.

Jede Woche spreche ich mit Design-Teams, die begeistert sind von dem, was LLMs für ihre Produktivität leisten können, und zugleich verängstigt von dem, was LLMs mit ihrem Tape-out-Zeitplan anrichten könnten. Sie haben recht, beides gleichzeitig zu empfinden. Die Technologie ist wirklich transformativ. Sie ist ohne ein Sicherheitsnetz auch wirklich gefährlich.

Veriprajna ist dieses Sicherheitsnetz. Wir geben Ihnen die Geschwindigkeit der KI mit der Gewissheit der Mathematik. Nicht „wahrscheinlich korrekt". Nicht „Regression bestanden". Bewiesen korrekt, über jede mögliche Eingabe, jeden möglichen Zustand, jeden möglichen Grenzfall, den eine Simulation nie zu testen in Betracht ziehen würde.

Die Entscheidung, vor der jeder Chip-Designer heute steht, ist nicht, ob KI eingesetzt werden soll. Dieser Zug ist abgefahren. Die Entscheidung ist, ob man KI einsetzt, die ihre eigene Arbeit beweisen kann, oder KI, die einfach auf das Beste hofft.

Ich weiß, auf welche ich 10 Millionen Dollar setzen würde.