Als Konstantin Diener auf der DWX über KI und Softwareentwicklung sprach, hatte das Publikum einiges zu lachen – auch über sich selbst. Sein Punkt: Viele Entwickler:innen seien in den letzten Jahren zu reinen Jira-Ticket-Abarbeitern geworden. Warten, bis ein Ticket im Körbchen liegt, umsetzen, Pull Request stellen, fertig. Das große Ganze verstehen? Fehlanzeige.
Genau das soll sich mit dem "Product Engineer" ändern, dem Rollenbild, das Diener in seinem Vortrag skizziert hat. Für ihn ist das keine Revolution, sondern eine Rückkehr. Ende der 90er, Anfang der 2000er, mit Tools wie Delphi oder Visual Basic, hätten kleine Teams oder sogar Einzelpersonen Software geschrieben, mit der ganze Unternehmen liefen. Danach sei Entwicklung immer feinteiliger geworden: Frontend Developer, Backend-Spezialist, DevOps, Tester, Produktmanager. Diener nennt das Ergebnis "zu Staub zerrieben" – jede Menge Koordinationsaufwand statt Wertschöpfung. Die Produktivitätsschübe durch KI, vor allem bei Fleißarbeit, könnten diesen Trend nun umkehren. Weg vom reinen Coding, hin zur ganzheitlichen Problemlösung.
Die gebrochene Abstraktion
Bei der Frage, wo Automatisierung an ihre Grenzen stößt, wird Diener grundsätzlich: Compiler seien heute eine vollständige Abstraktion – Source Code rein, Maschinencode raus, niemand muss mehr hinschauen. KI-Modelle seien das nicht. Eine "gebrochene Abstraktion" nennt er sie, weil man sich eben nicht darauf verlassen kann, dass unten rauskommt, was man erwartet. Damit ist die eigentliche Frage laut Diener gar keine technische mehr, sondern eine juristische: Wer haftet, wenn KI-generierter und KI-geprüfter Code beim Kunden Schaden anrichtet? Erste Betriebshaftpflichtversicherungen schließen solche Schäden bereits aus – die Firma bleibt dann auf den Kosten sitzen.
Diener berichtet außerdem von einer Entwicklung in einigen Firmen weg vom reinen "Agentic AI mit Review" hin zu einem Modell, das er als Exoskelett beschreibt: Die KI tippt schneller, aber das mentale Modell der Software soll weiterhin im Kopf der Entwickler:in entstehen – wie beim Pair Programming, nur dass die KI meist die Rolle des Drivers übernimmt und der Mensch die des Navigators.
Werde doch Softwareentwickler:in
Was das für die Ausbildung bedeutet? Weniger, als man denken könnte, findet Diener. Am Informatikstudium selbst müsse sich wenig ändern – Grundlagenwissen über Prozessoren oder relationale Datenbanken bleibe wertvoll, auch wenn man später nie einen eigenen Compiler baut. Wichtiger werde der Praxisanteil, gerade weil viele Studierende ihre Übungsaufgaben inzwischen einfach von der KI lösen lassen und dabei nichts lernen. Sein Rat: KI als Sparringspartner nutzen, in wechselnden Rollen als Driver oder Navigator – so, wie frühere Generationen aus dicken Büchern und eigenen Nebenprojekten gelernt haben.
Zum Kontrollverlust, den viele Entwickler:innen beim Umstieg vom "Ich schreibe eleganten Code" zum "Ich verantworte Ergebnisse" spüren, hat Diener keine einfache Antwort – aber eine Erinnerung. Die meisten seien nicht Softwareentwickler:in geworden, um Tickets zu schrubben, sondern wegen jenes Gefühls beim ersten eigenen Programm, das tatsächlich lief. Genau dahin, sagt er, müsse die Branche zurück: zur Frage, wofür man etwas baut und für wen. Die letzte Bastion des Menschen, da sind sich laut Diener auch KI-Vorreiter:innen einig, sei die Entscheidung, was überhaupt gebaut werden soll.
Konstantin Diener ist CTO bei cosee und seit vielen Jahren leidenschaftlicher Softwareentwickler. Er brennt für Clean Code und Test Driven Development und sorgt in seiner Rolle dafür, dass Softwareprodukte nach modernen Continuous-Delivery-Prinzipien entstehen. Mit der Zeit ist ihm neben dem "das Produkt richtig bauen" zunehmend wichtig geworden, auch das richtige Produkt zu bauen – deshalb beschäftigt er sich verstärkt mit Product Discovery und passenden Techniken.
