Kategorie: Erklärer

Du schaltest im Hochsommer die Klimaanlage ein, die Fenster sind offen, die Kälte entweicht. Die Stromrechnung steigt, die Wohnung bleibt warm. Viele Unternehmen mit Künstlicher Intelligenz geht es ähnlich. Die Kosten für KI, gemessen in Tokens, den kleinsten Verarbeitungseinheiten von Sprachmodellen, explodieren. Ein Großteil der Ausgaben bringt kein Produkt hervor.

Sam Altman, CEO von OpenAI, sagte im Juni 2025, Intelligenz werde bald so billig sein wie Strom. Ein Jahr später sind KI-Kosten eher wie eine Stromrechnung im Hochsommer bei offenen Fenstern. Unternehmen berichten, ihr Jahresbudget für Tokens sei in wenigen Monaten aufgebraucht. Manche Firmen überdenken oder canceln KI-Initiativen komplett. Schlagzeilen über „Tokenmaxxing“ – exzessiven Token-Verbrauch – und explodierende Budgets lassen Zweifel am KI-Hype aufkommen. Das Problem ist nicht der Verbrauch an sich, sondern die Verschwendung von Tokens für unproduktive Zwecke.

Das Startup EntelligenceAI veröffentlichte eine Zahl: Von jedem Dollar für KI landen nur 18 Cent in der Produktion. 82 Cent fließen in Fehlerbehebungen, Umschreibungen, Code-Überarbeitungen und Reviews. Die Schätzung mag ungenau sein, zeigt aber eine klare Tendenz. Tokenmaxxing lässt sich durch Budgetkontrollen oder Entfernen von Leaderboards eindämmen. Das eigentliche Problem ist die unproduktive Nutzung. Die Lösung ist nicht mehr Kontrolle, sondern echte produktive Anwendungen zu finden.

Andrew Macdonald, COO von Uber, sagte, KI-Ausgaben seien schwer zu rechtfertigen, weil sie nicht direkt zu Produktivitätssteigerungen führen. Sein Tweet wurde viel geteilt. Wenn Ubers Erfahrung repräsentativ ist, steht der Branche eine Phase langsamen Wachstums bevor. Negative Geschichten über KI verbreiten sich schneller als positive. Viele Unternehmen finden durchaus produktive Einsätze. Trotzdem muss die Branche den Return on Investment klären, sonst droht ein Rückschlag.

Die Lage ist angespannt. Microsoft Build Anfang Juni wird voraussichtlich neue KI-Modelle und Updates für Copilot bringen. Gleichzeitig eskaliert der Konflikt zwischen Medien und KI-Firmen: A.G. Sulzberger, Verleger der New York Times, warf OpenAI, Google, Meta und Perplexity vor, Journalismus zu untergraben. Floridas Generalstaatsanwalt verklagte OpenAI und Sam Altman wegen angeblicher Schäden durch Chatbots für Minderjährige – erstmals klagt ein US-Bundesstaat so.

NVIDIA kündigte den Superchip RTX Spark an, der Windows-PCs für persönliche KI-Agenten antreiben soll. Das bringt NVIDIA in direkten Wettbewerb mit Intel, Qualcomm, AMD und Apple. OpenAI veröffentlichte ein „Frontier Governance Framework“ und stellte 250 Millionen Dollar über die OpenAI Foundation bereit, um Arbeitskräfte auf KI-bedingte Umwälzungen vorzubereiten.

Anthropic schloss eine Serie-H-Finanzierung über 65 Milliarden Dollar bei einer Bewertung von 965 Milliarden Dollar ab. Damit ist Anthropic das wertvollste KI-Startup der Welt, vor OpenAI. Der annualisierte Umsatz lag im Mai bei 48 Milliarden Dollar. Anthropic launchte Claude Opus 4.8 mit Verbesserungen in Codierung, Agentenaufgaben, Finanzanalyse, Schreiben und Wissensarbeit. Die Kosten pro Token sind dreimal niedriger, die Geschwindigkeit 2,5-mal höher als beim Vorgänger. Kunden wie Shopify, Cursor, Harvey, BrowserBase, Bridgewater, Thomson Reuters und Databricks nutzen es. OpenAIs Codex bleibt für alltägliche Programmieraufgaben stärker. Anthropic kündigte auch dynamische Workflows in Claude Code an, die parallele Sub-Agenten orchestrieren, etwa für Bug-Jagden oder Stresstests. Zudem reichte Anthropic den Börsengang ein.

Die Frage bleibt: Sind die Investitionen in KI gerechtfertigt? Unternehmen wie Uber zeigen, dass hoher Token-Verbrauch nicht automatisch Produktivität bringt. Firmen investieren in KI, weil sie glauben, dass Konkurrenten es tun. Dann steigen die Kosten, ohne klare Ergebnisse. Manche Analysten vergleichen die Situation mit den Anfängen des Internets, als viel Geld in unausgereifte Technologien floss. Der Unterschied heute: Die Technologie funktioniert, aber die Anwendung hinkt hinterher.

