Wen Ming, Gründer von API7.ai: Nach dem Verbrauch von mehreren zehn Milliarden Tokens habe ich ein Produktions-Gateway mit KI neu geschrieben und 6 Erkenntnisse zusammengefasst
Das erste Mal, als ich wirklich Veränderungen spürte, war während des Frühlingsfestes 2026.
Zu der Zeit stießen wir bei Apache APISIX auf einen sehr kniffligen Bug: Wir hatten viele Methoden ausprobiert, um ihn zu reproduzieren, aber es war nicht gelungen. Auch nach mehrfachem Lesen des Codes konnten wir den Fehler nicht lokalisieren. Schließlich stellten wir noch eine letzte Hoffnung in einen AI-Agenten und beschrieben ihm das Phänomen des Bugs. Innerhalb von weniger als 10 Minuten wies er mit Hilfe einer statischen Codeanalyse und unserer Beschreibung des Phänomens genau auf den Fehler hin.
In diesem Moment war ich wirklich beeindruckt.
Später wagten wir noch etwas Bolderes: Könnte der Agent ein produktionsreifes Projekt wie Apache APISIX erstellen? Er konnte es nicht in einem halben Tag von der Architektur über den Code, die Tests bis hin zur Dokumentation vollständig nachbauen. Aber wenn man ihm die Architektur, den Technologiestack sowie die zentralen Konzepte und ihre Beziehungen erklärt, kann er in einem halben Tag die Code-Menge schreiben, die wir früher drei Monate lang brauchten. Das ist kein Problem.
Was das Schreiben von Code angeht, bin ich ganz sicher: Die AI hat die Fähigkeiten eines erfahrenen Softwareingenieurs erreicht und sogar übertroffen. Das ist unbestritten.
In den letzten ein bis zwei Monaten habe ich allein schon Hunderte von Milliarden Tokens für die Softwareentwicklung mit AI verbraucht. Je mehr Tokens ich verbrauche, desto sicherer bin ich mir einer Sache: Der Engpass liegt nicht bei der AI. Die Fähigkeiten der AI überschießen, und es ist der Mensch, der hinterherhinkt. Folgende Punkte sind Erfahrungen, die ich aus diesem Token-Verbrauch gewonnen habe. Es sind keine großen Theorien, sondern eher praktische Einsichten.
Die AI sieht das Was und kann das Wie umsetzen, aber das Warum muss der Mensch noch selbst klären.
Wenn die AI so gut im Schreiben von Code ist, was ist dann der wahre Wert eines erfahrenen Softwareingenieurs?
Ich denke, es sind die Fehler, die er in den Jahren gemacht hat, die technischen Abwägungen und Entscheidungen, die er getroffen hat, sowie die Erfahrungen, die er daraus gewonnen hat. Diese Dinge sind in keiner öffentlichen Wissensbasis gut dokumentiert.
Wenn man sich Apache APISIX ansieht, sieht man ein fertiges Produkt. Aber die inneren Denkprozesse, die abstrakten Konzepte und die Architekturplanung, also das Warum dahinter, sind für die AI unsichtbar. Sie kann das Was verstehen und das Wie umsetzen, aber bei der Bewertung, Beurteilung und Entscheidung über das Warum gibt es noch deutliche Unterschiede im Vergleich zu einem erfahrenen Ingenieur.
Einfach ausgedrückt: Sie übernimmt das Tippen, nicht aber die Vorstellung in meinem Kopf.
Mein Verbot des manuellen Code-Schreibens in der Firma provozierte vor allem die "Territorialität"
Ich habe in der Firma eine umstrittene Entscheidung getroffen: Wir sollten so wenig wie möglich manuell Code schreiben und die Aufgabe des "Tippens" an einen AI-Agenten übergeben.
Die stärkste Gegenreaktion kam von den Ingenieuren, die sich sehr klar definiert haben: "Ich bin Frontend-Entwickler" oder "Ich bin Backend-Entwickler". Wenn man sich selbst so einschränkt, fühlt man sich mit einem Tool wie dem AI-Agenten, das so leicht Grenzen überschreitet, unwohl.
Ich gebe ein Beispiel aus meiner eigenen Erfahrung. Früher musste man als Frontend-Entwickler mit Frontend-Technologien, Ästhetik, Leistung, SEO und verschiedenen Frameworks vertraut sein, um ein anständiger Entwickler zu sein. Aber jetzt kann auch jemand wie ich, der fast nie Frontend-Code geschrieben hat, ein recht gutes Dashboard erstellen. Das hat nichts mit der Technik zu tun, sondern damit, ob man die Kriterien für Frontend-Entwicklung benennen kann: Welche Farbpalette soll verwendet werden, sollen die Ressourcen über CDN geladen werden, muss die Mobile-Anpassung berücksichtigt werden. Wenn man diese Dinge klar beschreibt, kann man eine Seite erstellen, die etwa 60 - 70 Punkte erreicht.
Dies ist eine ganz andere Perspektive für die Definition und Iteration von Produkten. Früher musste für eine Benutzeranforderung eine Zusammenarbeit zwischen Produktmanager, Architekt, Frontend- und Backend-Entwickler erfolgen, um das Produkt auszuliefern. Heute ist es üblich, dass ein Mitarbeiter, der die Lösung erstellt oder sogar verkauft, nach der Beschreibung der Benutzeranforderung direkt mit dem AI-Agenten im Produkt Änderungen vornehmen und eine Simulation erstellen kann, um dem Benutzer zu zeigen: "Ist das, was Sie möchten?" Dieser Prozess, der früher Wochen dauerte, wird jetzt in weniger als einer halben Stunde abgeschlossen.
Deshalb sind diejenigen, die diese Entscheidung für "verrückt" oder "verantwortungslos" halten, oft diejenigen, die sich zu eng einschränken oder die AI noch nicht wirklich intensiv genutzt haben. Wenn man die AI intensiv genutzt hat und keine starke "Territorialität" hat, wird man feststellen, dass es ein ausgezeichnetes Werkzeug ist.
Naturgemäß stimmen nicht alle in der Firma mit mir überein. Meiner Empfehlung nach können sie anderer Meinung sein, aber sollten die besten Large Language Models nutzen und ihnen freien Lauf lassen. So erfahren sie, wo die Grenzen der AI liegen.
Die stärkste Gegenreaktion kam tatsächlich von den erfahrensten Ingenieuren: Sie sind überzeugt, dass die von der AI erstellten Programme nur Spielereien sind.
Ob Spielerei oder produktionsreif, die Grenze liegt beim Menschen, nicht im Code
Also, ist es nun eine Spielerei oder ein produktionsreifes Produkt?
Oft wird mir gefragt: Welchen Code kann man an die AI übergeben und welchen nicht? Ich denke, diese Frage ist falsch gestellt. Anstatt zwischen verschiedenen Code-Typen zu unterscheiden, gibt es ein wesentlich zentraleres Kriterium: Hat die Person, die die AI steuert, ein klares Verständnis von Architektur, Code und Tests? Hat sie eine gewisse Achtung vor der Inbetriebnahme eines Produkts?
Keine Person, die sich für Technik und Code begeistert, kann selbst einfachen CRUD-Code mit Hilfe der AI gut schreiben.
Warum muss der Mensch in die Entscheidungsprozesse involviert sein? Selbst wenn die Entscheidungsgenauigkeit der AI 85 % oder 90 % beträgt, reichen die verbleibenden 10 % aus, um die Qualität eines gesamten Projekts stark zu beeinträchtigen. Die AI kann nicht immer die richtigen Entscheidungen treffen, aber der Mensch muss an den Entscheidungen beteiligt sein. Ich habe mir eine Regel gegeben: Wenn Sie eine Entscheidung nicht verstehen, sollten Sie sie nicht treffen.
Ich gebe ein Beispiel aus unserem eigenen Bereich. Kürzlich haben wir ein neues Projekt begonnen - ein AI-Gateway namens AISIX. In diesem Projekt haben wir stark auf Claude Code zur Codeerstellung zurückgegriffen. Aber die Konzeption der Kernideen, die Auswahl der Architektur, der Fortschritt der Meilensteine und die Abwägungen bei der Technologieauswahl wurden nicht an die AI übergeben. In diesem Projekt dient die AI nur als Hilfsmittel.
Wie kann man die AI kontrollieren? Man muss sie dazu bringen, End-to-End-Tests durchzuführen, Klick-Tests auf den Kernpfaden des Dashboards durchzuführen und eine umfassende Dokumentation zu schreiben. Die AI bleibt immer ein Werkzeug, und in den Händen verschiedener Menschen wird sie völlig unterschiedliche Ergebnisse liefern.
Der von der AI geschriebene Code muss von einer anderen AI überprüft werden.
Dies ist für Menschen unmöglich. Die AI kann pro Tag Dutzende von Pull Requests und Tausende von Codezeilen erstellen. Ein Mensch kann das nicht überblicken, daher müssen wir auf einen Prozess setzen.
Unsere Vorgehensweise ist folgende: Wir schreiben den Code mit Claude Code. Anschließend lassen wir einen neuen, unabhängigen AI-Agenten starten, um diesen Pull Request zu überprüfen - also schreiben wir mit Claude Code und lassen ihn auch überprüfen. Gleichzeitig verwenden wir CodeRabbit und GitHub Copilot als zweite Stufe. Der von einer AI geschriebene Code muss mindestens von einer anderen AI überprüft werden.
Aber noch wichtiger als die "Überprüfungsmethode" ist die Tatsache, dass die Stabilität eines Projekts nicht davon abhängt, wie schön der Code geschrieben ist oder wie beeindruckend die Architektur ist. Vielmehr hängt es davon ab, dass viele Benutzer das Produkt in der Produktionsumgebung verwenden, dass Probleme auftauchen und dass man dann ständig iteriert und verbessert. Nur wenn es von Menschen genutzt wird, wird es immer besser. Der revolutionäre Aspekt der AI ist, dass sie die Iterationsgeschwindigkeit auf ein Maximum bringt - alle Rückmeldungen und alle Bugs können ich schnell lokalisieren und beheben.
Ich gebe ein konkretes Szenario. Ein Benutzer meldet um 2 Uhr morgens einen Bug. Zuerst wird eine AI die erste Analyse durchführen und feststellen, in welchem Produkt das Problem liegt. Dann wird sie eine statische Analyse anhand der Versionsnummer, des Szenarios und des Fehlersprotokolls durchführen. In über der Hälfte der Fälle kann das Problem bereits in diesem Schritt genau lokalisiert werden. Wenn dies nicht möglich ist, wird sie automatisch eine Reproduktionsumgebung aufsetzen und den Code und die Plugins der entsprechenden Version in einem echten End-to-End-Test ausführen, um verschiedene Möglichkeiten zur Reproduktion zu versuchen.
Die Lokalisierung des Problems reicht aber nicht aus. Dann muss ein unabhängiger Agent in einer unabhängigen Umgebung gestartet werden, um das Problem erneut zu reproduzieren und eine doppelte Prüfung durchzuführen.
Was macht dann der Mensch? Der Mensch optimiert ständig diesen automatisierten Prozess: Er ändert die Prompts, wechselt das Modell, verbessert die Reproduktionsszenarien und bringt seine eigenen Erfahrungen ein. Die endgültige Entscheidung wird immer noch vom Menschen getroffen. Nachts um 2 Uhr ist man möglicherweise nicht so klar im Kopf, aber die AI hat bereits die Codeanalyse, die Umgebungseinrichtung und die ungefähre Position des Problems vorbereitet. Was früher eine halbe Stunde oder eine Stunde gedauert hätte, ist jetzt in zehn Minuten erledigt. Der Mensch muss nur die endgültige Entscheidung treffen.
Deshalb denke ich, es spielt keine Rolle, ob eine Firma viele oder wenige Mitarbeiter hat. Wichtiger ist, dass sie zuerst "dick" wird und dann "groß".
Ich treffe jetzt täglich 40 - 50 Entscheidungen
Die Softwareentwicklung mit AI habe ich grob in drei Phasen unterteilt.
Erste Phase: Aufbau von Frameworks. Ich nutze verschiedene Harness - wie ECC, Oh My OpenCode, die Sammlungen von Skills und Prompts sind - um ein Softwareprojekt aufzubauen. Man stellt fest, dass es helfen kann, Blindstellen zu finden. Viele Agenten arbeiten parallel an den Aufgaben, und es fühlt sich an, als würde man ein Team leiten.
Zweite Phase: Wegwerfen der Frameworks. Man möchte nicht mehr so aufwändige Frameworks verwenden und möchte lieber die Kontrolle in die eigenen Hände nehmen. Der Grund ist einfach: Die Large Language Models sind inzwischen intelligent genug. Man muss ihnen nur sagen: "Führe einen End-to-End-Test durch" oder "Optimiere diese Seite", und sie können sich selbst informieren, verstehen und gut arbeiten. Es ist nicht mehr notwendig, so aufwändige externe Frameworks zu nutzen. Der wahre Wert, den man ihnen geben kann, ist die eigene Erfahrung, die man in 10 - 20 Jahren gesammelt hat. Man kann diese Erfahrungen in eine Datei wie agents.md oder CLAUDE.md mit etwa 100 Zeilen zusammenfassen - eine Datei, die eher auf Prinzipien und Erfahrungen basiert. Die AI kann diese Datei bei jeder Aufgabe laden. Mit anderen Worten: Man wirft die Erfahrungen, die man von anderen bekommen hat, weg und behält die eigenen.
Dritte Phase: Übergang von "Sucht-Coding" zu "Qualitäts-Entscheidungen". In der zweiten Phase stellt man fest, dass man sehr viele Entscheidungen treffen muss. Früher hat man pro Tag zwei oder drei technische Entscheidungen getroffen. Jetzt, mit der Unterstützung der AI, muss man 40 - 50 Entscheidungen pro Tag treffen. Die menschliche Energie reicht dazu nicht aus.
Was heißt "Sucht-Coding"? Ich habe versucht, der AI am Abend eine große Aufgabe zu geben, damit sie die Nacht lang arbeitet. In der Firma habe ich ständig mit der AI iteriert und Entscheidungen getroffen. Nach Hause komme ich und muss alle 10 - 20 Minuten eine Entscheidung treffen. Am Abend gebe ich ihr noch eine große Aufgabe. Ich schlafe schlecht und stehe früh auf, um den Fortschritt zu überprüfen. Es sieht so aus, als wäre ich sehr fleißig, aber die Ergebnisse verschlechtern sich.
Deshalb habe ich jetzt einen anderen Rhythmus: Ich arbeite an fünf oder sechs Projekten gleichzeitig. Wenn ich eine Entscheidung treffen muss, kläre ich zuerst die Logik hinter der Entscheidung und iteriere dann zusammen mit der AI. Wichtige Entscheidungen und die Auswahl der Architektur werden vom Menschen getroffen. Die Maschine hilft mir bei der Recherche, füllt Lücken und erweitert mein Horizont. Am Ende trifft der Mensch die Entscheidung, und die Maschine führt sie aus und schreibt den Code.
Bei fünf oder sechs Projekten gleichzeitig treffe ich pro Tag etwa 40 - 50 hochwertige Entscheidungen. Von 7 - 8 Uhr morgens bis 3 - 4 Uhr Nachmittags ist die menschliche Energie fast aufgebraucht. Deshalb versuche ich, alle hochwertigen Entscheidungen zwischen Morgen und 3 - 4 Uhr Nachmittags zu treffen. Den Rest der Zeit nutze ich, um mich durch Lesen und Sport zu erholen. Am Abend und an den Wochenenden versuche ich, nicht mit der AI zu arbeiten. Sonst sinkt die Qualität meiner Entscheidungen, und ich werde in eine endlose Iteration verwickelt - und in diesem Zustand kann ich der Softwarequalität nicht mehr helfen, weil ich keine guten Entscheidungen mehr treffen kann.
Was die erwähnten Hunderte von Milliarden Tokens angeht: Es spielt keine Rolle, ob man 100 Millionen oder 10 Milliarden Tokens verbraucht. Das Wichtige sind zwei Dinge: Haben Sie Ihre Erfahrungen in die MD-Datei eingebracht? Können Sie hochwertige Entscheidungen effizient treffen? Noch einmal: Die Fähigkeiten der AI überschießen, und es ist der Mensch, der hinterherhinkt.
Abschließend noch ein Gedanke: Mit demselben Modell und denselben Prompts können verschiedene Menschen völlig unterschiedliche Ergebnisse erzielen. So wie 1,1 hoch 100 eine sehr große Zahl ist, während der Unterschied zwischen 1,01 hoch 100 und 1,1 hoch 100 riesig ist. Ein erfahrener Ingenieur kann die Entscheidungsgenauigkeit der AI von 80 % auf 85 % erhöhen. Ein unerfahrener Ingenieur bleibt möglicherweise bei 80 %. Wenn man über den Tag hinweg Dutzende von Entscheidungen trifft, wird sich der Unterschied in der Qualität der entwickelten Software immens auswirken.
Warum haben wir ein neues Gateway neu geschrieben?
Vor zwei Jahren war der AI-Datenverkehr bereits vorhanden, aber noch nicht sehr hoch. Unser erster Gedanke war, in Apache APISIX Plugins zu verwenden, um diesen neuen Datenverkehr zu verwalten - schließlich scheinen AI-Datenverkehr und API-Datenverkehr ähnlich zu sein: Begrenzung der Rate, Lastverteilung, Fallback, Gesundheitsüberprüfung und Authentifizierung. Sind sie nicht im Wesentlichen das Gleiche?
Aber während der Entwicklung stellten wir fest, dass sie zwar auf der Oberfläche ähnlich sind, aber die Kernkonzepte unterschiedlich sind. Die Kernkonzepte eines API-Gateways sind Routing, Service, Consumer und Plugins. Die Kernkonzepte des AI-Datenverkehrs sind LLM-Provider und virtuelle API-Schlüssel. Wenn man Funktionen hinzufügt, die nur in AI-Szenarien benötigt werden - wie die Modellkonsensus (mehrere Large Language Models liefern jeweils ein Ergebnis, das dann zu einer Entscheidung zusammengefasst wird) oder semantisches Routing - passt es nicht gut in ein API-Gateway. Es ist nicht unmöglich, aber es fühlt sich nicht natürlich an.
Deshalb haben wir ein neues AI-Gateway nam