Gautam Korlam, Leitender Ingenieur bei Sonar – Interviewreihe

Gautam Korlam, Leitender Ingenieur bei Sonar, ist ein erfahrener Softwareingenieur und Technologieführer, dessen Karriere sich auf Entwicklerinfrastruktur, Codequalität, Automatisierung und KI‑unterstützte Softwareentwicklung konzentriert hat. Vor dem Eintritt bei Sonar gründete er gemeinsam Gitar und war CTO, wobei er eine KI‑native Plattform entwickelte, die Code‑Reviews automatisiert, Continuous‑Integration‑Fehler (CI) diagnostiziert, Ursachen ermittelt und Korrekturen erzeugt. Sonar erwarb Gitar im Mai 2026, wobei Korlam und das Gitar‑Team dem Unternehmen beigetreten sind, um die Technologie als Teil von Sonars umfassenderer Code‑Verifizierungsplattform weiterzuentwickeln. Vor Gitar verbrachte Korlam fast ein Jahrzehnt bei Uber, wo er vom Gründungsingenieur im Mobile‑Platform‑Team zum Leitenden Ingenieur aufstieg. Während seiner Tätigkeit half er beim Aufbau und der Skalierung der zentralen Entwicklerinfrastruktur von Uber, leitete große Monorepo‑ und Build‑System‑Initiativen, entwickelte Remote‑Entwicklungsumgebungen und CI/CD‑Tools und experimentierte mit Open‑Source‑Large‑Language‑Models wie StarCoder, OctoCoder und Code Llama, um KI‑unterstütztes Coden im Uber‑Code‑Base zu verbessern. Seine frühere Erfahrung umfasst Ingenieurrollen bei Lookout und Forschungsarbeit an der UC Santa Barbara sowie Praktika bei Microsoft und Oracle.

Sonar ist ein Softwareunternehmen, das sich auf Code‑Verifizierung, automatisierte Code‑Reviews, Code‑Qualität und Anwendungssicherheit konzentriert. Die Flaggschiff‑Plattform SonarQube analysiert von Entwicklern geschriebenen und KI‑generierten Code, um Bugs, Schwachstellen, Wartbarkeitsprobleme und andere Qualitätsmängel zu erkennen, bevor sie in die Produktion gelangen, wobei die Angebote Cloud‑, Self‑Managed‑ und integrierte Entwicklungsumgebungs‑Workflows umfassen. Sonar gibt an, dass seine Technologie von mehr als 7 Millionen Entwicklern und 22 000 Kunden genutzt wird und täglich über 750 Milliarden Codezeilen analysiert. Der Erwerb von Gitar erweiterte diesen Ansatz um KI‑native Code‑Reviews und ‑Remediation, indem die Verifizierungs‑Engine von SonarQube mit agentenbasierten Werkzeugen kombiniert wird, die Code prüfen, CI‑Fehler untersuchen und Korrekturen vorschlagen oder anwenden, während die Softwareentwicklung zunehmend KI‑gesteuert wird.

Ihre Karriere führte Sie vom Aufbau der mobilen und Entwickler‑Infrastruktur bei Uber über das Training von Open‑Source‑Large‑Language‑Models auf dessen Code‑Base bis hin zur Mitbegründung von Gitar und dem Einstieg bei Sonar nach dessen Übernahme. Wie haben diese Erfahrungen Ihre Überzeugung geprägt, dass das Generieren von Code nur ein Teil der Herausforderung ist und die zuverlässige Validierung das schwierigere Problem darstellt?

Bei Uber arbeitete ich an den Teilen des Systems, die entscheiden, ob etwas ausgeliefert wird: das Monorepo, das Build‑System, die CI‑Warteschlange, die Testsuite. Das Erleichtern von Änderungen verlagert den gesamten Druck auf diese Infrastruktur. Es entstehen mehr Services, die auf unvorhergesehene Weise interagieren, und mehr Ingenieure, die darauf warten, herauszufinden, ob ihre Änderung sicher zu mergen ist.

Später arbeitete ich an der Schulung von Modellen auf unserer eigenen Code‑Base, wo die Asymmetrie deutlich wurde. Ein Modell kann schnell eine plausible Implementierung erzeugen. Zu zeigen, dass die Implementierung in ein laufendes Produktionssystem passt, den von diesem Team tatsächlich genutzten Konventionen folgt und nichts in einem anderen Service bricht, dauerte deutlich länger, und der Großteil dieser Arbeit fiel auf Menschen. Gitar entstand daraus und passt zu dem, was Sonar seit über siebzehn Jahren auf der Analyse‑Seite leistet.

