Connect with us

Entwicklung & Code

KI Navigator #14: Muss KI gläsern sein? Zwischen Regulierung und Realität


Willkommen zur vierzehnten Ausgabe der KI-Navigator-Kolumne der DOAG KI Community!

Weiterlesen nach der Anzeige


Kolumne KI-Navigator - Benjamin Linnik

Kolumne KI-Navigator - Benjamin Linnik

Dr. Benjamin Linnik, promoviert in Kernphysik, vereint Expertise in Data Science, Software Engineering und Beratung. Als AI Tech Lead transformiert er Organisationen durch praktische AI-First-Ansätze – und schlägt dabei die Brücke zwischen technologischen Möglichkeiten und geschäftlichen Realitäten. Privat entspannt er gerne mit seiner Familie, umgeben von zwei Katzen und automatisiert gerne sein Smart-Home.




Dr. Alex Meistrenko hat als Unternehmensberater mit Fokus auf IT-Projekte in der Finanz- und Versicherungsbranche seine Leidenschaft für Systemarchitekturen, Datenmodellierung und Datenanalyse zum Beruf gemacht. Der promovierte Physiker und Mathematiker beschäftigt sich seit vielen Jahren mit der anwendungsorientierten Entwicklung von KI-Systemen – ebenso wie mit den mathematischen Prinzipien, auf denen sie beruhen.

Geschichte wiederholt sich

Die EU-KI-Regulierung erinnert uns Physiker an eine berühmte Debatte aus der Geschichte der Wissenschaft: Ende des 19. Jahrhunderts standen sich zwei Giganten der Physik gegenüber: Ludwig Boltzmann und Ernst Mach. Der einflussreiche Positivist Mach weigerte sich, Boltzmanns statistische Mechanik zu akzeptieren. „Ham’s aans g’sehn?“ (Haben Sie eins gesehen?), rief er provokant aus dem Publikum während einer von Boltzmanns Vorlesungen über Atome. Doch Boltzmann zeigte: Auch wenn jedes einzelne Molekül real ist und chaotisch wirkt, entstehen makroskopische Eigenschaften wie Temperatur und Druck aus statistischen Gesetzmäßigkeiten – ohne dass wir jeden einzelnen Molekülstoß verfolgen müssen.

Die EU verlangt von KI-Systemen eine transparente Nachvollziehbarkeit – aber was heißt das konkret? Es geht nicht darum, die Berechnung jedes einzelnen Tokens offenzulegen, sondern die Regulierung fordert, dass wir die Ergebnisse von KI-Systemen nachvollziehen und interpretieren können – so wie ein Physiker nicht die Bahn jedes einzelnen Gasmoleküls kennt, aber über Druck, Temperatur und Volumen das Verhalten des Gases zuverlässig beschreiben und steuern kann. Nicht mikroskopische Durchleuchtung, sondern makroskopisches Verständnis und Kontrolle sind das Ziel.

Die historische Parallele ist verblüffend: Damals wie heute geht es um dieselbe methodische Einsicht. In der Thermodynamik lehrt Boltzmann, dass man komplexe Systeme durch emergente statistische Eigenschaften verstehen und ihr Verhalten kontrollieren kann, ohne jeden Einzelprozess zu verfolgen. Bei der KI müssen wir ebenso akzeptieren, dass wir nicht jeden einzelnen Verarbeitungsschritt erklären müssen, sondern das Gesamtverhalten eines KI-Systems anhand der statistischen Gesetzmäßigkeiten und emergenten Eigenschaften überwachen und kontrollieren können.

Weiterlesen nach der Anzeige

LLMs verstehen: Von der Theorie zur Praxis

Die Kernfrage ist: Wie schaffen wir Vertrauen in Systeme, deren inneres Verhalten wir nicht vollständig verstehen und kontrollieren können? Dabei liegt die Antwort nicht in der unmöglichen Aufgabe, jeden Schritt zu erklären, sondern in der intelligenten Überwachung des Gesamtsystems – genau wie bei einem Motor, wo wir nicht jede Molekülbewegung im Brennraum verfolgen, aber sehr wohl die kritischen Parameter überwachen. Die Lösung liegt nicht in der Rückkehr zu deterministischen Ansätzen, sondern in der Entwicklung neuer Methoden für die Überwachung probabilistischer KI-Systeme.

Large Language Models (LLMs) sind probabilistische Systeme, deren Ausgabe nie deterministisch ist. LLMs verhalten sich wie ein komplexes Gas aus vielen Teilchen: Einzelne Token sind unvorhersehbar, aber das Gesamtverhalten lässt sich durch makroskopische Größen beschreiben und kontrollieren.

