Suchergebnisse für: „Agenten“

Du öffnest einen Pull Request mit 30 geänderten Dateien. Du scrollst durch die Diff-Ansicht, suchst nach Fehlern, aber nach fünf Dateien lässt die Konzentration nach. Ein Kollege reviewed später und übersieht genau den Nullzeiger, der dich nachts um drei wachhält. Dieses Szenario hatte Alibaba vor Augen, als sie ihr internes KI-Code-Review-Tool entwickelten – und jetzt als Open Source veröffentlichen.

Das Tool heißt Open Code Review (OCR). Es ist kein generischer KI-Agent, den du mit einem Prompt anlernst, sondern ein Hybrid aus deterministischen Pipelines und einem Large-Language-Model-Agenten. Die Maschine übernimmt stupide, aber kritische Prüfungen, während das KI-Modell dort glänzt, wo Kontextverständnis gefragt ist. Schauen wir uns an, was dahintersteckt.

Das Problem mit generischen KI-Agenten

Vielleicht hast du schon Claude Code oder einen anderen universellen Agenten für Code-Reviews eingesetzt. Die Ergebnisse sind oft ernüchternd. Bei großen Änderungssätzen neigen diese Agenten dazu, „Ecken abzuschneiden“ – sie reviewen nur einen Teil der Dateien und lassen andere aus. Die berichteten Probleme sitzen oft nicht auf der richtigen Codezeile; die Positionsangaben driften ab. Und die Qualität schwankt massiv, sobald du den Prompt geringfügig änderst.

Warum passiert das? Die Ursache liegt in einer rein sprachgetriebenen Architektur. Ein LLM hat keine harten Zwänge, keine Garantie, dass es wirklich alle Dateien anschaut oder die Zeilennummern stimmen. Es folgt Wahrscheinlichkeiten, nicht Regeln. Für eine Aufgabe wie Code-Review, bei der es auf Vollständigkeit und Genauigkeit ankommt, ist das ein Problem.

Der Hybrid-Ansatz von Open Code Review

Die Entwickler von Alibaba haben sich für eine klare Trennung entschieden: Deterministische Ingenieurslogik übernimmt alles, was nicht schiefgehen darf. Der KI-Agent kümmert sich um dynamische Entscheidungen, die Kontext erfordern. Stell dir vor, du hast einen Assistenten, der automatisch die richtigen Aktenordner aus dem Regal zieht (deterministisch) – und dann einen zweiten, der die Akten liest und dir die relevanten Stellen zusammenfasst (KI). Beide arbeiten Hand in Hand, aber jeder macht das, was er am besten kann.

Deterministische Säule: Harte Zwänge für kritische Schritte

Die erste Säule ist ein System aus fest programmierten Regeln und Pipelines. Sie garantieren:

• Präzise Dateiauswahl: Das Tool bestimmt exakt, welche Dateien reviewed werden müssen und welche ignoriert werden können. Keine wichtige Änderung wird übersehen.
• Intelligentes Bündeln: Zusammenhängende Dateien – etwa message_en.properties und message_zh.properties – werden zu einem Review-Bundle zusammengefasst. Jedes Bundle läuft als eigener Sub-Agent mit isoliertem Kontext. Das ist eine Divide-and-Conquer-Strategie: Selbst bei sehr großen Changesets bleibt das Tool stabil, und die Reviews laufen nebenläufig.
• Fein abgestimmtes Regel-Matching: Statt das LLM mit allgemeinen Prompts zu füttern, werden spezifische Review-Regeln an die Eigenschaften jeder Datei geknüpft. Das hält den Fokus des Modells scharf und eliminiert Informationsrauschen. Im Vergleich zu rein sprachgesteuerten Regelwerken ist eine Template-Engine stabiler und vorhersagbarer.
• Externe Positionierungs- und Reflexionsmodule: Zwei unabhängige Module korrigieren systematisch die Positionsgenauigkeit und die inhaltliche Korrektheit der KI-Kommentare. So landen die Hinweise exakt auf der richtigen Codezeile und sind inhaltlich treffsicher.

KI-Agent: Dynamische Intelligenz für Kontext und Entscheidungen