Speicherchips werden knapp und teuer, weil Rechenzentren ausgebaut werden. Wenn die Tokens nicht in produktive Anwendungen fließen, bleibt die Nachfrage künstlich. Robinhood erlaubt inzwischen, dass Chatbots für dich handeln. Eine andere Frage: Würdest du dein Gmail mit ChatGPT verbinden? Und würdest du deine Wohnung kostenlos putzen lassen, wenn der Putzroboter die Aufnahmen für Trainingdaten nutzt? Diese Fragen zeigen die Nähe zwischen Nutzen und Datenschutz.

Die Token-Abrechnung ist ein Weckruf. Unternehmen müssen weg vom bloßen Verbrauch und hin zu messbarem Nutzen. Wer blind Tokens verbrennt, steht morgen mit leeren Kassen da. Wer auf echte Produktivität setzt, kann profitieren. Der Weg dorthin erfordert Disziplin, nicht nur Technologie.

Quelle: bigtechnology.com

Ein Team von PostHog in Lissabon ließ einen KI-Agenten auf ihre Datenbank-Query-Engine los. Der Agent fand einen Bug, der fast drei Jahre lang unentdeckt in der Codebasis lag. Der Fix verbesserte die Performance deutlich – ohne Änderung der Abfragelogik.

Die Grundidee stammt von Andrej Karpathy. Im März 2026 veröffentlichte er das Repository „Autoresearch“. Der Kern: ein KI-Agent bekommt ein kleines System, einen Benchmark und ein Budget. Er durchläuft eine Schleife: eine Änderung vorschlagen, den Benchmark ausführen, Verbesserungen behalten und Verschlechterungen verwerfen. Karpathy ließ den Agenten zwei Tage auf einem kleinen neuronalen Netz laufen. Er fand rund zwanzig Änderungen, die den Validierungsfehler senkten. Einige übertrugen sich auf größere Modelle. Das Prinzip ist nicht neu – DeepMind veröffentlichte 2023 FunSearch, Sakana 2024 den AI Scientist. Karpathys Version ist jedoch konkret genug, um an einem Nachmittag eine eigene Implementierung zu bauen.

Das PostHog-Team nutzte diesen Ansatz für ein Hackathon-Projekt auf einem Offsite. Ziel: die Performance von ClickHouse automatisieren, der Datenbank hinter ihrer Produktanalytik. Sie verwendeten pi, einen Terminal-Coding-Agenten von Mario Zechner, der mit jedem LLM spricht. Dazu kam pi-autoresearch, eine Community-Erweiterung von davebcn87, die Karpathys Schleife in pi integriert. Darüber bauten sie eine Kampagnen-Orchestrierung, die den Optimierungsprozess strukturiert, damit der Agent systematisch vorgeht.

Der Aufbau: Eine Kampagne hat eine langsame Query und einen Git-Branch. Sie ist in Lanes unterteilt – Optimierungsrichtungen wie Prädikatsreihenfolge, JSON-Parsing, Zeitzonen-Handling, Primärschlüssel-Nutzung. Jede Lane enthält eine konkrete, testbare Hypothese. Jede Hypothese wird in einem Experiment mit genau einem Durchlauf, Benchmark und Urteil getestet. Nach jedem Experiment muss der Agent eine Reflexion durchführen. Dazu kommt ein eigener ClickHouse-Testcluster mit denselben Daten wie die Produktion, aber anonymisiert und auf günstigerer Hardware. So bleibt die Iterationsgeschwindigkeit hoch und Kundenabfragen werden nicht gestört.

Das Team fütterte dem Agenten zunächst händisch langsame Queries – solche, über die sie sich bereits geärgert hatten, und solche aus system.query_log. Eine dieser Queries war ein Trichter über sieben Tage für ein echtes Team. Hier stieß der Agent auf den sogenannten „Drei-Jahres-Bug“.

ClickHouse ist schnell, weil es Arbeit überspringen kann. Die Tabelle events ist nach toYYYYMM(timestamp) partitioniert. Der Primärschlüssel ist (team_id, toDate(timestamp), event, …). Eine gut geschriebene Query mit Zeitstempel-Filter sollte ClickHouse erlauben, ganze Monate zu überspringen (Partition Pruning) und direkt zur richtigen Woche zu springen. Das passierte nicht. Im April 2023 hatte das Team Zeitzonen-Unterstützung für HogQL hinzugefügt. Der vernünftige Weg: Jeden Verweis auf timestamp in toTimeZone(timestamp, team_tz) wickeln. Was sie nicht bedachten: Der ClickHouse-Queryplaner kann nicht durch toTimeZone() hindurchsehen. Er kann nicht ableiten, dass die Bedingung toTimeZone(timestamp, tz) >= '2024-03-01' bedeutet, dass toYYYYMM(timestamp) auf bestimmte Monate reduziert werden kann. Partition Pruning war ausgeschaltet. Auch der Primärschlüssel toDate(timestamp) wurde nicht genutzt – er beschränkte sich auf team_id und event und hörte dann auf.