Die Kontrollgrößen der KI

Statt jeden einzelnen Schritt zu prüfen, überwachen moderne KI-Systeme makroskopische Metriken:

  • Lösungsqualität: Wie gut löst das System die anvertrauten Aufgaben faktisch korrekt und relevant über Zeit und Anwendungsbereiche?
  • Zuverlässigkeit: Wie konsistent sind die Antworten bei wiederholter Ausführung und unter gleichen Bedingungen?
  • Durchsatz: Wie viele Aufgaben kann das System pro Zeiteinheit bearbeiten?
  • Effizienz: Wie viel Rechenleistung und Kosten verursacht das System für nützliche Ergebnisse?
  • Quellentreue (Faithfulness): Wie treu bleibt die generierte Antwort den bereitgestellten Quelldokumenten, ohne unbelegte Informationen hinzuzufügen?

Diese exemplarischen Metriken erklären nicht jeden einzelnen Prozess, geben aber ein klares Bild vom Gesamtzustand des Systems. Zusätzliche Metriken lassen sich je nach Anwendungsfall heranziehen, etwa Fairness bei verschiedenen Nutzergruppen, Latenz bei Echtzeitanwendungen oder Robustheit gegen Angriffe bei sicherheitskritischen Systemen.

Messung makroskopischer Metriken in der Praxis

In der Praxis werden makroskopische KI-Metriken durch eine Kombination bewährter Methoden erfasst, die drei zentrale Säulen umfassen:

  • stichprobenartige Bewertung mit menschlichen Experten
  • LLM-as-a-Judge
  • Distributed Tracing

Stichprobenartige Bewertung mit menschlichen Experten: Statt jeden einzelnen Output zu prüfen, bewerten Fachexpertinnen und -experten repräsentative Stichproben in Testsystemen. Moderne Plattformen wie LangSmith oder Langfuse bieten Annotation Queues – strukturierte Warteschlangen, in denen Experten systematisch KI-Ausgaben nach vordefinierten Kriterien bewerten können. Diese Bewertungen schaffen Referenzdatensätze, um automatische Systeme zu kalibrieren.

LLM-as-a-Judge: skalierbare automatische Bewertung. Bei dieser Methode werden vordefinierte Testszenarien mit bekannten Sollergebnissen (Ground Truth) durch das zu testende System verarbeitet. Ein KI-System in der Richterrolle vergleicht dann die tatsächlichen Ausgaben mit den erwarteten Ergebnissen anhand festgelegter Bewertungskriterien wie Faktentreue und Relevanz. Dies ermöglicht eine konsistente und skalierbare Bewertung großer Datenmengen. Entscheidend ist die sorgfältige Auswahl und kontinuierliche Verfeinerung der Judge-Szenarien.

Distributed Tracing: Systemverhalten sichtbar machen. Moderne KI-Systeme nutzen OpenTelemetry und ähnliche Frameworks für Distributed Tracing. Wie ein Thermometer die Temperatur misst, ohne jedes Molekül zu erfassen, tracken diese Systeme Anfragen durch komplexe KI-Pipelines und sammeln dabei makroskopische Metriken wie Latenz, Durchsatz, Fehlerrate und Ressourcenverbrauch. Sie erfassen jeden Schritt im KI-System – vom Prompt über die Toolauswahl bis hin zur Modellausführung und Antwort – als „Span“ und verknüpfen sie zu einem „Trace“.

Dabei gilt die Unterscheidung zwischen Test- und Produktivsystem: Ein Mensch könnte im Prinzip jeden Pfad nachvollziehen, den ein KI-System genommen hat – das ist jedoch in Produktivsystemen weder praktikabel noch erwünscht. Aus Kostengründen wäre die manuelle Prüfung von Millionen von Traces unwirtschaftlich, und aus Datenschutzgründen ist es verboten, persönliche Nutzerdaten in den Traces für manuelle Inspektion zu speichern.

Stattdessen werden diese Trace-Daten automatisch zu makroskopischen Kennzahlen aggregiert: durchschnittliche Antwortzeiten, Fehlerquoten pro Zeitraum oder Ressourcenverbrauch nach Systemkomponenten. KI-Monitoring konzentriert sich auf datenschutzkonforme Aggregatdaten statt auf individuelle Nutzerinteraktionen.