Auf der anderen Seite steht der LLM-Agent. Er wird nicht mit einem vagen „Reviewe diesen Code“-Prompt losgeschickt, sondern nutzt speziell für Code-Review optimierte Prompt-Vorlagen. Diese Vorlagen senken den Token-Verbrauch und steigern die Effektivität. Der Agent hat ein maßgeschneidertes Toolset – basierend auf einer Analyse von Millionen von Tool-Call-Traces aus der Produktion. Die Entwickler haben sich angeschaut, welche Werkzeuge wie oft verwendet werden, wie hoch die Wiederholungsraten sind und wie sich neue Tools auf die gesamte Aufrufkette auswirken. Das Ergebnis ist eine stabile, vorhersagbare Tool-Ausstattung, die genau auf Code-Reviews zugeschnitten ist – nicht die generische Toolbox eines Allround-Assistenten.

Mit diesem Setup kann der Agent nicht nur den Diff anschauen, sondern auch den vollständigen Dateiinhalt lesen, im Codebase suchen und andere geänderte Dateien zur Kontextgewinnung heranziehen. Er liefert tiefgehende Reviews, nicht nur oberflächliches Feedback zum Diff.

Wie du Open Code Review nutzt

Du kannst das Tool als CLI installieren – über npm, als Binär von GitHub Releases oder aus dem Quellcode. Der Befehl ocr review startet den Review auf deinem Workspace, einem Branch-Vergleich oder einem einzelnen Commit. Du bestimmst die Ausgabe im Text- oder JSON-Format, die Anzahl der parallelen Reviews und den Timeout.

Ein Beispiel: Um alle Änderungen zwischen main und einem Feature-Branch zu reviewen, reicht ocr review --from main --to feature-branch. Möchtest du vorab sehen, welche Dateien reviewed werden, nutzt du ocr review --preview. Das ist hilfreich, um ein Gefühl für die Abdeckung zu bekommen.

Die Konfiguration des LLM-Anbieters erfolgt über die Kommandozeile – du gibst Endpunkt, API-Key und Modell an. OpenAI-kompatible und Anthropic-Modelle werden unterstützt. Das Tool liest auch die Umgebungsvariablen von Claude Code, sodass du sie nicht doppelt pflegen musst.

Integration in CI/CD und Coding Agents

Open Code Review ist nicht nur für die lokale Nutzung gedacht. Es lässt sich in CI/CD-Pipelines einbauen, um Pull Requests automatisch zu reviewen. Mit dem Flag --format json erhältst du maschinenlesbare Ergebnisse, die dein CI-Skript weiterverarbeiten kann. Alibaba liefert Beispiele für GitHub Actions und GitLab CI mit.

Du kannst das Tool direkt in KI-Coding-Agents wie Claude Code als Slash-Command integrieren. Es gibt fertige Plugins und Skills, die dem Agenten beibringen, ocr aufzurufen, die Ergebnisse zu kategorisieren und sogar automatisch Fixes vorzuschlagen. Das Bindeglied ist immer die installierte CLI – der Agent selbst wird nicht mit der Review-Logik belastet, sondern delegiert an die deterministische Pipeline.

Was das für die Praxis bedeutet

Mit Open Code Review bekommst du ein Werkzeug, das die Stärken von deterministischen Systemen und KI vereint. Du musst keine langen Prompts optimieren oder hoffen, dass der Agent alle Dateien erwischt. Die harten Zwänge garantieren Vollständigkeit und Positionsgenauigkeit – zwei Schwachstellen reiner KI-Lösungen. Gleichzeitig profitiert der KI-Agent von einem spezialisierten Toolset und optimierten Prompts, die aus Jahren Erfahrung bei Alibaba destilliert wurden.

Für Entwicklerteams, die regelmäßig große Code-Reviews durchführen, bedeutet das eine Entlastung. Die KI erledigt Standardprüfungen (Nullzeiger, Thread-Safety, XSS, SQL-Injection) zuverlässig und liefert tiefgehendes Feedback, das sonst nur ein erfahrener Senior-Entwickler geben kann. Weil das Tool Open Source ist, kannst du es an deine eigenen Bedürfnisse anpassen, eigene Regeln definieren oder die Tool-Ausstattung erweitern.