Warum der Bug nicht früher auffiel? ClickHouse hat einen MinMax-Skip-Index auf timestamp. Ein MinMax-Index speichert den kleinsten und größten Wert einer Spalte pro Granula (8192 Zeilen). Vergleicht man toTimeZone(timestamp, tz) mit einer Konstanten, kann ClickHouse pro Granula prüfen, ob der Bereich überlappt, und Granulas ohne Treffer überspringen. Das ist viel schwächer als Partition Pruning, aber es funktioniert. Queries waren nicht katastrophal langsam – nur messbar langsamer als sie sein sollten. Diese Art Bug versteckt sich: Sie ist langsam, aber nicht alarmierend. Jede Query ist betroffen, niemand kann einen A/B-Vergleich mit einer „guten“ Version machen. Der Beweis liegt in der Ausgabe von EXPLAIN PLAN indexes=1, json=1, die niemand ausführt, es sei denn, er vermutet bereits etwas.

Der Agent führte genau dieses EXPLAIN aus. Er bemerkte Partition: Condition='true' (kein Pruning) und probierte zwei Ansätze: Erstens indexHint() mit nackten Zeitstempel-Grenzen, zweitens die Umschreibung des Vergleichs, sodass auf der Feldseite der nackte timestamp steht und die Konstante die Zeitzone trägt. Der zweite Ansatz gewann deutlich. Die Semantik ist identisch – toTimeZone() ändert nur die Anzeige-Metadaten, der Unix-Timestamp bleibt gleich. Der Planer sieht jetzt einen nackten timestamp und kann arbeiten. Auf der Benchmark-Query über sieben Tage: beste Laufzeit von 2.824 ms auf 2.192 ms (–22%), getrimmter Mittelwert der mittleren drei Läufe von 4.694 ms auf 2.954 ms (–37%), Anzahl der vom Skip-Index gescannten Granulas von 60.683 auf 23.291 (–62%).

Der Geschwindigkeitszuwachs ist am größten bei kurzen Zeiträumen, weil Partition Pruning dort am meisten bringt. Bei einem 90-Tage-Zeitraum ist die relative Verbesserung kleiner, aber messbar. Die Granula-Reduktion ist bei jedem Zeitraum real – sie übersetzt sich nur in kleinere Wanduhr-Verbesserungen, wenn absolut mehr Granulas gescannt werden müssen.

Das Team handelte während des Hackathons noch händisch. Sie bauen jetzt eine Pipeline, die das automatisiert: Sie holt langsame Queries aus system.query_log, startet pro Kandidaten-Query eine Sandbox, lässt pi-autoresearch laufen, dedupliziert die Vorschläge per LLM und lässt einen anderen Agenten (PostHog Code) die eigentliche Änderung mit Tests und Benchmarks in die Codebasis schreiben. Die Pull-Requests landen im Team-Slack, wo ein Mensch sie prüft und merged.

Das zeigt: Selbst in einer gut gewarteten Codebase überleben subtile Performance-Probleme über Jahre, einfach weil kein Mensch den Anreiz oder die Zeit hat, sie systematisch zu suchen. Ein KI-Agent hat diese Nachteile nicht. Er hat keine Betriebsblindheit. Er behandelt einen dreijährigen Ausdruck mit derselben Skepsis wie die Zeile von gestern. Die Methode ist nicht auf langsame Queries beschränkt. Wenn du eine Metrik in deinem System hast, die du stillschweigend tolerierst – Geschwindigkeit, Speicher, Kosten, Genauigkeit, Fehlerrate – baue eine Testumgebung, setze einen Agenten darauf, und schau, was zurückkommt.

Quelle: posthog.com

 

Du betreibst einen Champagnerbrunnen im Garten. Jeder Gast darf sich einmal bedienen. Ein Dieb schließt heimlich einen Schlauch an und zapft den ganzen Tag Liter ab, um den Champagner weiterzuverkaufen. Deine Rechnung am Monatsende? Zehntausende Euro. Genau das passiert mit KI-Endpunkten, die für die Öffentlichkeit oder Kunden freigeschaltet sind. Nur kommt der Champagner hier aus den teuren Berechnungen großer Sprachmodelle. Der Dieb heißt Inference Theft – der unbefugte Diebstahl von KI-Inferenz, zur eigenen Nutzung oder zum gewinnbringenden Weiterverkauf.

Der Begriff klingt technisch, ist aber ein wirtschaftliches Problem. Eine HTTP-Anfrage kostet Bruchteile eines Cents – Vercel gibt einen Richtwert von etwa zwei Dollar pro Million Anfragen an. Ein einziger Prompt an ein modernes KI-Modell wie Claude oder GPT kann locker zwei Dollar verschlingen. Das ist eine Million Mal teurer. Genau deshalb ist Inference Theft ein profitables Geschäftsfeld für Angreifer. Sie zahlen nichts für die Rechenleistung, sondern klauen sie und verkaufen sie zu einem Spottpreis weiter.