Die drei Methoden ergänzen einander: Menschliche Bewertungen schaffen den Sollzustand während der Entwicklung in kontrollierten Testsystemen, LLM-Judges stellen sicher, dass die Qualität mit der Zeit nicht schlechter wird und Tracing-Systeme überwachen das laufende Systemverhalten in Produktivsystemen.

Differenzierte Sicht auf Regulierung

Das globale Regulierungsumfeld für KI zeigt klare prinzipielle Unterschiede zwischen den Regionen. Während die EU im Rahmen des ersten weltweiten KI-Gesetzes (EU AI Act Regulation) auf explizite Erklärbarkeit setzt, bevorzugen die USA, Australien, aber auch internationale Standards, System-Level Assurance – einen Ansatz, der makroskopische Metriken über mikroskopische Erklärbarkeit stellt und die Erklärung emergenter Eigenschaften des Gesamtsystems ohne detaillierte Kenntnis einzelner Entscheidungen zum Ziel hat.

Makroskopische Metriken für stochastische KI-Systeme sind technisch umsetzbar und bewährt. Beispiele hierfür sind durch die Standards und Methoden wie Assurance of AI-Enabled Systems und Artificial Intelligence Risk Management Framework (AI RMF 1.0) gegeben und zeigen insbesondere, dass System-Level Assurance auch im Bereich von KI-Systemen funktioniert.

Der EU-Weg ist technisch herausfordernder, aber nicht unmöglich, solange keine lückenlose mathematische Erklärung aller mikroskopischen Entscheidungen vorliegen muss – er erfordert jedoch andere technische Lösungen, die über makroskopische Metriken hinausgehen und möglicherweise höhere Entwicklungskosten zur Folge haben. Insbesondere lässt der EU-Weg aber auch viel Interpretationsspielraum für die Bedeutung einer transparenten und erklärbaren KI zu.

Darüber hinaus ist davon auszugehen, dass eine zweifelsfreie Klassifizierung eines KI-Systems als Hochrisiko-System (EU AI Act Art. 6) in der Praxis oft auf Schwierigkeiten stoßen wird. Folglich könnte die EU-Regulierung Innovation behindern oder zu alternativen technischen Entwicklungspfaden führen, in denen der KI-Einsatz im Bereich von Hochrisiko-Systemen auf grundlegende klassische ML-Verfahren beschränkt bleibt und somit die Erklärbarkeit von rückgekoppelten, nicht-linearen und tiefen neuronalen Netzen vermieden wird.

Hier ist davon auszugehen, dass sich solch eine Entwicklung zu einem enormen Wettbewerbsnachteil bspw. im Energiesektor entwickeln wird, der längerfristig in einer wiederholten Abhängigkeit von den führenden Tech-Giganten, vorwiegend aus den USA, resultieren wird, wie wir es auch schon im Bereich des Cloud-Computing erlebt haben.

Der Paradigmenwechsel: Von Code zu Systemen

Der Übergang von traditioneller zur AI-First-Entwicklung greift tiefer, als neue Tools einzuführen. In der traditionellen Entwicklung schreiben Developer den Code, führen manuelle Code-Reviews durch und pflegen separate Dokumentationen. AI-First-Entwicklung hingegen basiert auf natürlicher Sprache, automatisierten Abnahmetests, Everything-as-Code (inklusive Dokumentation) und autonomer Fehlerbehebung.

Die zentrale Frage lautet: Wie baut man Vertrauen in autonome KI-Systeme auf, damit sie sicher autonom arbeiten können? Die Antwort liegt in Quality Gates und makroskopischen Metriken, die emergente Eigenschaften des Gesamtsystems messen. Autonome Fehlererkennung und ausgeklügelte Quality Gates helfen dem KI-System, Fehler zu identifizieren und zu beheben.

Developer entwickeln sich zu KI-Kuratoren – eine zukunftsweisende Rolle, die weit über traditionelle Programmierung hinausgeht. Statt Code Zeile für Zeile zu schreiben, orchestrieren KI-Kuratoren intelligente Systeme: Sie definieren Architektur, etablieren Qualitätsstandards und schaffen adaptive Frameworks, während KI-Systeme die eigentliche Codegenerierung übernehmen.

KI-Kuratoren befähigen ihre Systeme zur selbstständigen Weiterentwicklung: Sie implementieren Lernmechanismen, die es dem System ermöglichen, aus Fehlern zu lernen, neue Technologien zu integrieren, sich an veränderte Anforderungen anzupassen und eigenständig Fähigkeiten zu erweitern. Durch kontinuierliche Validierung und strategische Führung entstehen Systeme, die nicht nur funktionieren, sondern sich proaktiv verbessern und mit dem Puls der Zeit entwickeln.