Die Veröffentlichung zeigt einen Trend: KI-Tools für Entwickler werden erwachsener. Statt jedes Problem mit einem allmächtigen LLM zu erschlagen, setzt sich der hybride Ansatz durch – wie in der Luftfahrt, wo Autopilot und Pilot zusammenarbeiten. Open Code Review ist ein Beispiel, wie man KI sinnvoll in bestehende Arbeitsabläufe integriert, ohne die Kontrolle aus der Hand zu geben. Es lohnt sich, einen Blick darauf zu werfen – besonders, wenn du eine verlässliche, automatisierte Code-Review-Lösung suchst.

Quelle: github.com

Ein Architekt, der jahrelang Grundrisse von Hand zeichnete, bekommt plötzlich einen Assistenten, der in Minuten Baupläne entwirft. Softwareentwickler erleben Ähnliches mit Coding Agents. Ein erfahrener Open‑Source‑Entwickler hat seine Erfahrungen geteilt: Er schreibt kaum noch Code von Hand. Viele erleben diesen Wandel.

Seine Arbeitsweise hat sich fundamental verändert. Projekte wie Vite+ (Features in Rust, obwohl er die Sprache kaum beherrscht), fate 1.0 (Live Views, Drizzle‑ und GraphQL‑Support) und Codiff (eine schnelle Diff‑Review‑App) entstanden zu 90 % oder 100 % durch KI‑Codegenerierung. Für Athena Crisis, ein älteres, von Hand geschriebenes Spiel, ließ er die KI 70 Fehler beheben, Features implementieren und Tests schreiben – während er an anderen Projekten arbeitete. „Ich bin einfach nur erstaunt“, sagt er. Nie zuvor gab es eine solche Verbesserung der Entwicklererfahrung.

Wie der Workflow mit KI‑Agenten heute aussieht

Er nutzt die Codex CLI mit einem starken Modell (GPT‑Level). Er bevorzugt die Befehlszeile, weil sie mit einem leeren Blatt beginnt – keine alten Chats, keine Ablenkung. Sein Arbeitsplatz: ein Terminalfenster pro Projekt, links Codex, rechts die Konsole. So arbeitet er an drei bis sechs Projekten gleichzeitig. Der Flaschenhals ist nicht mehr das Schreiben von Code, sondern das Diskutieren und Reviewen der Ergebnisse. Er ordnet die Projekte räumlich auf einem großen Bildschirm: fate oben Mitte, void links, Athena Crisis rechts. Diese räumliche Zuordnung hilft beim Multitasking.

Seine Prompts sind knapp: „Ich will X bauen. Hol Kontext aus Y und Z, mach einen Vorschlag und frag mich, was noch unklar ist.“ Bevor der Agent startet, iteriert er mit ihm über den Plan. Bei Fehlerbehebungen schreibt der Agent zuerst einen Test, der den Fehler reproduziert. Das erhöht die Wahrscheinlichkeit, dass er das richtige Problem löst. Trotzdem: Die Modelle gehen oft in die falsche Richtung. Manchmal ist es besser, eine Sitzung abzubrechen und neu zu starten. Für größere Änderungen nutzt er /review-Zyklen. Sein Review‑Tool ist Codiff, das einen geführten Walkthrough der Änderungen liefert.

Die neuen Engineering Values

Der Autor leitet Werte ab, die für die Softwareentwicklung ab 2026 entscheidend sind. Die Art, Code zu produzieren, hat sich gewandelt, aber grundlegende Prinzipien bleiben – ihre Gewichtung verschiebt sich.

Starke Verantwortung

Gute Ingenieure zeichnen sich durch Domänenwissen und Eigentümerschaft aus. KI‑Agenten verstärken das: Wer sein Produkt kennt, liefert schneller. Wer keine Ahnung hat, erzeugt Lärm. Koordination wird teurer. Deshalb setzt er auf kleine Teams von zwei bis drei Personen mit klaren Zuständigkeiten und isolierten Repositories. Das tut weh, denn er war lange ein Verfechter von Monorepos. Starke Verantwortung bedeutet, Architektur, Anforderungen und langfristige Richtung zu verstehen, die Arbeit der Agenten zu reviewen und Entscheidungen zu treffen – manchmal direkt auf main zu pushen. Code‑Reviews in kleinen Teams dienen der Abstimmung, nicht dem Streit über Zeichensetzung.