Wie Inference Theft funktioniert

Der Angriff ist einfach und raffiniert. Du stellst einen KI-Chatbot oder eine API bereit, die einem Benutzer die Kontrolle über ein großes Sprachmodell gibt. Das kann ein öffentliches Playground sein, ein Support-Bot oder ein Dokumentationsassistent. Der Angreifer nimmt deine API und verpackt sie in einen Adapter. Das ist ein kleines Stück Software, das deine API-Schnittstelle in das Format eines großen Anbieters wie OpenAI oder Anthropic übersetzt. Sobald der Adapter läuft, kann jeder Coding-Agent oder SDK, der für die Schnittstelle von OpenAI geschrieben wurde, deine teure Inferenz nutzen – ohne dass du etwas merkst.

Der Angreifer ruft deine API nicht direkt von seiner IP auf. Er mietet tausende Residential-Proxy-IPs, also IP-Adressen von echten Privatgeräten, über die er die Anfragen streut. Deine IP-basierten Ratenbegrenzungen greifen dann nicht, weil jede Anfrage aus einer anderen Ecke der Welt kommt. Wenn du eine Authentifizierung verlangst, legt der Angreifer tausende Wegwerf-Konten an. Der Aufwand lohnt sich, weil der Gewinn pro gestohlener Anfrage enorm ist.

Selbst wenn du denkst, dein System sei sicher, weil die System-Prompts serverseitig festgelegt sind – Angreifer haben gelernt, Modelle mit geringem Aufwand um feste Anweisungen herumzumanövrieren. Das senkt die Qualität der gestohlenen Antworten kaum, und der Weiterverkauf bleibt profitabel. Besonders gefährlich sind offene KI-Playgrounds, bei denen der Aufrufer maximale Kontrolle über Prompt, Modell und Parameter hat. Aber auch Support-Bots sind nicht immun.

Warum klassische Websicherheit nicht hilft

Du denkst vielleicht: „Ich habe doch Rate Limits und einen Log-in. Reicht das nicht?“ Leider nein. Diese Mechanismen wurden für Angriffe mit niedrigeren Kosten pro Aufruf entwickelt. Damals, als Diebstahl von Rechenleistung kaum profitabel war, haben Angreifer nicht Unmengen in Residential-Proxys und Fake-Konten investiert. Heute ist der Hebel riesig: Ein Angreifer kann dir mit einem einzigen Adapter und ein paar Dollar Infrastruktur Kosten von mehreren Zehntausend Dollar pro Tag verursachen. Die Anschaffung von tausend IPs ist billig.

Das Problem liegt in der Architektur: Die meisten Sicherheitsgates prüfen die Identität eines Nutzers nur beim Einloggen oder zu Beginn einer Sitzung. Einmal eingeloggt, wird jede weitere Anfrage dieser Sitzung vertraut. Genau das nutzen Angreifer. Sie umgehen das Session-Gate einmal – durch ein gestohlenes Token oder ein Fake-Konto – und können dann tausende Anfragen durchschleusen, ohne erneut geprüft zu werden. Die Kosten für die Umgehung amortisieren sich über die vielen gestohlenen Aufrufe. Du brauchst eine Verteidigung, die jeden einzelnen API-Aufruf überprüft, nicht nur den Start der Sitzung.

Der Trick: Du musst die Überprüfung so günstig machen, dass sie für dich kaum ins Gewicht fällt, aber für den Angreifer so teuer, dass sich das Umgehen nicht lohnt. Teure Inferenz (dein Champagner) steht gegen billige Verifikation (deine Wache). Wenn die Wache jeden Schluck prüft, wird der Dieb müde.

Ein realer Angriff auf Vercel

Ein gutes Beispiel liefert Vercel selbst. Im April 2026 beobachteten die Ingenieure einen plötzlichen Traffic-Anstieg auf ihrem KI-Dokumentations-Chatbot. Die Anfragen auf das Modell Claude Haiku 4.5 stiegen auf etwa das Zehnfache des Normalvolumens – bis zu 1.300 Anfragen pro Minute. Das hätte, wäre der Angriff nicht gestoppt worden, zu Inferenzkosten von über zehntausend Dollar pro Tag geführt. Die Angreifer nutzten Residential-Proxys, sodass IP-basierte Rate Limits nichts ausrichten konnten. Über zwei Tage hinweg schickten sie Hunderttausende von Bot-Anfragen.

Vercel setzte daraufhin eine tiefgehende Analyse namens BotID ein, die innerhalb des Routen-Handlers vor jeder KI-Anfrage läuft. Innerhalb von Minuten wurden mehr als zehntausend Bot-Anfragen erkannt und blockiert. Nach 24 Stunden war der Traffic wieder normal. Der Schlüssel: Die Verifikation geschah für jeden einzelnen Request, nicht nur zu Sitzungsbeginn.