Als Beispiel für AI-First-Arbeitsweise: Das Recruiting-Startup Mercor erzielte mit 30 Mitarbeitern 100 Millionen US-Dollar jährliche Umsatzrate. Dieses technologienahe Startup ist ein Sonderfall und als AI-natives Unternehmen besonders früh dran – das Beispiel illustriert jedoch, in welche Richtung sich Automatisierungsgrade entwickeln könnten, auch wenn solche Ergebnisse noch nicht branchenübergreifend Standard sind.



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Wegen Vibe Coding: Open Source nur noch gegen Geld?


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Die immer stärkere Nutzung von Vibe Coding gefährdet das Open-Source-Prinzip (OSS). Viele OSS-Entwicklerinnen und -Entwickler ziehen ihre Motivation nur aus dem direkten Umgang mit der Community und dem Feedback von ihr. Was Open Source groß gemacht hat, bleibt durch Vibe Coding nun aber zunehmend aus.

Weiterlesen nach der Anzeige

Zu diesem Ergebnis kommt die Studie „Vibe Coding Kills Open Source“ der Central European University (CEU), der Universität Bielefeld und des Kieler Instituts für Weltwirtschaft. „Unser wichtigstes Ergebnis ist, dass unter traditionellen OSS-Geschäftsmodellen, bei denen die Verantwortlichen in erster Linie das direkte Nutzerengagement monetarisieren (höhere Sichtbarkeit, die zu bezahlten Gelegenheiten oder anderen Formen der Anerkennung führt), eine stärkere Verbreitung von Vibe Coding das OSS-Angebot reduziert und das Wohlergehen senkt.“

Ihre Urheber verstehen dies als Aufruf zum Handeln und schlagen Lösungen vor. Eine besteht darin, auf ein kostenpflichtiges Open-Source-Modell umzuschwenken, das Erträge an die Maintainer und Kontributoren ausschüttet.

Viel Traffic, wenig Engagement

Die von vier Ökonomen durchgeführte Studie nennt das CSS-Framework Tailwind CSS als Beispiel für eines von vielen Projekten, dem der Vibe-Coding-Boom zu schaffen macht. Sie zitiert dessen Anbieter mit den Worten, dass Tailwind zwar populärer sei als jemals zuvor, was die Download-Zahlen angeht. Der Traffic bei den Tailwind-Docs sei gegenüber 2023 aber um 40 Prozent gesunken, der Umsatz sogar um fast 80 Prozent.


Infografik zur Studie

Infografik zur Studie

Stillschweigen: Durch den zunehmenden Einsatz von KI verzeichnen Tailwind (links) und Stack Overflow (rechts) immer weniger Interaktionen.

(Bild: arxiv.org/abs/2601.15494)

Um die Auswirkungen von Vibe Coding auf OSS zu untersuchen, erstellten die Forscher ein Modell des Open-Source-Ökosystems, das auf den zugrundeliegenden ökonomischen Prinzipien basiert. Das Ergebnis: Vibe Coding senkt zwar einerseits die Kosten für die Softwareentwicklung und steigert die Produktivität. Andererseits schwächt es aber die Nachfrage, im Sinne von User-Engagement, und damit den Gemeinwohlgedanken hinter Open Source. „Das zentrale Ergebnis des Modells ist ein Wettrennen zwischen diesen beiden Kanälen.“

Weiterlesen nach der Anzeige

Da es nicht mehr hauptsächlich der Mensch ist, sondern die KI, die mit den OSS-Repositories interagiert, entfällt die Mitmach-Komponente weitgehend. Bei OSS-Maintainern, die sich ausschließlich darüber motivieren, verschlechtere sich dadurch die Qualität und die Verfügbarkeit des OSS-Codes.

Lesen Sie auch

Angesichts des immer beliebteren Vibe-Codings ließe sich der Status quo des OSS-Ökosystems deshalb nur dann aufrechterhalten, wenn man das Wertschöpfungsmodell der OSS-Maintainer grundlegend überdenke. „Die Lösung besteht nicht darin, die Einführung von KI zu verlangsamen – die Vorteile sind zu groß und die Technologie zu nützlich. Die Lösung besteht darin, die Geschäftsmodelle und Institutionen neu zu gestalten, die den Wert an die OSS-Maintainer zurückfließen lassen“, etwa durch kostenpflichtige Angebote.

Da sich KI-gestütztes Programmieren immer mehr durchsetzt, dürfte man um solch eine Diskussion nicht herumkommen.


