Ali-Reza Adl-Tabatabai, Gründer und CEO von Gitar – Interview-Serie

Ali-Reza Adl-Tabatabai, Gründer und CEO von Gitar, ist ein erfahrener Technologie-Unternehmer, dessen Karriere einige der einflussreichsten Technologie-Unternehmen im Silicon Valley umfasst, darunter Uber, Google (GOOGL ), Facebook (META ), Intel (INTC ), AMD und IBM. Bevor er Gitar 2023 gründete, war er Senior Director of Engineering bei Uber, wo er half, die Developer-Platform-Initiativen des Unternehmens zu leiten, nachdem er zuvor Führungspositionen bei Google innehatte, wo er für die Site-Reliability-Engineering-Produkte wie Communications, Photos, Social, Cloud und technische Infrastruktur verantwortlich war.

Früher in seiner Karriere arbeitete er an Compiler-Technologien, virtuellen Maschinen, parallelen Computingsystemen und Hardware-Optimierungen bei Intel Labs und dem HipHop-VM-Team von Facebook, während er auch an der Stanford University fortgeschrittene Compiler-Designs lehrte. Seine jahrzehntelange Erfahrung in Programmiersprachen, Infrastruktur-Verlässlichkeit, Developer-Tooling und groß angelegter Systemarchitektur hat ihn zu einer prominenten Figur in der sich entwickelnden AI-gesteuerten Software-Entwicklungslandschaft gemacht.

Gitar konzentriert sich auf ein wachsendes Problem, das aus dem Aufstieg der AI-gesteuerten Software-Entwicklung entsteht: die Validierung und Sicherung des enormen Volumens von maschinengeneriertem Code, das nun in Unternehmenssysteme einfließt. Die Plattform verwendet AI-Agenten, um Code-Reviews zu automatisieren, CI/CD-Pipeline-Fehler zu untersuchen, Fehler und Sicherheitslücken zu identifizieren, Korrekturen vorzuschlagen und direkt in bestehende Engineering-Workflows über Tools wie GitHub, GitLab (GTLB ), Jenkins, Jira und Slack zu integrieren. Anstatt allein im AI-Code-Generation-Bereich zu konkurrieren, positioniert sich das Unternehmen um das, was es als “agentic Quality Gates” bezeichnet, und hilft Engineering-Teams, Zuverlässigkeit, Sicherheit und betriebliche Aufsicht zu gewährleisten, während die Software-Entwicklung zunehmend in Richtung autonomer und AI-gesteuerter Codierungs-Workflows verschoben wird.

Sie haben bei Uber, Google und Intel Labs die Leitung von Engineering-Teams innegehabt und an großen Entwickler-Plattformen und Infrastruktur gearbeitet. Welche spezifischen Erfahrungen aus dieser Reise haben Sie dazu veranlasst, Gitar zu gründen, und warum konzentrieren Sie sich auf Code-Validierung anstelle von Code-Generation?

Über Uber, Google, Facebook und Intel Labs hinweg habe ich an Entwickler-Plattformen auf sehr unterschiedlichen Ebenen gearbeitet, und die gleiche Lektion zeigte sich immer wieder: die Entwickler-Erfahrung ist ein Wettbewerbsvorteil. Gute Tools ziehen die besten Ingenieure an und halten sie, und Unternehmen können schnell vorankommen. Entwickler wollen schnelle, lautlose Tools, die sie in Fluss halten und die Routinearbeit automatisieren. Aber Entwickler-Tooling ist tief gespalten, und die meisten Unternehmen verbrennen enorme Ingenieurs-Ressourcen, nur um eine kohärente Erfahrung zusammenzustellen. Ich habe gesehen, wie viel Hebelwirkung es gibt, wenn man das behebt.

AI ändert die Gleichung, indem es möglich macht, weit mehr der Entwickler-Workflows als zuvor zu automatisieren. Code-Generation ist bereits gut abgedeckt, aber das hat nur den Flaschenhals nach unten verschoben, zu Validierung, Refactoring und Wartung des Codes, den wir jetzt in einem beispiellosen Umfang produzieren. Das ist der Bereich, auf den Gitar sich konzentriert. Wenn AI mehr Code schreibt, ist die knappe Ressource nicht die Generation, sondern das Vertrauen, die Richtigkeit und die Wartbarkeit dessen, was geliefert wird. Code-Validierung ist der Teil des Workflows, der bestimmt, ob AI-generierter Code tatsächlich sicher in die Produktion gelangt, und das ist das schwierigere, wertvollere Problem, das gelöst werden muss.