Geschmack, Geschmack, Geschmack

Er hat eine geringe Toleranz für Bullshit – und mit Agenten könne jeder den ganzen Tag Bullshit produzieren. Sein Appell: „Hör einfach auf.“ Guter Geschmack bedeutet nicht nur, großartige Produkte zu bauen, sondern auch zu entscheiden, ob es sich lohnt, Zeit in etwas zu investieren. Sein Rat an Teams: Verbringt mehr Zeit damit herauszufinden, was die Zeit wirklich wert ist.

Strenge Leitplanken und schnelle Feedbackschleifen

Große Organisationen legen Code enge Beschränkungen auf, um Geschwindigkeit zu halten. Mit Coding Agents verhält es sich ähnlich: Jede Sitzung gleicht einem neuen Mitarbeiter ohne Kontext. Je mehr Regeln (Lint‑Regeln, automatisierte Tests, schnelle Verifikation), desto schneller iterieren Menschen und Agenten. Schnelle, skalierbare Werkzeuge sind wichtiger denn je. Enge Feedbackschleifen machen den Unterschied zwischen einer Minute und einer Stunde Bearbeitungszeit. Tools sollten nur geänderte Dateien prüfen und nicht mit der Codebasis wachsen.

Kontext im Repository

Kontext war bisher über viele Orte verteilt: Notion, Meetings, implizites Wissen, Commit‑Kommentare. Jede Agentensitzung ist wie ein neuer Mitarbeiter, der nicht an all diese Quellen herankommt. Die Lösung: den gesamten relevanten Kontext direkt im Repository ablegen – lokal, zugänglich für Agenten und Menschen. Das ist der Ort, um Geschmack, Werte und Denkweise zu injizieren. Agenten sollten keinen Schrott in die Codebasis spülen. Code wird noch stärker fürs Lesen optimiert: Weniger und einfacherer Code ist leichter zu verstehen und zu reparieren.

Den eigenen Stack besitzen

Früher bestand eine App zu 95 % aus Drittanbieter‑Abhängigkeiten. Externe Bibliotheken waren sinnvoll, weil eigenes Schreiben teuer war. Aber das machte abhängig von einem Stack ohne Kontrolle. Jede Abhängigkeit bringt Architektur, Einschränkungen und Entscheidungen mit. Agenten verschieben die Kosten: Sie machen es günstiger, eigene Lösungen zu bauen. Der Entwickler hat einen eigenen Open‑Source‑JavaScript‑Stack aufgebaut – für Daten, Internationalisierung, UI, Tool‑Konfigurationen. Das erlaubt ihm, neue Projekte schnell mit engen Vorgaben für Agenten zu starten und die volle Kontrolle zu behalten.

Was das für uns bedeutet

Der Autor weiß, dass dies nicht nur individuelle Arbeitsweisen betrifft, sondern ganze Organisationen umkrempelt. „Alle technischen Organisationen werden sich drastisch ändern müssen, wenn sie erfolgreich sein wollen.“ Wer heute noch in traditionellen Code‑Reviews und langen Genehmigungsprozessen denkt, verliert den Anschluss. Code und Programmierung werden nicht verschwinden. Englische Spezifikationen in Markdown sind eine furchtbare Programmiersprache – dynamischer Code mit Agenten erscheint sinnvoller.

Die Rolle des Ingenieurs verschiebt sich vom Code‑Schreiber zum System‑Dirigenten. Alte Werte wie Sorgfalt, Verantwortung und guter Geschmack bleiben zentral, müssen aber neu interpretiert werden. Statt selbst jede Zeile zu tippen, kuratierst du die Ausgabe von KI‑Assistenten. Statt jedes Detail zu wissen, musst du sicherstellen, dass die Leitplanken stimmen. Statt aufwändiger Koordinationsschleifen setzt du auf kleine, fokussierte Teams und klare Verantwortungen. Das passiert jetzt. Die Frage ist nicht, ob du mitziehst, sondern wie schnell du deine eigenen Engineering Values anpassen kannst.

Quelle: cpojer.net

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