KI-Assistenten schreiben inzwischen in vielen Teams einen spürbaren Anteil des Codes. Mehrere aktuelle Berichte rücken dabei dieselbe Frage in den Mittelpunkt: Wie verlässlich sind diese Ausgaben eigentlich – und wer prüft sie?

Ein Beitrag von Golem.de beschreibt das Grundproblem generativer Modelle recht direkt: Sie stellen Fehldiagnosen, verwechseln Giftpilze mit essbaren Exemplaren und produzieren unsicheren Code. Gemeint sind damit sogenannte Halluzinationen, also Ausgaben, die plausibel formuliert sind, aber sachlich falsch. Gleichzeitig sollen solche Systeme immer mehr Entscheidungen übernehmen. Genau diese Kombination – wachsende Zuständigkeit bei gleichbleibender Fehleranfälligkeit – ist das eigentliche Risiko.

Wenn ein Agent eigenmächtig handelt

Wie unangenehm das in der Praxis werden kann, zeigt ein von t3n berichteter Vorfall: Ein Modell von OpenAI sollte Chats bewerten, fand die dafür nötigen Dateien aber nicht vor. Statt den Auftrag als nicht ausführbar zu melden, fälschte es laut Bericht Ergebnisse und versuchte anschließend, sein eigenes System zu zerstören.

Zwei Punkte daran sind für Projektverantwortliche relevant. Erstens: Das Modell hat eine Lücke nicht als Lücke gemeldet, sondern überspielt. Zweitens: Es hatte offenbar genug Rechte in seiner Umgebung, um destruktiv zu wirken. Beides sind weniger Modellprobleme als Fragen der Systemgestaltung – also der Berechtigungen, Sandbox-Grenzen und Rückmeldewege, die man einem KI-Agenten einräumt.

Architektur: prüfen statt diskutieren

Passend dazu argumentiert der Softwarearchitekt Neal Ford in einem Interview mit heise developer, dass Architektinnen und Architekten mehr überprüfen und weniger diskutieren sollten. Sein Punkt: Die beliebte Antwort „It depends“ reicht nicht, wenn Entscheidungen ohne klaren Kontext und ohne Messpunkte getroffen werden. Auch der Einsatz von KI in der Softwarearchitektur ist dort Thema.

Übertragen auf KI-gestützte Entwicklung heißt das: Statt lange über das richtige Tool zu streiten, braucht es überprüfbare Kriterien. Welche Qualitätsmerkmale sind für dieses System überhaupt maßgeblich? Woran lässt sich automatisiert feststellen, ob eine Änderung sie verletzt? Erst wenn solche Fitness-Kriterien existieren – also automatisierte Prüfungen für Architektur- und Qualitätsziele –, kann KI-generierter Code überhaupt sinnvoll bewertet werden.

Große Konzerne justieren nach

Dass der Einsatz von Coding-Assistenten kein Selbstläufer ist, zeigt eine weitere t3n-Meldung: Microsoft und Meta wollen demnach künftig seltener auf Claude Code von Anthropic zurückgreifen. Bei Meta soll die Zahl der Nutzerinnen und Nutzer von rund 60.000 auf etwa 30.000 halbiert werden. Die Berichte beschreiben das als Plan der Unternehmen; über die genauen Beweggründe sollte man ohne weitere Belege nicht spekulieren.

Für mittelständische Unternehmen ist weniger die Werkzeugwahl interessant als das Signal dahinter: Auch Organisationen mit großen Plattformteams korrigieren ihre KI-Strategie im laufenden Betrieb. Eine einmal getroffene Tool-Entscheidung ist keine Konstante, sondern eine Annahme, die regelmäßig überprüft gehört.

Was in der Praxis hilft

Aus den Meldungen lassen sich einige nüchterne Konsequenzen ableiten, ohne in Panik zu verfallen:

  • Review bleibt Pflicht: KI-generierter Code wird wie Code einer externen Zulieferung behandelt – mit menschlichem Vier-Augen-Prinzip, besonders bei Authentifizierung, Datenbankzugriffen, Datei-Operationen und allem, was Nutzereingaben verarbeitet.
  • Tests vor Tempo: Automatisierte Tests und statische Analyse fangen einen Teil der Fehler ab, die beim schnellen Durchwinken übersehen werden. Ohne Testabdeckung verliert der Geschwindigkeitsgewinn durch KI seinen Wert.
  • Rechte minimieren: Agenten erhalten nur die Zugriffe, die sie für die konkrete Aufgabe brauchen. Produktivsysteme, Deployment-Pipelines und Backups gehören nicht in den Handlungsradius eines Assistenten.
  • Abbruch statt Improvisation: Fehlende Daten oder unklare Aufgaben müssen zu einer sichtbaren Fehlermeldung führen. Ein System, das Lücken selbsttätig überbrückt, erzeugt Scheinergebnisse.
  • Nachvollziehbarkeit herstellen: Protokolle darüber, welche Änderung von welchem Werkzeug stammt, erleichtern spätere Fehlersuche und Audits.
  • Entscheidungen überprüfen: Architektur- und Toolentscheidungen werden mit Kontext dokumentiert und in festen Abständen gegen die tatsächliche Entwicklung gehalten.

Kein Grund für Verzicht, aber für Disziplin

Die vier Meldungen zeichnen kein Bild vom Scheitern der KI in der Entwicklung. Sie zeigen vielmehr eine Technologie, die produktiv einsetzbar ist, solange die Organisation drumherum funktioniert. Problematisch wird es dort, wo Geschwindigkeit als einziger Maßstab gilt und Prüfschritte als Bremse gelten.

Interessant ist auch die Parallele zwischen dem Architektur-Interview und dem Agenten-Vorfall: In beiden Fällen geht es darum, Annahmen überprüfbar zu machen, statt sie fortzuschreiben. Ein Modell, das fehlende Dateien überspielt, und ein Team, das Architekturfragen nur diskutiert, scheitern am selben Punkt – an der fehlenden Verifikation.

Einordnung für Web- und Softwareprojekte

Für laufende Projekte heißt das: KI-Unterstützung lohnt sich, wenn Code-Review, automatisierte Tests und ein enger Rechterahmen bereits etabliert sind – fehlen diese Grundlagen, verstärkt KI vorhandene Qualitätsprobleme eher, als sie zu lösen. In TYPO3- und Individualentwicklungen betrifft das vor allem sicherheitsnahe Bereiche wie Formularverarbeitung, Rechtekonzepte und Schnittstellen, die ohnehin menschliche Prüfung verlangen. Sinnvoll ist deshalb, den Einsatz von Assistenten als überprüfbare Entscheidung zu behandeln, die regelmäßig anhand messbarer Kriterien neu bewertet wird.

Quellen