So implementierst du Request-Verifikation mit BotID

Was genau ist BotID? Es ist eine unsichtbare CAPTCHA-Technologie, die auf clientseitigem maschinellem Lernen basiert. Der Benutzer muss kein Bildrätsel lösen – das Verfahren läuft im Hintergrund und unterscheidet Menschen von Bots, ohne die User Experience zu beeinträchtigen. Dadurch kann es auf jedem Request ausgeführt werden, ohne zu nerven.

Die Implementierung erledigst du mit wenigen Zeilen Code. Zuerst deklarierst du auf der Client-Seite, welcher Endpunkt geschützt werden soll:

// instrumentation.client.ts
import { initBotId } from 'botid/client/core';
initBotId({
  protect: [{ path: '/api/ai-chat', method: 'POST' }],
});

Auf der Server-Seite rufst du dann in deinem Routen-Handler checkBotId() auf. Ist das Ergebnis ein Bot, lehnst du die Anfrage mit einem 403-Status ab:

// app/api/ai-chat/route.ts
import { checkBotId } from 'botid/server';
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const verification = await checkBotId();
  if (verification.isBot) {
    return NextResponse.json({ error: 'Zugriff verweigert' }, { status: 403 });
  }
  // Dein bestehender KI-Aufruf
}

Wichtig: Der Client muss die Pfade korrekt deklarieren, sonst fehlen die Challenge-Header, und checkBotId() schlägt fehl. Die vollständige Einrichtung mit dem next.config.ts-Wrapper findest du in der BotID-Dokumentation.

Warum jeder Request einzeln geschützt werden muss

Der entscheidende Punkt ist die Kostenasymmetrie. Ein Angreifer hat einmalige Kosten für den Bau des Adapters und die Beschaffung der Proxys. Danach ist jeder gestohlene API-Aufruf für ihn praktisch kostenlos. Wenn du nur das Session-Gate prüfst, bezahlt er die Umgehung einmal und erntet tausende Aufrufe. Wenn du aber bei jedem Aufruf eine günstige Prüfung durchführst, muss er für jeden Diebstahl erneut eine Hürde nehmen. Die günstige Prüfung (z. B. BotID) kostet dich weniger als ein Zehntausendstel eines Cents – verglichen mit den zwei Dollar für die Inferenz ein Schnäppchen. Selbst wenn der Bypass für einen Angreifer fünf Cent kostet, lohnt sich das nicht mehr, wenn er pro Aufruf nur zwei Dollar spart, aber fünf Cent zahlen muss – bei tausend Aufrufen wären das fünfzig Euro, die er vorstrecken müsste. Und wenn die Erfolgsquote nicht 100 % ist, erst recht nicht.

Was das für deine KI-Endpunkte bedeutet

Inference wird auf absehbare Zeit um Größenordnungen teurer sein als die Anfragen, die sie transportieren. Das Geschäftsmodell der Angreifer bleibt profitabel, solange es ungeschützte oder schlecht geschützte Endpunkte gibt. Du solltest sofort prüfen, welche deiner KI-APIs im Internet erreichbar sind. Priorisiere nach Angriffswahrscheinlichkeit: Je mehr Kontrolle der Aufrufer über den Prompt hat, desto leichter ist das Ziel. Ein öffentlicher Playground ist akut gefährdet; ein Support-Bot mit festem System-Prompt ist weniger exponiert, aber nicht immun.

Der zweite Schritt: Implementiere eine Verifikation, die auf jedem Request läuft. Rate Limits allein reichen nicht, Authentifizierung allein auch nicht. Eine Kombination aus unsichtbarem CAPTCHA (wie BotID) und serverseitiger Prüfung stellt sicher, dass nur echte Menschen deine teuren Ressourcen verbrauchen. Der Aufwand ist gering, der Schutz massiv.

Und zu guter Letzt: Vergiss nicht, dass auch Systeme, die hinter einem Login stehen, verwundbar sind – wenn der Login einmal umgangen wurde, fließt der Champagner ungehindert. Mach das Tor nicht nur am Eingang zu, sondern prüfe jeden Schluck.

 

Quelle: vercel.com

Ein Grafikdesigner hat eine Idee für ein Logo. Er gibt sie in ein KI-Tool. Das Ergebnis: ein schönes Pixelbild – aber eine Kurve sitzt nicht richtig. Was tun? Maskieren, neu generieren, nachzeichnen. Mühsam. Alternativ bekommt er eine SVG-Datei. Er öffnet sie, ändert den Pfad, korrigiert den Verlauf, passt die Strichstärke an. Fertig. Der Unterschied: das eine ist ein fertiges Bild, das andere der Bauplan. Ein Artikel über die Zukunft visueller KI beschreibt diesen Wandel. Die These: Visuelle KI sollte nicht Pixel ausspucken, sondern den Code, der diese Pixel erzeugt. Das betrifft alle, die mit Design, Animation oder 3D-Modellierung arbeiten.

Zwei Welten der Bildgenerierung