(who)



Source link

Weiterlesen

Entwicklung & Code

Microsoft löst .NET Framework 3.5 aus Windows heraus


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Microsoft hat bekannt gegeben, dass das klassische .NET Framework in der Version 3.5 ab 2026 in Windows 11 nicht mehr Teil des Betriebssystem-Setups sein wird. Bisher war .NET Framework 3.5 eine optionale Komponente bei der Betriebssysteminstallation.

Weiterlesen nach der Anzeige

Demnächst eigenständige Installation

Künftig muss man das Installationsprogramm für .NET Framework 3.5 von der Microsoft-Website herunterladen und getrennt ausführen. Diese Änderung betrifft erst einmal nur Windows 11 ab Insider Preview Build 27965 und wird dann aber voraussichtlich schon mit dem Feature-Release 26H1 in den stabilen Windows-Kanal eingehen.

Für Windows 10 ist diese Änderung nicht geplant. Details zu der Änderung erläutert Microsoft in einer kurzen FAQ.

Support für .NET Framework 3.5 endet 2029

Das .NET Framework 3.5 ist am 19. November 2007 erschienen. Der Support für diese Version endet am 9. Januar 2029, siehe Microsoft .NET Framework Lifecycle Policy. Die Version 3.5 ist eine ältere Version des klassischen .NET Framework, das zahlreiche Nachfolger in den Versionen 4.0, 4.5, 4.6.x, 4.7.x und 4.8.x hatte.

Der Support für die Versionen 4.0, 4.5 und 4.5.1 endete schon im Jahr 2016. Die Versionen 4.5.2, 4.6 und 4.6.1 liefen 2022 aus dem Support. Der Version 4.6.2 geht es am 12. Januar 2027 an den Kragen.

Weiterlesen nach der Anzeige

Kein Support-Ende für .NET Framework 4.7 bis 4.8.1

Für die Versionen 4.7 bis 4.8.1 des klassischen .NET Framework wurde noch kein Support-Ende verkündet. Microsoft hatte bei der Einführung der modernen .NET-Versionen (im Jahr 2016 zunächst als .NET Core in den Versionen 1.0 bis 3.1, dann seit Version 5.0 nur noch .NET genannt) zwar offiziell erklärt, dass es keine signifikante Weiterentwicklung des .NET Framework mehr geben wird. Nach dieser Aussage im Jahr 2019 erschien aber im August 2022 noch die Version 4.8.1 für das klassische .NET Framework.

Microsoft hatte auch erklärt, dass man weiterhin an Fehlerbehebungen, Zuverlässigkeit und Sicherheit der klassischen .NET-Framework-Versionen arbeitet und dass das .NET Framework weiterhin mit Windows ausgeliefert werde. Wie die Änderung an der Auslieferungsart von .NET Framework 3.5 jetzt zeigt, bezieht sich diese Aussage „Teil von Windows“ aber offenbar nicht auf alle Versionen.

Aktuelle Version .NET 10.0

Die aktuelle Version des modernen .NET ist die Version 10.0, die am 11. November 2025 erschienen ist – zusammen mit C# 14.0. Im heise-Blog Der Dotnet-Doktor erscheint jede Woche ein Beitrag, der neue Funktionen in C# 14.0 und .NET 10.0 vorstellt.

Details zu der Umstellung von .NET Framework 3.5 finden sich im Microsoft-Blog.


(rme)



Source link

Weiterlesen

Entwicklung & Code

Interview: So arbeiten die Entwickler bei OpenAI


Für viele Entwickler sind Programmierassistenten auf Basis großer Sprachmodelle (LLMs) nicht mehr wegzudenken. Da Kompetenz in diesem Feld für neue Modelle besonders relevant ist, nennen Entwickler Coding-Kapazitäten oft neben Mathe-Fähigkeiten, wenn sie die nächste Generation ihrer Produkte hypen wollen. Derzeit nutzen Entwickler oft nicht das Eine Modell, sondern greifen für verschiedene Anforderungen auf die Klassenbesten verschiedener Anbieter zu – wenn nicht sogar kleinere Modelle simplere Aufgaben abwickeln.

Weiterlesen nach der Anzeige

Unter dem Namen Codex bündelt OpenAI die Programmierfähigkeiten seines Angebots, auf die sich über eine CLI-Variante, als IDE-Extension oder auf dem Mac neuerdings per App zugreifen lässt. Im Gespräch mit iX erzählt Dominik Kundel, Developer Experience Lead bei OpenAI, über Softwareentwicklung mit Codex bei OpenAI und den Zielen, die das Unternehmen mit dem Tool verfolgt.