Mit dem Aufstieg von AI-generiertem Code haben viele Teams jetzt mit dem zu kämpfen, was einige als Code-Überlast bezeichnen. Wie groß ist dieses Problem in Unternehmen heute, und wo haben Teams am meisten Schwierigkeiten?

Der Wandel besteht nicht darin, Code zu schreiben. Dieser Teil bewegt sich bereits schneller, als die meisten Teams absorbieren können. Was sich geändert hat, ist alles, was danach kommt. AI-Tools generieren einen ständigen Strom von Pull-Requests, oft schneller, als Teams sie überprüfen können, was Druck in Teilen des Systems erzeugt, die nicht für diese Ausgabe konzipiert waren.

Jede Änderung muss immer noch validiert werden. Code-Review. CI. Sicherheitsprüfungen. Genehmigungen. Nichts davon verschwindet einfach, weil Code schneller generiert wird. Was früher ein handhabbarer Fluss war, ist zu einer Rückstand geworden. Teams sind nicht mehr blockiert, weil ihnen Ideen oder Implementierungen fehlen. Sie sind blockiert, weil ihnen das Vertrauen fehlt. Kann das geliefert werden? Ist es sicher? Hat es etwas Subtiles gebrochen?

Dort sitzt der Reibungspunkt jetzt. Nicht in der Erstellung, sondern darin, Code ohne Risiko über die Ziellinie zu bringen.

Die Branche hat sich hauptsächlich auf die Generierung von Code konzentriert. Warum glauben Sie, dass die Validierung übersehen wurde, und warum wird sie jetzt kritischer?

Weil das System unterhalb der Code-Generation nicht im gleichen Tempo evolviert ist. Wenn die Ausgabe zunimmt, wird alles unterhalb gestresst. Pull-Requests werden größer und häufiger. CI-Fehler beginnen, sich zu stapeln. Review-Zyklen werden komprimiert, weil niemand die Zeit hat, jeden Change tief zu überprüfen.

Die Qualität beginnt zu sinken, nicht weil Ingenieure sich nicht um die Qualität kümmern, sondern weil der Umfang Kompromisse erzwingt. Plattform-Teams übernehmen mehr von der Last, indem sie Pipeline-Probleme handhaben, Fehler triagieren und versuchen, alles am Laufen zu halten. Senior-Ingenieure agieren als Koordinatoren, indem sie Log-Dateien zusammenstellen, Probleme diagnostizieren und entscheiden, was sicher zu mergen ist.

Teams stehen vor einer Wahl, die nicht wirklich funktioniert. Code schnell durchpushen und später mit Regressionen umgehen oder langsamer machen und Qualität schützen, aber akzeptieren, dass die Geschwindigkeit sinkt. Diese Spannung zeigt sich derzeit in allen Ingenieurs-Organisationen.

Gitar verwendet AI-Agenten, um Code-Reviews, Tests und CI-Workflows zu handhaben. Wie unterscheiden sich diese Agenten grundlegend von herkömmlichen statischen Analyse-Tools und regelbasierten Pipelines?

Der Unterschied ist nicht kosmetisch. Ein echter Agent muss mehr tun, als nur auf Prompts zu reagieren. Er muss mehrschrittige Arbeit handhaben, planen, Tools verwenden, Kontext verfolgen und Aufgaben ohne ständige Eingabe vorantreiben.

Die meisten Systeme erfüllen diese Anforderung nicht. Sie generieren Ausgaben, aber sie handhaben nicht die Ausführung. Wenn diese Tools in echten Workflows platziert werden, zeigen sich die Lücken schnell. Sie reduzieren nicht die Komplexität. In vielen Fällen fügen sie eine weitere Schicht hinzu, die jemand verwalten muss.

Das ist, warum die Konversation sich von “haben wir Agenten” zu “welche Arbeit kann tatsächlich zuverlässig gehandhabt werden” verschiebt.

Vertrauen ist eine große Hürde für die Automatisierung in der Software-Entwicklung. Wie stellt Gitar sicher, dass sein Validierungsprozess zuverlässig genug für Teams ist, um sich darauf zu verlassen?

Das Muster, das funktioniert, ist einfach. Arbeit in kleinere Schritte aufteilen. Klare Grenzen definieren. Ausgaben kontinuierlich validieren. Menschen involvieren, wo Entscheidungen Risiken mit sich bringen.

Agenten können Code überprüfen und Probleme identifizieren, die leicht zu übersehen sind. Sie können CI-Fehler analysieren, verwandte Fehler gruppieren und auf eine wahrscheinliche Ursache hinweisen. Sie können Korrekturen vorschlagen und in einigen Fällen in einer kontrollierten Weise anwenden.