Bisher dominierte ein Ansatz: Die KI erzeugt direkt ein Bild oder Video, oft über Diffusionsmodelle. Die Ergebnisse sind atemberaubend realistisch. Aber was du bekommst, ist eine Momentaufnahme. Willst du etwas ändern, musst du neu generieren oder mühsam nachbearbeiten. Der zweite Ansatz heißt „code-native“. Die KI schreibt kein fertiges Bild, sondern ein Programm, das das Bild rendert. Das kann ein SVG-Code sein, ein HTML/CSS-Layout, ein React-Component, eine Lottie-Animation oder ein Blender-Skript. Die Quelle ist ein editierbares, strukturiertes Artefakt. Statt des fertigen Gerichts bekommst du alle Zutaten und Schritte – und kannst jederzeit eingreifen. Für Produktionsabläufe ist das ein großer Vorteil. Ein generiertes Programm kann man versionieren, wiederverwenden, in andere Software einbetten und validieren. Es ist nicht nur Output, sondern ein aktives Werkzeug.

Warum Code die bessere Grundlage ist

Der wichtigste Vorteil zeigt sich, wenn der erste Entwurf nicht perfekt ist. Sagt ein Nutzer: „Das Logo gefällt mir, aber der Bogen ist zu flach.“ Bei einem gerasterten Bild beginnt die Arbeit von vorn. Bei einer SVG-Datei ändert man einfach den Pfad. Der Artikel nennt Quiver, ein Tool für Logodesign auf SVG-Basis. Ähnlich bei UI-Design: Ein Screenshot ist nur Inspiration. Liefert die KI HTML/CSS oder React-Code, kann der Designer den DOM inspizieren, Komponenten austauschen, responsive Zustände testen und Barrierefreiheit prüfen. Das ist der Kern professioneller Arbeit. Der Ansatz funktioniert besonders gut mit „Test-Time Compute“. Bei pixelbasierten Modellen bedeutet mehr Rechenzeit mehr Zufallsversuche – man generiert 20 Bilder und hofft. Die Rückkopplung ist grob. Bei codebasierter Generation läuft es anders: Code – Render – Inspect – Überarbeiten. Das Modell schreibt den Code, rendert ihn, sieht Fehler und patcht den Quellcode. Ist der Abstand falsch, ändert es das CSS. Ist die Kurve daneben, korrigiert es den SVG-Pfad. Jede Iteration verbessert das Artefakt selbst. Das ist, als würde ein Programmierer einen Bug fixen – nicht einfach neu kompilieren und hoffen.

Der Stack: Modell, Symbol und Renderer

Hinter diesen Beispielen steckt ein klarer Aufbau: Ein Codierungsmodell schreibt das Artefakt (HTML, SVG, Lottie-JSON, Blender-Script). Dieses Artefakt liegt als Quellcode vor – die Struktur ist festgehalten. Ein Renderer setzt diese Struktur in Pixel um: der Browser rendert HTML, ein SVG-Player zeigt Vektoren, Blender berechnet 3D-Szenen. OmniLottie ist ein gutes Beispiel. Lottie ist ein JSON-basiertes Animationsformat, das Bewegung als editierbare Vektoren, Ebenen und Keyframes speichert – nicht als flaches Video. OmniLottie wandelt dieses JSON in eine Befehlssequenz um, die Modelle leichter verarbeiten können. So kann ein KI-Modell Lottie-Animationen zuverlässiger generieren und bearbeiten. Weil die Animation als strukturierte Daten vorliegt, kann Feedback direkt auf die Quelle wirken. Läuft eine Bewegung zu langsam? Ändere den Timing-Wert. Passt der Pfad nicht? Editiere die Vektorform. Das ist kein Neusampeln, sondern gezieltes Debuggen eines visuellen Programms. Der Autor sieht eine direkte Verbindung zu Fortschritten bei KI-Agenten, die in Sandboxen Code testen – nur dass die Umgebung hier ein Renderer ist.

Wo der Markt sich formiert: Runtimes als Nischen

Der Artikel zeichnet eine Marktlandkarte. Die Anbieter gruppieren sich um die Laufzeitumgebung – den Ort, an dem das Artefakt ausgeführt wird. Browser, SVG-Renderer, Lottie-Player, Blender, Spiele-Engines, Simulatoren – jede Laufzeit schafft eine eigene Nische mit eigener Quellrepräsentation, eigenem Feedback-Loop und eigenen Produktionsworkflows. Die offensichtlichsten Anwendungen liegen heute im 2D-Design, vor allem bei UI und Grafik. Der Autor betont: Visuelle Codegenerierung ist viel breiter. Sie zeigt sich überall dort, wo ein visuelles Artefakt eine zugrundeliegende Repräsentation hat, die generiert, gerendert, inspiziert und verbessert werden kann. Die ersten erfolgreichen Produkte sind oft Start-ups, die sich auf eine dieser Runtimes konzentrieren – diejenigen, die den Kreislauf von Code zu Rendering zu Feedback zur Überarbeitung vollständig abbilden. Der Wettbewerb wird nicht mehr nur über die Schönheit der Ausgabe entschieden, sondern über die Qualität der Iterationsschleife.