Dominik Kundel ist Developer Experience Lead für Codex bei OpenAI in San Francisco. Er sitzt bei OpenAI zwischen dem Produkt- und dem Go-to-Market-Team, programmiert am Tooling und an der Dokumentation und Lehrmaterialien, um dafür zu sorgen, dass Leute das Meiste aus Codex herausholen können.

iX: OpenAI hat zwischen 2021 und 2025 drei Werkzeuge vorgestellt, die Codex heißen. Was ist der aktuellste Ableger der Reihe denn jetzt genau?

Dominik: Grundsätzlich verstehen wir Codex als eine Einheit. Codex ist ein Software Engineer, der da sein soll, wo Entwickler arbeiten. Das ist einmal die Terminal-Oberfläche Codex CLI. Außerdem gibt es Codex für Code Reviews in GitHub und IDE Extensions, um Codex in Cursor oder in VS Code zu benutzen. Darunter liegen die Codex-Modelle, aktuell GPT-5.2 Codex. Das sind auf Programmieren trainierte Modelle und der Codex Harness, in dem die Agenten interagieren. Diese Teile geben wir auch in der API raus, worüber Cursor oder Open Code ebenfalls mit Codex interagieren können.

Wie helft ihr euren Nutzern dabei, den Überblick über ihren generierten Code zu behalten?

Einerseits mit der Funktion Codex Code Review, die automatisch mit der ChatGPT-Subscription kommt. Codex ist gut darin, selbst komplexe Codebases zu navigieren und zu verstehen. Wir haben sehr große Codebases bei OpenAI und testen das Ganze damit selber. Andererseits ist Codex gut darin, Rückfragen zu stellen, um den Code zu verbessern. Wir benutzen Codex selbst viel, um sozusagen aufzuräumen. Wir schicken Codex die Aufgabe, Sachen zu refactorn oder Bugs zu finden. Ich hab letztes Jahr am Agents SDK gearbeitet und hatte dabei konstant mehrere Codex-Instanzen laufen, die noch nach Bugs gesucht haben oder Sachen verbessert haben.

Fast alle bei OpenAI nutzen Codex

Weiterlesen nach der Anzeige

Das heißt, ihr entwickelt bei OpenAI selbst mit Codex?

Grundsätzlich sieht es bei uns so aus, wie bei vielen Silicon Valley Softwarefirmen, wir benutzen also Git und PR-Reviews. Allerdings haben wir durch den ganzen Prozess Codex verteilt. Das heißt, Entwickler, aber auch Product Manager, Designer, Data Scientists, andere, eigentlich mittlerweile fast die komplette Firma benutzt Codex, um Code zu schreiben. Der Code geht dann aber noch durch die traditionellen Pull Requests Reviews und den ganzen Prozess. Wir nutzen Codex aber auch für einen zusätzliches Review, durch das aller Code läuft. Wir haben das Modell explizit auf Code Reviews trainiert.

Mich überrascht häufig, wenn Codex Sachen findet, die ich selbst nicht gefunden hätte. Vor allem, da ich zum Teil an Dokumentation arbeite und dann etwa einen Pull Request hochschicke und auf einmal dann ein Kommentar kommt, dass auf der aktuellen Seite die Dokumentation und der Source Code nicht übereinstimmen. Etwa, weil es eine Logikproblem gibt. Trotzdem wird jeder PR noch von Menschen durchschaut. Häufig ist es so, dass die Leute als Erstes Codex benutzen, um den PR zu reviewen und dann eventuell irgendwelche CI/CD Probleme von Codex reparieren lassen, bevor ein Kollege den Pull Request dann durchschaut.

Hast du das Gefühl, du hast dann noch die Kontrolle über die ganzen Agenten oder bist du eigentlich nur noch ein Mensch, der Sachen abnickt?

Nee, ich habe noch Kontrolle. Vor allem bei komplexeren Problemen bitte ich Codex, erstmal einen Plan zu schreiben. Wir haben einen Kollegen, Aaron Friel, der nennt seine Pläne „Exec Plans“. Er lässt das Modell ein komplettes Dokument schreiben, wo es dokumentiert, welche Entscheidungen es getroffen hat und was der Fortschritt ist. Da hat man ein Log, durch das man nochmal durchgehen kann und die Richtigkeit der Entscheidungen bestätigen kann. Das lässt sich auch noch weiter aufteilen, um weiterhin mehrere PR-Reviews zum Durchgehen zu haben.

