AI-driven Software Engineering: Die Frage ist nicht ob, sondern wie

Ein Artikel von Kristian Köhntopp über „LLM Driven Development" hat bei uns viele Gespräche ausgelöst – weil er klar benennt, was wir beim Einsatz von KI im Software-Engineering selbst erlebt haben. Wir haben mit Marc Ponschab, Head of AI & Data, darüber gesprochen, wo für ein Software- und KI-Haus die eigentliche Herausforderung liegt: nicht beim Prompt, sondern bei allem, was drumherum gelöst sein muss.

Hallo Marc, in den letzten Wochen ging bei uns ein Artikel herum: „LLM Driven Development“ von Kristian Köhntopp. Was hat den Nerv getroffen?

Weniger eine Überraschung als ein erstaunlich präziser Spiegel. Köhntopp beschreibt die KI nüchtern als rasend schnellen Mitarbeiter, der wörtlich nimmt, was man ihm gibt. Wer länger dabei ist, kennt den Entwicklertyp „Zauberer“, der in konkurrenzlosem Tempo Beeindruckendes liefert, nur wie, weiß er allein. Ein Code-Agent ist dem gar nicht so unähnlich — und verlangt denselben Umgang: Leitplanken, Reviews, und jemanden, der die unausgesprochenen Annahmen festhält.

Dazu kommt ein Gedächtnis, das anders funktioniert als unseres: ein Arbeitstisch, kein Archiv. Die Kontextfenster wachsen zwar stetig, und in den effizienteren Umgang mit großem Kontext fließt viel Forschung — aber ein größerer Tisch ist noch keine Ordnung. Was der Agent für gute Arbeit braucht, muss klug strukturiert und passend aufbereitet auf dem Tisch liegen. Gute Ergebnisse hängen also vor allem davon ab, ob man ihm brauchbares Arbeitsmaterial liefert — der Kontext ist das eigentliche Material.

Genau das hatten wir beim eigenen Einsatz schon erfahren: Das naive „Bau mir eine Anwendung, die …“ trägt für kleine Schnipsel, aber sobald es ernst wird, braucht es Anforderungen, Tests, Reviews, Aufräumphasen – also klassisches Software-Engineering. Dass das jemand so klar ausformuliert, hat hier viele Gespräche ausgelöst.

Du sagst, der spannende Teil beginnt hinter dem Prompt. Köhntopp beschreibt die Disziplin am einzelnen Repository. Wo setzt Ihr an?

Der Artikel konzentriert sich – bewusst und zu Recht – auf die Werkbank: Wie arbeitet man diszipliniert mit Agenten an einem Projekt? Diese Präzision macht ihn ja so wertvoll. Wer unsere Situation kennt, ahnt aber schon, welche Fragen sich direkt anschließen: Als Dienstleister bauen wir für viele Kunden gleichzeitig, mit sehr unterschiedlichen Anforderungen. Da steht um jede dieser Werkbänke herum eine Reihe von Entscheidungen: Wo läuft das überhaupt? Darf der Code das Haus verlassen? Welches Modell für welchen Zweck? Wer weist die Qualität nach? Was kostet der Betrieb? Es gibt keinen einzelnen Schalter, den man umlegt. Deshalb fahren wir bewusst mehrgleisig.

Fangen wir beim Alltag der Entwickelnden an. Wie arbeitet Ihr konkret mit KI?

Unsere Leute wählen zwischen mehreren Anbietern – Claude, ChatGPT, Cursor. Wir schreiben kein Werkzeug vor; jede Aufgabe stellt andere Anforderungen – und jedes Werkzeug hat andere Stärken. Genauso arbeiten wir entlang des ganzen Methoden-Spektrums: vom Spec-Driven Development am disziplinierten Ende bis zum Vibe-Coding am schnellen. Köhntopps Artikel ist im Kern ein Plädoyer für das disziplinierte Ende, und das zu Recht – reines „bau mir das“ produziert bei echten Projekten viel, das plausibel aussieht und trotzdem nicht stimmt.

Aber Vibe-Coding hat seinen Platz: Wegwerf-Experimente, Prototypen, das Herausfinden, was überhaupt gewollt bzw. gebraucht wird. Die Kunst ist, der Aufgabe den passenden Modus zu geben. Die Kehrseite der freien Werkzeugwahl ist übrigens genau das Problem, das Köhntopp beschreibt, wenn mehrere Agenten im selben Repository arbeiten: Jedes Tool liest eine andere Instruktionsdatei, und schnell stehen sich widersprüchliche Regeln gegenüber. Wir halten deshalb eine kanonische Quelle der Wahrheit, damit nicht jedes Werkzeug auf seine Art plausibel das Falsche tut.

Du hast „Darf der Code das Haus verlassen?“ erwähnt. Das klingt nach mehr als einer Komfortfrage.

Für einen großen Teil unserer Arbeit ist es die erste Frage überhaupt. Wer für sich selbst entwickelt, kann sein Repository an einen Cloud-Agenten schicken; viele unserer Kunden dürfen das rechtlich nicht – oder wollen es aus guten Gründen nicht. Wir entwickeln auch Software unter staatlicher Regulierung – Healthcare ist das naheliegende Beispiel – und für Kunden, deren Verträge jede Weitergabe von Quellcode kategorisch ausschließen. Ein öffentlicher Cloud-Assistent ist damit schlicht raus.