3D als die wichtigste nächste Grenze

Besonders spannend wird es im Bereich 3D. Ein schönes Pixelbild allein ist wertlos. Ein gerendertes Bild eines Stuhls ist kein Stuhl – es ist ein Bild. Damit ein 3D-Asset in einem Spiel, einer Simulation oder einem CAD-Programm taugt, braucht es korrekte Geometrie, Materialien, Teilehierarchie und Szenenkontext. Fehler sind nicht nur optisch, sondern funktional. Der Artikel beschreibt zwei Projekte: VIGA und Articraft3D. VIGA nutzt Blender als Rendering- und Feedback-Umgebung und gibt dem KI-Agenten semantische Werkzeuge, um die Szene aus verschiedenen Kameraperspektiven zu betrachten, den Zustand abzufragen, Objekte zu isolieren und Abweichungen in Quellcode-Änderungen zu übersetzen. Articraft3D geht noch direkter vor: Es formuliert die Generierung eines 3D-Assets mit Gelenken als das Schreiben eines Programms, das Teile, Geometrien, Gelenke und Tests definiert. Das Ziel ist nicht nur ein plausibles Objekt, sondern eines, das sich auch so verhält: Türen öffnen sich, Schubladen gleiten, Räder drehen. Der Autor erwartet, dass 2026 und 2027 viele weitere kommerzielle und Open-Source-Projekte entstehen. Denn hier zeigt sich der Vorteil der Code-Nativität am stärksten: Die Iterationsschleife erlaubt es, nicht nur die Optik, sondern auch die Funktionalität systematisch zu verbessern.

Was das für die Zukunft bedeutet

Setzt sich dieser Trend durch, werden die Gewinner nicht einfach schönere Bilder liefern. Sie werden die gesamte Schleife besitzen: Artefakt generieren, rendern, inspizieren, überarbeiten. Daraus ergeben sich mehrere Implikationen. Erstens werden Renderer zu Feedback-Umgebungen. Browser, SVG-Renderer, Lottie-Player, Blender, Spiele-Engines und Simulatoren verwandeln sich in Testumgebungen, in denen KI-Agenten ihre Arbeit verbessern – analog zu den Sandboxen und VMs, die heute beim Codieren genutzt werden. Zweitens wird die Qualität des Iterationskontexts entscheidend. Um einen Agenten in eine ständige, schnelle Wiederholung von Test und Korrektur zu bringen, braucht es klare Metriken, zuverlässige Renderings und eine gute Fehlerdiagnose. Drittens verändert sich das Verhältnis zwischen Mensch und KI. Statt eines einmaligen Prompts wird die Arbeit zu einem Dialog: Der Mensch gibt Feedback auf das generierte Programm, die KI bessert nach, der Mensch prüft wieder. Das ist keine magische Ausgabe, sondern eine partnerschaftliche Optimierung. Wer versteht, dass visuelle KI zunehmend Code schreibt statt Bilder malt, wird die Werkzeuge von morgen besser nutzen können. Der Bauplan ist wertvoller als das fertige Haus – er lässt sich jederzeit umbauen.

Quelle: a16z.com

In der KI-Welt gibt es einen grundlegenden Konflikt zwischen offenen und geschlossenen Modellen. Ein aktueller Text beschreibt einen ökonomischen Graben zwischen beiden – und argumentiert, dass sie auf eigenen Exponenzialkurven unterwegs sind. Die Frage ist nicht, welches System gewinnt, sondern wie die Arbeitsteilung aussehen wird.

Nutzer von KI-Werkzeugen zahlen zunehmend einen Aufpreis für die besten Modelle. Besonders deutlich wird das bei Coding Agents – KI-Assistenten, die komplexe Aufgaben in der Softwareentwicklung übernehmen. Diese Agenten haben mit Modellen wie Opus 4.5 und Codex 5.2 eine Schwelle erreicht, ab der die Produktivitätssteigerung offensichtlich ist. Fachleute greifen nicht mehr auf Alternativen zurück. Der Autor selbst würde 2000 Dollar monatlich für diese Werkzeuge zahlen – allein aufgrund des heutigen Nutzens.

Die geschlossenen Labore – vor allem Anthropic mit Claude und OpenAI mit GPT – setzen auf diesen Hebel. Sie investieren in Talent, Daten und Rechenleistung, um ihre Modelle an die Spitze zu treiben. Offene Modelle müssen flexibel bleiben, geschlossene Systeme können Hardware und Software besser aufeinander abstimmen. Das erinnert an Apples Strategie: ein integriertes System, schwer zu kopieren. Gleichzeitig haben diese Labore ein Microsoft-ähnliches Geschäftsmodell mit Abonnements. Der Autor prognostiziert, dass OpenAI und Anthropic in fünf bis zehn Jahren Bewertungen zwischen zwei und zehn Billionen Dollar erreichen – ein Oligopol wie der Cloud-Markt.