Was wir generell vorschlagen ist, die gleichen Systeme aufzusetzen, wie wenn man mit einem großen Team an denselben Sachen arbeitet. Das heißt, CI ist eine der ersten Sachen, die ich normalerweise aufsetze, um sicherzustellen, dass ich dann auch Test Coverage habe. Das hilft dann auch Codex. Codex ist generell darauf trainiert, zu verifizieren, ob die Aufgaben fertig sind. Wenn man also nach einem neuen Feature fragt und bereits Tests hat, schreibt Codex automatisch neue Tests. Sowas hilft dann bei der Maintenance. Genauso wie weiterhin Code Reviews zu machen und Dokumentation zu behalten. Ich habe das Gefühl, dass die Codebases besser aussehen, weil Codex hilft Features zu dokumentieren und auch bei anderen Aufgaben hilft, die in der Realität oft hinten anstehen.

Benutzt ihr nur Codex oder benutzt ihr auch Modelle von anderen Anbietern?

Wir benutzen nur OpenAI-Modelle. Bei der Wahl des Editors sind wir nicht festgelegt, da kann jeder Kollege die IDE of Choice einsetzen, die eventuell noch weitere KI-Features hat. Wenn ich mal Code schreiben muss, dann benutze ich Cursor, wo ich dann das Cursor Tab Modell benutze. Cursor ist allerdings auch ein großer OpenAI-Kunde.

Kann Codex mit Claude mithalten?

Viele Entwickler schwören aktuell auf Claude Code mit Opus 4.5. Wie wollt ihr da mit Codex aufholen?

Ich glaube, dass es da zwei Perspektiven gibt. Auf der einen Seite sind die Leute, die Claude Code sehr mögen, mit den Features, die es gibt und auch das Terminal Interface, was die Modelle haben. Die Leute mögen es, mit Opus zu schreiben. Wir hören häufig, dass Codex zu langsam ist. Da arbeiten wir auch dran. Auf der anderen Seite gibt es viele Leute, die mittlerweile auf Codex schwören. Die Anwender loben, dass sie Codex ein Problem geben und das Tool einfach daran arbeitet. Wenn sie dann später wiederkommen, ist Codex komplett fertig.

Anders als bei Claude Code, wo man sich dran gewöhnt hat, hin und her zu schreiben, ist Codex gut darin, ein Problem zu nehmen und wenn es das Ziel verstanden hat, einfach für mehrere Stunden an diesem Problem arbeiten. Peter Steinberger, der im Moment auf X und LinkedIn sehr viral geht, schreibt darüber, dass er Codex bevorzugt und wie er das meiste aus Codex rausholt.

Wie wollt ihr Codex denn schneller machen?

Ich kann da keine Details nennen, aber wir haben zum Beispiel vor Kurzem eine Cerebras-Partnerschaft angekündigt.

Umgang mit großen Codebasen

Du hast über große Codebasen gesprochen, wie ihr sie ja selber habt. Gibt es besondere Strategien für den Umgang damit?

Mono-Repos helfen sehr, um dem Modell Kontext zu geben. Also, in der Lage zu sein, Codex etwa auf das Backend zu verweisen, wenn man gerade zum Beispiel an einer Android-App arbeitet. Ein gutes Beispiel dafür ist unser Browser Atlas. Da gibt es das Agent Panel, über das ein Agent in einem logged-in oder logged-out State dann selbst mit dem Browser umgehen kann. Das Feature und den Wechsel zwischen den Zuständen hat größtenteils Codex geschrieben. Dafür musste es die Codebase mit vier verschiedenen Sprachen durchgehen. Diesen Kontext zu geben ist sehr hilfreich.

Außerdem schlagen wir vor, CI/CD zu haben und generell Validation Tools. Wenn man also Frontend-Produkte baut, auch die Tools zu haben, die sicherstellen, dass die Frontend-Komponenten richtig gerendert werden. Man kann dann die Screenshots wieder als Image-Input in Codex reingeben und Codex kann sich dann quasi selbst validieren. Ein weiterer Punkt ist Naming. Wir empfehlen, Namen zu benutzen, die sehr einfach zu finden sind. Codex benutzt nämlich Tools wie grep und ripgrep, um sich in der Codebase zurechtzufinden. Wenn es die Sachen schnell finden kann, ist Codex wesentlich schneller.