Dies reduziert die Menge an manueller Triage, die Ingenieure durchführen müssen. Es entfernt Ingenieure nicht aus der Schleife, aber es ändert, wo sie ihre Zeit verbringen. Die meisten Systeme operieren mit Checkpoints, nicht mit vollständiger Unabhängigkeit.

Ihre Plattform ermöglicht es Teams, ihre eigenen Agenten zu erstellen. Wie wichtig ist Anpassung für die Unternehmensadoption, und welche sind einige der interessantesten Anwendungsfälle, die Sie sehen?

Anpassung ist für die Unternehmensadoption unerlässlich. Jedes Plattform-Team verbringt erhebliche Ressourcen damit, CI an die spezifischen Bedürfnisse des Unternehmens anzupassen, was traditionell besondere Skripte, Konfiguration, Tool-Integrationen, Log-Verarbeiter und den Rest des Klebebands erfordert, das die moderne Dev-Infrastruktur zusammenhält.

Gitar reduziert diese Arbeit. Plattform-Teams können benutzerdefinierte Prüfungen mit natürlichen Sprach-Prompts erstellen, was es ihnen ermöglicht, Dinge zu validieren, die mit herkömmlicher Programm-Analyse schwierig oder unmöglich sind, wie z.B. die Markierung von Benutzeroberflächen-Strings, die für die Übersetzung mehrdeutig sind, oder die Validierung von Updates der AGENTS.md-Dateien. Sie können auch benutzerdefinierte Workflows auf Pull-Requests automatisieren: PRs mit Jira-Problemen verknüpfen, Folge-Tickets für ungelöste Review-Kommentare öffnen, flaky Tests automatisch erneut ausführen oder benutzerdefinierte To-Do-Listen zu PR-Zusammenfassungen hinzufügen.

Die interessantesten Anwendungsfälle sind meistens die, die wir nicht vorhergesehen haben. Teams kennen ihre Code-Basen und ihre Schmerzpunkte besser als jeder Anbieter, also wenn man ihnen ein Primitive gibt, das “wir wünschen, CI könnte nur X überprüfen” in eine 10-zeilige Prompt umwandelt, beginnen sie sofort damit, Dinge zu automatisieren, die wir standardmäßig nie gebaut hätten. Das ist genau, was wir wollen.

Moderne Ingenieurs-Teams verlassen sich auf eine komplexe Stapelung von Tools wie GitHub, GitLab und Jira. Wie wichtig ist es für Gitar, in bestehende Workflows integriert zu werden, anstatt sie zu ersetzen?

Die Adoption hängt davon ab, Entwickler dort zu treffen, wo sie bereits sind. Ingenieure wollen keine neue Oberfläche lernen, keinen weiteren Dashboard-Check und keine weitere Kontext-Umschaltung zwischen Tools. Sie wollen, dass ihre bestehenden Workflows schneller und leiser werden. Also ist eine tiefe Integration mit GitHub, GitLab, Jira und dem Rest des Stacks für uns nicht nur ein Nice-to-Have, sondern die gesamte Strategie.

Unser Ehrgeiz geht jedoch weiter. Wir versuchen nicht, diese Tools zu ersetzen, und wir versuchen auch nicht, nur in sie einzustecken. Wir automatisieren die Workflows, die über sie laufen. Die PR-Überprüfung, das Ticket-Linking, die Folge-Aufgaben, die flaky Test-Wiederholungen, all das sollte autonom im Hintergrund passieren. Und wir gehen weiter: Ein Agent bearbeitet die PR direkt, um Code-Review-Feedback zu bearbeiten und CI-Fehler zu beheben, und handhabt letztendlich die Genehmigung und das Merging für Änderungen, die den Richtlinien des Teams entsprechen. Die Rolle des Entwicklers verschiebt sich von der Steuerung jedes Schritts zur Festlegung der Absicht, Überprüfung der Ergebnisse und Handhabung von Ausnahmen.

Der Endzustand ist nicht ein neues Tool, in das Entwickler einloggen. Es sind die bestehenden Tools, die mehr auf eigene Faust tun, damit Entwickler sich auf die Arbeit konzentrieren können, die tatsächlich ihre Urteilsfähigkeit erfordert.

Sie haben angedeutet, dass menschliche Code-Reviews möglicherweise zu Ausnahmen werden könnten. Was muss passieren, damit Organisationen sich mit diesem Wandel wohl fühlen?