Deshalb betreiben wir mehrere KI-Systeme im eigenen Haus, hinter unserer selbst entwickelten Middleware, dem iSYS AI Hub – auch mit sehr leistungsfähigen LLMs. Wir nutzen ihn für Experimente, für wissensbasierte Systeme mit RAG, für interne Prozessautomatisierung – und vor allem, um KI-gestützte Entwicklung genau dorthin zu bringen, wo sie sonst nicht hindürfte. Der Hub macht aus „das würden wir hier gern einsetzen“ ein „das dürfen wir“.

Schneller ist das eine. Köhntopp besteht auf Tests und Audits. Wie haltet Ihr Euer Qualitätsniveau – und wie weist Ihr es nach?

Das ist für uns der wichtigste Punkt, weil „fühlt sich schneller an“ wertlos ist, wenn die Qualität leidet. Wir messen uns an einem Niveau bei Usability, Softwarequalität und IT-Sicherheit – und es geht uns nicht nur darum, dieses Niveau mit KI zu halten, sondern es zu steigern und belastbar nachzuweisen. Köhntopps Mechanik passt dazu unmittelbar: Tests zuerst geben dem Agenten ein klares Ziel, statt ihn auf eine bloß plausibel aussehende Antwort optimieren zu lassen.

Und Audits als Artefakt in der Pipeline – Security- und Refactoring-Reviews, die Findings erzeugen, daraus Tickets, daraus Fixes – sind genau der Weg, Qualität nachweisbar zu machen, statt sie zu behaupten. Darum herum bauen wir Prozesse, die den KI-Einsatz tragen und nachvollziehbar machen.

Ein ehrlicher Vorbehalt gehört dazu: Ein wiederholbares Agenten-Audit ist ein Werkzeug, kein Ersatz für einen professionellen Security-Review bei kritischen Systemen – das sagt Köhntopp auch, und wir sehen das genauso.

Ihr ruft also nicht einfach eine API auf.

Nein – und hier zahlt unser Erbe aus Software-Engineering und Data ein. Es sind zwei Ebenen. Erstens der Betrieb: welche Architektur wo läuft, abgewogen gegen digitale Souveränität, Regulatorik in sensiblen Bereichen und ganz nüchtern Effizienz und Kosten. Leistungsfähige Modelle gut zu betreiben ist nicht umsonst, da trifft man bewusste Abwägungen. Zweitens die Modelle selbst: anforderungsgetriebene Modellauswahl, dann Techniken wie Distillation, gezieltes Nachtrainieren und Quantisierung, im Betrieb Kniffe wie speculative decoding – bis hin zu maßgeschneidertem Context-Engineering.

Letzteres führt direkt zu Köhntopps „Kontext ist Material“ zurück: Das Kontextfenster ist eine Werkbank, keine Müllhalde, und ein Modell ist nur so gut wie das Material, das man ihm vorlegt. Wir schneiden Material und Modell gezielt auf Aufgabe, Budget und Rahmenbedingungen zu.

Das klingt nach einem weit gediehenen Umbau. Wo steht Ihr auf diesem Weg?

Mittendrin – und das sagen wir bewusst so. Firmenweit ist das eine Transformation, wie sie viele unserer Kunden gerade selbst durchlaufen oder anschieben wollen. Der Einsatz ist in Projekten und Teams unterschiedlich weit, und wir standardisieren gerade, was sich dort bewährt hat. Genau diese Erfahrung geben wir weiter: Wir empfehlen nichts, das wir nicht selbst erprobt haben – mitsamt den Umwegen, die dazugehören.

Wenn der Agent so viel übernimmt – schrumpft dann der Job der Entwickelnden?

Er schrumpft nicht, er verschiebt sich. Was wir bei uns beobachten: Der Software-Engineer wird zum Umgebungsbauer. Ein wachsender Teil der Arbeit besteht darin, den Agenten eine passende ‚virtuelle Realität‘ zu errichten, in der sie optimale Bedingungen vorfinden. Das klingt abstrakter als es ist: Es geht um Projektregeln, Architekturentscheidungen, Sicherheitsgrenzen, Tests. Mir kommt das sehr bekannt vor: Als Engineering Manager habe ich früher genau das für Entwicklerteams getan – ein Umfeld schaffen, in dem gute Arbeit möglich wird. Heute bauen wir dieses Umfeld für Menschen und Agenten.

Und die Zauberer-Analogie vom Anfang trägt bis hierher: Dem Agenten die Magie lassen, aber das Urteil behalten. KI hebt die Decke dessen, was ein Team bauen kann – doch jemand muss entscheiden, was es wert ist, gebaut zu werden, was „gut“ hier heißt und ob das Ergebnis wirklich trägt. Das ist Engineering, und es ist menschlich. Für uns ist das kein Spruch: „Technology for the People“ schließt die Menschen ein, die sie bauen. Also ja, AI-driven – aber auf Ingenieursart.

Danke Marc für deine Zeit!

Sehr gerne.