Einer der Gründe, warum Codex den Leuten langsam vorkommt, ist, dass es häufig erstmal auf eine Tour geht, um sich zurechtzufinden. Codex springt nicht direkt rein und schreibt irgendeinen Code, sondern es geht erstmal rum und versucht, zu verstehen. Genauso wie das ein Software-Entwickler machen würde: Wie sieht die Codebase hier aus, wo sind die Daten oder die Dateien, mit denen ich umgehen möchte. Das Modell versucht zu verstehen, wie das Ganze aufgebaut ist, bevor es dann anfängt. Naming Conventions, die dem Modell erlauben einfacher herumzuspringen, helfen.

Das kann die Codex App

Was hebt die neue Codex App vom CLI oder dem Plug-in-Einsatz ab?

Die App ist gezielt entwickelt, um Leuten beim Multitasking zu helfen. Viele Leute nutzen mehrere Codex-Instanzen parallel, die dann mehrere CLI-Tabs nebeneinander aufbauen. Die Codex-App ist als Command Center gedacht. Man kann den Überblick über alle Projekte behalten und schnell zwischen den Projekten wechseln. Dabei hat die App ein ähnliches User-Interface wie die IDE-Extension, man hat also Zugriff auf Features wie Worktrees. Wenn man an mehrere Features in der gleichen Codebase arbeiten will, kann man mehrere Worktrees aufbauen, um dann Aufgaben im Hintergrund laufen zu lassen und dann schnell dazwischen zu wechseln. Außerdem heben wir in der App Agent Skills hervor, also die Möglichkeit, dem Agenten neue Capabilities wie bestimmte APIs oder bestimmte Tools beizubringen.

Also generell Tool-Use-Funktionen?

Das ist ähnlich wie Tool Use, nur, dass der Agent das Ganze „progressively discovered“. Man kann jetzt bestimmte Prozesse einbauen. Ich habe letztens ein Screenshot-Skill gebaut, der auch in der App enthalten ist. Damit kann man Codex anweisen, Screenshots der App zu machen, die Codex dann benutzen kann, um selber zu verifizieren, ob es den Job richtig gemacht hat. Als ich diesen Skill gebaut habe, habe ich dann meinen PR zu GitHub geschickt, der Codex Code Review auf GitHub hat dann ein Problem gefunden. Ich habe dann den GitHub „address code review“-Skill benutzt, um Codex auf GitHub zu schicken und das Problem zu analysieren, zu fixen und ein Update zu dem PR zu schicken.

Man kann in diese Skills Prozesse einarbeiten und dann mit dem kombinieren, was wir Automations nennen. Automations sind dann Aufgaben, die entweder jede Stunde oder zu einer bestimmten Uhrzeit am Tag laufen. Die Automations laufen im Hintergrund auf einem Worktree. Wenn sie irgendein Problem finden, können sie das Ganze an dich weiterleiten. Ein Kollege hat beispielsweise jede Stunde eine Automation laufen, die alle seine Pull Requests durchgeht und guckt, ob CI bei denen grün ist oder ob es irgendwelche Probleme gibt und fixt die dann automatisch selber. Oder die Automation läuft einmal am Tag durch Sentry durch und guckt sich die Error-Logs an. Dann sucht sich das Programm ein besonders großes Problem aus und versucht es selber zu fixen und öffnet einen PR.

Mit Codex und den Automations in der App kann man als Entwickler dann auch die Aufgaben neben der Feature-Entwicklung im Blick behalten. Also die Aufgaben, die so an der Seite hängen oder nicht-technische Aufgaben sind, wie etwa bei der Codebase auf dem Laufenden zu bleiben. Da kann man sich zum Beispiel einmal am Tag ein automatisiertes Update mit den Änderungen an der Codebase schicken lassen und dazu, was in dem Fall an der Dokumentation aktualisiert werden muss.

Codex – nur ein Tool für Experten?

Du hast berichtet, dass ihr am Ende immer die Ergebnisse von Codex kontrolliert. Wie vibe-coding-freundlich ist euer Tool?

Wir wollen, dass Codex eine Stütze für professionelle Entwickler ist. Codex kann an sehr komplexen Problemen arbeiten, weswegen es auch etwas langsamer ist. Das heißt, es kommt darauf an, was man aus dem Vibe Coding herausholen will. Ich habe zum Beispiel schonmal eine komplette Demo-App während eines Meetings gebaut, was viele so Vibe Coding nennen würden. Es funktioniert, aber es ist nicht die gleiche Erfahrung, als wenn man sich beispielsweise was mit Lovable bauen lassen würde.

Dominik, vielen Dank für das Interview.


(pst)



Source link

Weiterlesen

Beliebt