AI Development mit Qualität und Bewusstsein
von Klemens Loschy
Mit AI lässt sich mittlerweile ja ein großer Teil des Entwicklungs-Workflows unterstützen, wenn nicht sogar komplett umsetzen. Hinzu kommt, dass Applikationen nicht mehr ausschließlich von (erfahrenen) Entwickler:innen erstellt werden müssen, sondern dass mit der Hilfe der passenden AI-Agenten fast jeder dazu in der Lage ist: mit den richtigen Prompts oder Agenten purzeln sogar von Beginn an Testfälle heraus (die bei jeder Änderung verifiziert und erweitert werden), der Code wird statisch analysiert und natürlich compiliert, ein Security Check im Anschluss wird ebenfalls durchgeführt. Damit ist doch für die Qualität nachhaltig gesorgt, oder? Man könnte sogar argumentieren, dass so ein AI-Agent bessere Ergebnisse produziert als die meisten Junior-Entwickler:innen, und das auch noch um ein Vielfaches schneller. Daraus resultiert fast automatisch, dass von nun an ganz stark auf AI gesetzt werden muss, damit man konkurrenzfähig bleiben kann.
Wenn wir aber einen Schritt zurück gehen, sehen wir vielleicht, dass es einen Mittelweg zwischen “wir lassen nur noch die Agenten arbeiten” und “besser keine AI verwenden” geben muss. Aber schauen wir uns das gemeinsam im Detail an.
Die Junior-Falle
Dass viele AI-Agenten mit dem Fokus auf Software-Entwicklung besseren Code als Junior-Entwickler:innen schreiben und dafür wesentlich weniger Zeit brauchen, das kann man schon fast als gegeben annehmen. In jeder professionellen Software-Entwicklung braucht es aber jemanden, der den erstellten Code reviewed und gegebenenfalls auf besondere fachliche oder technische Anforderungen hin prüft - Senior-Entwickler:innen kommen hier ins Spiel. Es muss jemanden - und damit meine ich tatsächlich einen Menschen - geben, der den Überblick über das Projekt (aus einer technischen Perspektive) behält und technische Entscheidungen treffen darf und kann. Letztlich muss ja auch jemand aus technischer Sicht die Verantwortung über die Umsetzung übernehmen bzw. übernehmen können, da tut man sich aus jetziger Sicht noch schwer, diese Verantwortung auf einen AI-Agenten abzuwälzen (auch das kommt vielleicht noch).
Wir waren ja gerade dabei, die Arbeit unserer Junior-Entwickler:innen von AI Agenten machen zu lassen (weil schneller und vermutlich auch besser). Das bringt aber Konsequenzen mit sich, die man zumindest betrachten muss:
Die Senior-Entwickler:innen müssen mehr Code reviewen und bewerten als ohne AI Unterstützung (denn der Output der AI-Agenten ist wesentlich höher)
Die Rolle des Junior-Entwicklers, so wie sie bisher gelebt wurde, könnte dadurch obsolet werden
Ohne diese Junior-Entwickler:innen, die viel Zeit in die vielen und immer mehr werdenden Aspekte der Softwareentwicklung gesteckt haben und zahlreiche Probleme lösen mussten, kann es zukünftig keine Senior-Entwickler:innen mehr geben
Wenn es zukünftig aber (zumindest) weniger Senior-Entwickler:innen gibt, wer prüft dann den Code und übernimmt letztlich die technische Verantwortung?
Das skizziert natürlich das Worst-Case Szenario, aber vieles deutet aktuell darauf hin, dass diese Richtung zum Teil eingeschlagen wird.
Wer testet den Tester?
“Wie konnte der Fehler bis in die Produktion kommen, wir haben dafür doch einen Unit-Test?” - Hand hoch, wer noch nie einen Unit-Test gefunden hat, der falsch umgesetzt wurde oder die eigentlich notwendigen Prüfungen nicht (vollständig) umgesetzt hatte? Ein Unit-Test muss jedenfalls eines machen, bevor er ein guter Unit-Test überhaupt sein kann: er muss einmal fehlschlagen! Nur wenn geprüft wurde, dass der umgesetzte Unit-Test im Fehlerfall auch wirklich anschlägt, kann man sich mit hoher Wahrscheinlichkeit sicher sein, dass der Unit-Test auch bei einem tatsächlichen Fehlverhalten der getesteten Funktionalität anschlägt. Ein von Anfang an “grüner” Testfall sagt genau gar nichts aus.
Da kommt wieder das Review - oder im Test-Design auch “4 Augen Prinzip” genannt - ins Spiel: Testfälle müssen ebenfalls qualitätsgesichert werden! Wie immer gilt: ein risikobasierter Ansatz ist hier durchaus sinnvoll (wie fast immer in der QA). Man wird wohl nicht jeden Testfall Peer-Reviewen, aber die wesentlichen müssen geprüft werden. Die AI kann, wenn man sie richtig steuert, viele und natürlich auch gute Testfälle komplett automatisiert erstellen und durchführen, ich würde mich aber nicht darauf verlassen, ohne die Testfälle auch kritisch reviewed zu haben. Auch hier muss es fachlich und technisch gut ausgebildete menschliche Mitarbeiter geben, die diese Tätigkeiten jetzt, und auch in Zukunft übernehmen.
Die menschliche Aufsicht
Im EU-AI Act (Artikel 14) ist die menschliche Aufsicht bei Hochrisiko-Systemen vorgeschrieben. Jetzt kann man natürlich argumentieren, dass nicht jedes System gleich als Hochrisiko-System eingestuft werden muss und dementsprechend diese vorgeschriebene Regel nicht immer anzuwenden ist, fair enough - auch hier wieder ein ganz klarer risikobasierter Ansatz. Und ja: wenn ich mir eine eigene kleine App Vibe-Code, dann werde ich deutlich weniger Wert auf Code-Qualität und Testabdeckung legen und auch mit etwaigen Fehlern leben können.
Aber auch bei nicht Hochrisiko-Systemen im kommerziellen Umfeld wird es problematisch, wenn durch Fehler im Produktivbetrieb z.B. personenbezogene Daten oder Anmeldedaten geleaked werden, denn (noch) haftet das Unternehmen und die Geschäftsführung bei derartigen Vorfällen und nicht die AI, die (vielleicht) den meisten Code dieser Systeme geschrieben hat.
Der “Social Media” Druck
Wenn man in den “Sozialen Medien” Beiträge über AI sieht, hört oder liest, dann bekommt man durchaus den Eindruck, dass diese Technologie unfehlbar ist: da werden Frameworks, Applikationen und ganze SaaS Plattformen in wenigen Stunden oder Tagen aus dem Boden gestampft. Erst vor Kurzem habe ich wieder einen Beitrag gesehen, in dem ein Entwickler meinte, dass sein AI-Agent, während er selbst geschlafen hat, seine Applikation umgesetzt hat (in nur 2 oder 3 Stunden), wofür ein Entwickler mehrere Tage gebraucht hätte. Was er nicht erzählt ist, wieviel Zeit er in die Analyse und Refactoring des Codes aufgewendet hat und welche Features unzureichend oder gar nicht umgesetzt wurden. Und verständlicherweise wird dadurch Druck auf die Unternehmen aufgebaut: “Alle anderen sind ja jetzt offensichtlich so viel schneller mit AI, also müssen wir da nachziehen”. Und welche Tätigkeiten kann und konnte man immer schon kürzen? Richtig: Qualität! In Form von schlechter UX, mieser Performance oder ganz offensichtlichen Fehlern, die dann natürlich wieder von und mit AI gefixt werden (müssen), denn die Zeit sich einen Überblick über die Codebasis zu verschaffen, die hat sich keiner genommen.
AI: die “Silver Bullet”?
Wer erinnert sich noch an die 2000er, wo UI-Testautomation (damals noch mit Mercury WinRunner) aufkam und alle wie wild begonnen haben ihre Tests zu automatisieren? Dank “Capture/Replay” konnte da auch der Fachbereich fleißig mithelfen (so zumindest laut Mercury Werbung) - also die “Silver Bullet” um alle Qualitätsprobleme mit einem Schlag zu lösen! Ewig viel Zeit und Ressourcen sind daraufhin in den Aufbau und die Pflege solcher automatisierter Testfall-Portfolios geflossen und es hat einige Jahre gedauert, bis viele Unternehmen feststellen mussten, dass UI-Testautomation natürlich einen Mehrwert bringt, aber nur zielgerichtet in Maßen eingesetzt und als Ergänzung zu vielen anderen Test-Tätigkeiten, und schon gar nicht die “Silver Bullet” ist, als die sie einst dargestellt wurde.
Wie sollen wir also mit AI umgehen?
Aus meiner Sicht muss man AI als Werkzeug sehen: Werkzeuge haben sich seit jeher verbessert und damit die Produktivität, die Qualität und die Arbeitsweise maßgeblich verändert. In den letzten Jahren haben wir ein neues Werkzeug in die Hand bekommen, mit dem wir erstmal lernen müssen richtig umzugehen. Aber wir Entwickler, Tester, allgemein wir Menschen sind immer noch diejenigen, die dieses Werkzeug verwenden und für das Ergebnis verantwortlich sind oder sein sollten! Aussagen wie “die AI hat gesagt” oder “keine Ahnung was der Code da genau macht, aber es funktioniert” haben in einer professionellen Software-Entwicklung einfach nichts zu suchen, jetzt nicht und auch nicht in der Zukunft! Software Development ist und bleibt ein immens anspruchsvolles Handwerk, das von gut ausgebildeten und erfahrenen Handwerkern durchgeführt wird.
Wir bei razzfazz.ai werden dieses neue Werkzeug natürlich zielgerichtet einsetzen, unsere Effizienz damit steigern aber unsere Grundwerte damit nicht über Bord werfen: wir erstellen qualitativ hochwertige, performante, sichere, gut bedienbare und getestete Produkte. Wir kennen unsere Code-Basis und übernehmen Verantwortung.
Quellen und weiterführende Informationen
EU AI Act: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689