Sie haben argumentiert, dass KI‑Code‑Reviews die deterministische Analyse ergänzen sollten, anstatt sie zu ersetzen. Welche Arten von Problemen lassen sich am besten durch wiederholbare, regelbasierte Analysen identifizieren, und wo kann KI Fähigkeiten bieten, die traditionelle Techniken nicht können?

Regelbasierte Analyse ist das richtige Werkzeug, wenn die Eigenschaft aus dem Code selbst entscheidbar ist. Verunreinigte Eingaben, die einen Sink erreichen, ein Null‑Dereferenz‑Fehler auf einem übersehenen Pfad, ein fest codiertes Credential, eine Abhängigkeit mit einer bekannten CVE, ein Import, der eine Schicht überschreitet, die er nicht überschreiten sollte. Sie erhalten bei jedem Durchlauf dieselbe Antwort und können den Grund für das Auslösen benennen, weshalb Durchsetzung genau auf dieser Ebene stattfindet.

Was Regeln nicht abdecken, ist die Absicht. Kein Parser kann Ihnen sagen, dass eine benutzerorientierte Zeichenkette für den Übersetzer mehrdeutig ist, oder dass eine Änderung behauptet, ein Ticket zu schließen, dabei aber nur die Hälfte der geforderten Änderungen implementiert, oder dass eine neue Wiederholschleife dem Vorgehen des restlichen Services bei Rückdruck entgegenwirkt. Ein Modell, das das Diff zusammen mit dem verknüpften Issue und dem gesamten Code‑Base‑Kontext liest, wird solche Punkte ansprechen, und sie sollten als Befunde erscheinen, die eine Person prüft, anstatt als endgültige Urteile.

KI‑Systeme können Geschäftslogik, Entwickler‑Intentionen und architektonische Kompromisse beurteilen, doch ihre Schlussfolgerungen sind probabilistisch. Wie können Entwicklungsteams von diesem kontextbezogenen Denken profitieren, ohne die Ausgabe eines KI‑Reviewers als grundsätzlich korrekt zu behandeln?

KI‑Reviews verdienen ihren Platz bei Problemen, die konventionelle Prüfungen übersehen: Logikfehler, Verhalten, das nicht der angegebenen Absicht entspricht, oder eine Änderung, die isoliert betrachtet in Ordnung scheint, für das jeweilige System jedoch fehlerhaft ist. Diese Schlussfolgerungen sind probabilistisch und gehören daher als Input zu einer Entscheidung, nicht als Entscheidung selbst. Teams wahren diese Grenze, indem sie die deterministischen Kontrollen vor dem Merge beibehalten, also automatisierte Tests, CI‑Validierung, Sicherheits‑Scans, Richtlinien‑Checks und einen Menschen, der die Änderung verantwortet. KI kann Korrekturen vorschlagen oder sie innerhalb der vom Team festgelegten Leitplanken umsetzen, solange diese Änderungen dieselbe Verifizierung bestehen wie alles, was von einer Person geschrieben wurde, und nicht wegen ihrer maschinellen Herkunft bevorzugt werden.

Wir ziehen dieselbe Grenze in unserer eigenen Implementierung. Das Modell schlägt Befunde vor, und das Review‑Urteil wird im Code aus dem Zustand dieser Befunde berechnet. Die Auflösung funktioniert analog. Wenn der Code hinter einem Befund aus dem Diff verschwunden ist, ist das ein deterministischer Check gegen das geparste Diff, und das Modell darf nicht das Auflösen rückgängig machen, was das Diff bereits behoben hat.

Die generelle Vorgehensweise besteht darin, der probabilistischen Schicht Aufgaben zuzuweisen, bei denen ein Fehler wiederherstellbar ist, die Zustandsmaschine deterministisch zu halten und die Verantwortung beim Team zu belassen. Vertrauen entsteht durch Nachweise, die jemand prüfen und kontrollieren kann und die bei jedem Durchlauf gleiches Verhalten zeigen.

Sonar kombiniert kontextbezogene Pull‑Request‑Reviews mit deterministischer Analyse und Qualitäts‑Gates. Wie sieht ein effektiver mehrschichtiger Verifizierungsprozess aus, und wie sollten die verschiedenen Schichten zusammenwirken, ohne Arbeit zu duplizieren oder Entwickler mit Befunden zu überfluten?

Deterministische Analyse und Qualitäts‑Gates übernehmen die nicht verhandelbaren Aspekte und bilden die Blockierkriterien eines Merges. Kontextbezogene Reviews treffen die Urteilsentscheidungen darüber, ob eine Änderung das tut, was sie behauptet, ob sie in die Code‑Base passt und ob ein bestimmtes Risiko die Aufmerksamkeit einer Person rechtfertigt.