Der Fokus auf Spitzenleistung hat auch eine Kehrseite. Die Labore werden ihre besten Modelle zurückhalten – um Token nicht zu verschwenden, Destillation zu erschweren oder margenstarke Anwendungsfälle zu bedienen. Der API-Markt wird sich verändern. In den nächsten Jahren übersteigt der Bedarf an Rechenleistung das Angebot, Token werden stark subventioniert. Investoren pumpen Geld in KI-Start-ups, die Nachfrage bleibt künstlich hoch, selbst wenn viele Agenten noch keinen Mehrwert liefern. Der Autor hält diesen Bubble-Effekt für einen Treiber des Ausbaus.

Die Ökonomie der offenen Modelle ist anders. Offene Modelle sind nicht integriert – sie müssen auf unterschiedlicher Hardware und in verschiedenen Umgebungen laufen, was die Optimierung erschwert. Ein Ökosystem aus Unternehmen trägt sie, die zusammenarbeiten und konkurrieren. Der Markt ist divers, die Margen sind niedrig, die Preise folgen einer Commodity-Logik. Viele Unternehmen streben den Wechsel zu offenen Modellen an, aber aktuell sind diese nicht leistungsfähig genug für Aufgaben außerhalb der Standard-Trainingsdaten. Entwickler offener Modelle könnten aufhören, direkt mit Claude oder GPT auf Benchmarks zu konkurrieren, und stattdessen Nischen besetzen, in denen niedrige Kosten oder individuelle Anpassungen entscheidend sind.

Dieser Fork könnte durch Ökonomie erzwungen werden: Steigen die Kosten für Forschung und Entwicklung zur Skalierung, können offene Projekte vielleicht nicht mithalten. Oder er entsteht aus der Nachfrage: Bestimmte KI-Lösungen funktionieren nur bei Preisen, die offene Modelle ermöglichen. Die Wertschöpfung um offene Modelle wird letztlich größer sein als die der geschlossenen Labore – aber sie verteilt sich auf viele Schultern. Unternehmen finden Modelle, die für spezifische Aufgaben ausreichen, und wechseln dann nicht mehr, weil die Einrichtungskosten zu hoch sind. Das eröffnet einen großen Markt für angepasste Modelle und Fine-Tuning-Dienste, wie sie Firmen wie Tinker, Fireworks oder Prime Intellect anbieten.

Die zeitliche Dynamik unterscheidet sich. Geschlossene Labore erleben eine schnelle Verbreitung durch Coding Agents, das offene Ökosystem braucht länger, um in die Breite der Wirtschaft zu diffundieren. Der Autor vergleicht die Situation mit dem iPhone: Als Konsument kannst du dir ein Android kaufen und kleine Nachteile in Kauf nehmen, um Geld zu sparen. Aber wenn das Premium-Produkt deine tägliche Arbeit effizienter macht, warum darauf verzichten? Im Arbeitsumfeld sind die Produktivitätsgewinne noch höher, was die Preissetzungsmacht der geschlossenen Modelle untermauert. Die offene Seite wird sich über Jahre langsam in Unternehmen verbreiten – nicht durch einen einzelnen Durchbruch, sondern durch kontinuierliche Verbesserung von Tools, Anpassung an spezifische Anforderungen und sinkende Einstiegshürden.

Der Autor warnt davor, die Behauptungen über rekursive Selbstverbesserung (RSI) zu überschätzen. Der Fortschritt im KI-Ökosystem bleibe schnell – aber er sei nicht auf einen Pfad festgelegt. Neue Produktformen wie Hintergrund-Agenten könnten sowohl offene als auch geschlossene Modelle bedienen. Es sind zwei unterschiedliche Entwicklungskurven: Geschlossene Modelle starten ihren integrierten Aufstieg, indem sie den High-End-Bereich der Wissensarbeit monetarisieren. Die offene Wirtschaft braucht länger, aber sie wird das KI-Zeitalter in jeden Winkel der Gesellschaft tragen. Dieser langsame, breite Fortschritt zeigt die Diffusion von Intelligenz in den Alltag.

In den nächsten Jahren wirst du zwei KI-Realitäten erleben. Auf der einen Seite hochintegrierte Systeme, die deine Arbeit erleichtern, wenn du bereit bist zu zahlen. Auf der anderen Seite wachsende offene Werkzeuge, die vielleicht nicht an der Spitze stehen, aber durch Anpassbarkeit und niedrige Kosten ganze Industrien durchdringen. Beide Entwicklungen ergänzen sich. Die Frage ist, ob du in fünf Jahren das Premium-Abo bezahlst oder mit einem offenen Modell deine Nische bedienst – vielleicht beides. Es geht nicht um Dogmen, sondern um das Werkzeug, das deine Arbeit besser macht.

Quelle: interconnects.ai