Vertrauen wird in Stufen aufgebaut, nicht auf einmal. Organisationen müssen sehen, mit ihrem eigenen Code, dass AI die Fehler und Sicherheitslücken finden kann, die wirklich zählen, und ihre benutzerdefinierten Regeln mit Präzision und hoher Abdeckung durchsetzen. Von dort aus ist der Weg zum autonomen Merging eine natürliche Fortschreibung durch vier Stufen zunehmenden Vertrauens.

Die erste Stufe ist die Erkennung. Teams bauen Vertrauen auf, dass Agenten echte Probleme mit einer niedrigen Falsch-Positiv-Rate finden. Sobald dieses Vertrauen etabliert ist, lassen sie die AI automatisch PRs blockieren, wenn sie kritische Probleme findet.

Die zweite Stufe ist die Behebung. Die AI findet nicht nur Probleme, sondern behebt sie auch, entblockt die PR und macht CI grün, ohne menschliche Intervention. Vertrauen bedeutet hier, dass der Agent Probleme und CI-Fehler präzise lösen kann, ohne Dinge zu brechen.

Die dritte Stufe ist die Genehmigung. Sobald Teams sehen, dass Agenten zuverlässig PRs grün machen, lassen sie die AI PRs unter den Regeln genehmigen, die sie definieren. Organisationen eine explizite Kontrolle über die Bedingungen für die Auto-Genehmigung zu geben, ist es, was diesen Schritt sicher und nicht leichtsinnig macht.

Die vierte Stufe ist das Merging. Die AI landet die Änderung, wieder unter Bedingungen, mit denen das Team einverstanden ist. Dieser Schritt hat seine eigene Hürde: Der Agent muss Merge-Konflikte präzise lösen, ohne Regressionen oder Brüche in main einzuführen. Das ist wichtig, weil die Häufigkeit von Konflikten mit der Commit-Throughput steigt, und die Throughput explodiert, während AI mehr Code generiert. Große Monorepos spüren das bereits; jeder andere wird es bald.

Der Wechsel zu AI als Standard-Reviewer ist nicht ein einziger Sprung des Vertrauens. Es ist eine Leiter, und Organisationen klettern sie eine Sprosse nach der anderen, während die Beweise sich ansammeln.

Wenn AI mehr von der Codierungsarbeit übernimmt, wie sehen Sie die Rolle der Senior-Ingenieure in den nächsten Jahren evolvieren?

Senior-Ingenieure sind bereits in Koordinationsrollen wechselnd, indem sie Log-Dateien zusammenstellen, Probleme diagnostizieren und entscheiden, was sicher zu mergen ist. Das ist keine Rolle, die jemand geplant hat. Es ist eine Reaktion auf das System, das unter der Last bricht.

Wenn Agenten mehr der wiederholbaren Validierungsarbeit übernehmen, bleiben Ingenieure in der Schleife, aber bewegen sich höher in der Hierarchie. Sie verbringen weniger Zeit mit manueller Triage und mehr Zeit damit, zu entscheiden, was geliefert werden sollte und warum.

Gitar hat kürzlich 9 Millionen Dollar aufgenommen, um die Plattform zu skalieren. Was sind Ihre Top-Prioritäten für diese Mittel, und was sieht der Erfolg in den nächsten 12 bis 18 Monaten aus?

Das Kapital wird für zwei Prioritäten eingesetzt. Die erste ist der Marktzugang: Wir skalieren unsere Unternehmensbewegung und investieren in die Bewusstseinsbildung der Entwickler, damit die Teams, die von Gitar profitieren könnten, wissen, dass wir existieren. Die zweite ist das Produkt: Wir bauen weiterhin auf unsere Vision von vollständig autonomer Code-Validierung und -Qualität, was tiefergehende Agenten-Fähigkeiten, breitere Workflow-Abdeckung und engere Integration mit den Tools bedeutet, die Entwickler bereits verwenden.

Erfolg in den nächsten 12 bis 18 Monaten sieht wie eine bedeutende Basis von Unternehmenskunden aus, die Gitar über ihre Code-Basen hinweg ausführen, einer Entwickler-Community, die uns als Standard für AI-gesteuerte Code-Validierung erkennt, und klaren Beweisen, dass unsere Agenten mehr der Review-, Behebungs- und Merge-Arbeit autonom übernehmen. Wenn wir auf dem richtigen Weg sind, ist die Konversation in einem Jahr nicht mehr, ob AI Code validieren kann, sondern wie viel der Validierungs-Pipeline ein Team an Agenten übergeben hat.

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