Eine Flut von Befunden wird etwa genauso häufig ignoriert wie das Fehlen von Befunden. Wir entfernen Duplikate über Reviewer hinweg, bevor etwas den Autor erreicht, verwerfen Kandidaten, die nicht verifiziert werden können, und konzentrieren uns auf Befunde mit hohem Signalwert. Auf der Regel‑Seite entscheidet ein Prädikat, ob eine Regel auf das aktuelle Diff zutrifft, bevor ein Modell läuft, sodass die meisten Regeln bei den meisten Änderungen keine Kosten verursachen. All dies erscheint im Pull‑Request, den der Entwickler bereits geöffnet hat.

Da Coding‑Agents immer mehr Code und Pull‑Requests erzeugen, könnte die Software‑Review und -Verifizierung zum neuen Engpass werden? Welche Teile des Review‑Prozesses sollten automatisiert werden, und welche Entscheidungen sollten erfahrenen Ingenieuren vorbehalten bleiben?

Review und Verifizierung sind bereits zum Engpass geworden. Tatsächlich hat unsere 2026 State of Code Developer Survey ergeben, dass Teams etwa ein Viertel der Arbeitswoche damit verbringen, KI‑Ausgaben zu prüfen und zu korrigieren. Vor diesem Hintergrund ist es nicht überraschend, dass nur 48 % der Entwickler KI‑generierten Code stets vor dem Commit prüfen, obwohl die Mehrheit (96 %) ihm nicht vollständig vertraut, dass er funktional korrekt ist.

Die zu automatisierende Arbeit ist mechanisch und unangenehm: das Eingrenzen eines CI‑Fehlers auf die Ursache, sodass niemand viertausend Log‑Zeilen lesen muss, die Entscheidung, ob ein Befund nach einem Rebase noch gilt, das Reproduzieren eines Fehlers, das Schreiben einer offensichtlichen Korrektur. Ingenieure sollten die Intention, das Design und die Entscheidung darüber, wie viel Evidenz für eine bestimmte Änderung ausreicht, beibehalten. Wenn ein Senior‑Ingenieur einen Abend damit verbringt, Logs zu lesen, um herauszufinden, welcher von neun Fehlern relevant ist, ist das Triage und nicht Urteil, und genau diese Art von Arbeit sollten wir ihnen abnehmen.

KI‑Code‑Review‑Systeme können Probleme identifizieren, Korrekturen vorschlagen und diese Änderungen gegen die Continuous‑Integration‑Pipeline validieren. Wie verhindern Sie, dass ein autonomes Remediation‑System Regressionen einführt oder zu eng auf einen erfolgreichen Build optimiert, anstatt die umfassendere Software‑Qualität zu berücksichtigen?

Das Wesentliche ist, das „grün“ nicht als Akzeptanzkriterium zu behandeln, da ein erfolgreicher Build nur aussagt, dass die vorhandenen Tests nicht fehlgeschlagen sind.

Die meisten Einschränkungen, die wir für unsere eigene Remediation festlegen, betreffen den Umfang. Gitar behebt CI‑Fehler, die aufgetreten sind, und prüft, dass der Commit vor dem eigenen Push grün war, bevor es Verantwortung übernimmt. Es stoppt nach zwei nachfolgenden Commits, anstatt an einem roten Build weiterzuarbeiten. Wenn der Fehler nichts mit der Änderung zu tun hat – ein flüchtiger Test oder ein Infrastruktur‑Fehler – wird der Retry‑Pfad gewählt statt des Fix‑Pfads, weil „den Test zum Stillstand bringen“ das Ziel ist, das Sie einem fähigen Agenten am wenigsten wünschen.

Danach muss die Änderung eine Schicht passieren, die Gitar nicht kontrolliert. SonarQube bewertet das Ergebnis nach eigenen Kriterien, das Qualitäts‑Gate ist die Bedingung für den Merge, und das Team besitzt diese Richtlinie. Wir prüfen die Änderung zudem gegen das Issue, das sie implementieren soll, wobei die Anforderungsextraktion vom Abschluss‑Urteil getrennt bleibt, sodass eine Anforderung, die stillschweigend das Ticket verließ, nicht als umgesetzt zurückkehren kann.

Effektive KI‑Code‑Reviews hängen vom Verständnis der Konventionen, Abhängigkeiten, Architektur und des Zwecks einer vorgeschlagenen Änderung eines Repositories ab. Welchen Kontext benötigt ein KI‑Reviewer, um nützliche Entscheidungen zu treffen, und wie können Organisationen diesen Kontext aktuell halten, wenn sich ihre Systeme weiterentwickeln?

Er benötigt ausreichend Kontext, um wie ein erfahrener Reviewer zu argumentieren, nicht nur genug, um das Diff zu lesen. Dazu gehören der Zweck der Änderung, relevante Code‑Pfade und Typinformationen, Abhängigkeiten, Testverhalten, Repository‑Konventionen und die architektonischen Grenzen, die das Team von der Änderung erwartet.

Der Kontext muss zudem im Code verankert sein. Halten Sie Regeln und Review‑Leitlinien versioniert im Repository, aktualisieren Sie sie, wenn sich Services oder Konventionen ändern, und machen Sie die Verantwortlichkeiten für architektonische und Richtlinien‑Entscheidungen klar. Andernfalls kann ein KI‑Reviewer einen plausiblen Einzelevorschlag machen, der im Widerspruch dazu steht, wie das Gesamtsystem tatsächlich funktioniert.

Deterministische Analyse liefert konsistente und prüfbare Ergebnisse, während auf Large‑Language‑Models basierende Reviews zwischen Durchläufen variieren können. Wie sollten Unternehmen AI‑generierte Befunde in regulierten oder sicherheitskritischen Umgebungen dokumentieren, reproduzieren und steuern?

Der Audit‑Trail sollte die geprüfte Änderung, den KI‑Befund, die getroffene Entscheidung und die unabhängige Evidenz, die zur Validierung des Ergebnisses verwendet wurde, anzeigen. Teams können KI einsetzen, um Review und Remediation zu beschleunigen, während Durchsetzung und Genehmigungsentscheidungen in definierten Richtlinien und menschlicher Verantwortung verankert bleiben.

Welche Kennzahlen sollten Führungskräfte im Engineering verwenden, um zu bestimmen, ob KI‑Code‑Reviews die Softwareentwicklung tatsächlich verbessern? Sollten sie Review‑Zeit, entkommene Defekte, Fehlalarm‑Raten, Continuous‑Integration‑Fehler, technische Schuld, Entwickler‑Vertrauen oder andere Messgrößen priorisieren?

Beginnen Sie mit den Ergebnissen, nicht mit der Anzahl der Kommentare, die ein KI‑System erzeugt. Ich würde die Zeit vom Pull‑Request bis zum Merge messen, die Zeit, die für die Diagnose von CI‑Fehlern aufgewendet wird, die Rate, mit der Korrekturen beim ersten Validierungsversuch bestehen, und wie häufig Probleme in spätere Phasen oder die Produktion gelangen.

Dann beobachten Sie Qualitäts‑Signale wie Fehlalarm‑ und Ablehnungsraten, wiedereröffnete Issues, Regressionen, die mit kürzlich gemergten Änderungen verknüpft sind, und das Feedback der Entwickler, ob Befunde umsetzbar sind. Die passende Kennzahlen‑Mischung variiert je nach Team, aber die Frage bleibt konstant: Reduzieren wir Nacharbeiten und Wartezeiten im Review, ohne die Standards für sichere, zuverlässige Software zu senken?

Blicken wir in die Zukunft, erwarten Sie, dass die Softwareentwicklung zu einem kontinuierlichen Kreislauf wird, in dem Agents Code generieren, prüfen, testen und reparieren, wobei deterministische Leitplanken gelten? Wie werden sich in diesem Umfeld die Verantwortlichkeiten und erforderlichen Fähigkeiten menschlicher Software‑Ingenieure ändern?

Dieser Kreislauf existiert bereits, und Teams übernehmen ihn in einer festen Reihenfolge: zuerst Erkennung, dann Remediation, anschließend Genehmigung unter festgelegten Bedingungen und schließlich Merge. Niemand springt sofort zum letzten Schritt, und das treibende Argument dafür ist ihr eigener Code‑Base und nicht ein Benchmark. Der Merge ist für mich der interessanteste Schritt, weil die Konflikt‑Häufigkeit mit der Commit‑Durchsatzrate steigt, und genau diesen Durchsatz erhöhen wir durch all das.

Die Fähigkeiten, die an Wert gewinnen, liegen rund um den Kreislauf und nicht innerhalb davon. Präzise das Problem und seine Randbedingungen zu definieren, wird wichtiger, wenn ein Agent Ihre Beschreibung wörtlich übernimmt. Ebenso wichtig ist die Entscheidung, welche Evidenz ausreicht, um eine Änderung zuzulassen – früher ein implizites Wissen, das nun als Richtlinie schriftlich festgehalten werden muss, damit Automatisierung sie anwenden kann. Der Rest ist System‑Design: Festlegen, was automatisierte Arbeit berühren darf, ein Element, das der Agent nicht kontrolliert, das Ergebnis prüfen lässt und die Nachvollziehbarkeit bei Fehlern sicherstellt. Ingenieure werden weniger Zeit mit der eigentlichen Implementierung verbringen und mehr Zeit damit, zu entscheiden, was existieren soll und welche Nachweise dafür gelten, dass es funktioniert.

Vielen Dank für das großartige Interview, Leser, die mehr erfahren möchten, sollten Sonar besuchen.