Warum Out-of-the-Box-KI-Teams frustriert — und was dagegen getan werden kann

Bei den meisten Technologien ist es so, dass man sich mit der Zeit immer ruhiger auf sie verlässt. Bei KI-Tools ist das Gegenteil der Fall: in ihrer jährlichen Umfrage von mehr als 49.000 Entwicklern hat Stack Overflow eine steigende Nutzung von 84% festgestellt, während das Vertrauen in die Genauigkeit dieser Tools von 40% auf 29% innerhalb eines Jahres sank.

Dieser Effekt ist mir vertraut. Unsere erste Erfahrung mit KI-Tools in der Entwicklung hatte wenig mit dem Wow-Effekt von schnellerer Arbeit und weniger Routine zu tun, über den die Technikpresse schrieb. Unsere Entwickler waren enttäuscht: die KI produzierte mittelmäßigen Code, der lange Zeit zum Überprüfen benötigte und am Ende neu geschrieben werden musste. Das Team erwartete, dass die KI Zeit sparen würde, und stattdessen bekamen sie extra Arbeit. Kurz nach diesen ersten Versuchen, KI-Tools in den täglichen Arbeitsablauf einzubinden, kehrte das Team zu seiner alten Arbeitsweise zurück.

Heute beschleunigen diese Tools sowohl das Schreiben von Code als auch dessen Überprüfung für unsere Entwickler — nicht, weil wir ein besseres Modell gefunden haben, sondern weil wir unsere Arbeitsweise geändert haben. Hier ist, was uns half, dorthin zu gelangen.

Warum KI-generierter Code Entwickler frustriert

KI stützt sich auf eine enorme Menge an öffentlichem Code aus dem Internet, und dieser Code ist selten vorbildlich: seine Qualität ist durchschnittlich, und das Modell reproduziert diesen Durchschnitt.

Aber “durchschnittlich” ist nicht die Obergrenze dessen, was möglich ist — es ist einfach das, was das Modell ausgibt, bis es Ihr Projekt kennt: seine Konventionen, seine Code-Struktur, seine architektonischen Entscheidungen. In einer Umfrage von über 600 Entwicklern fand Qodo heraus, dass unter denen, die unzufrieden mit der Qualität des KI-Code waren, 44% dies genau auf mangelnden Kontext zurückführten. Das ist es, was die Ausgabe auf einem mittelmäßigen Niveau festhält.

Die gute Nachricht ist, dass der Kontext, den die KI erhält, die einzige Variable ist, die ein Team vollständig kontrolliert. Wie gut das Tool das Projekt versteht, hängt nicht vom Modell ab, sondern von dem, was Sie ihm geben.

Der zweite Grund ist mental — die Natur der Arbeit ändert sich. Wenn die KI den größten Teil des Codes schreibt, ist die Hauptaufgabe des Entwicklers nicht mehr das Schreiben, sondern das Überprüfen dessen, was generiert wurde: das Lesen einer Lösung von jemand anderem, die Alternativen abwägen, entscheiden, was bereit ist, ausgeliefert zu werden. Das ist eine andere Fähigkeit als das Schreiben von Code selbst, und für jeden, der das Schreiben mochte, fällt es nicht leicht.

In seinem Octoverse-Bericht 2025 beschreibt GitHub genau diese Veränderung: die Entwickler, die am weitesten mit KI gekommen sind, nennen sich nicht mehr “Autoren von Code” und werden eher zu dessen “kreativen Direktoren”, wo die Schlüsselfähigkeit darin besteht, zu steuern und zu überprüfen. Aber der Weg zu dieser Rolle führt durch Fehler und Frustration, bis eine Person den Nutzen in ihrer eigenen Arbeit sieht.

Was KI von einer Quelle der Frustration in ein funktionierendes Werkzeug verwandelt

Als unser Team zum ersten Mal mit KI begann, arbeiteten einige Entwickler mit Claude Code, andere versuchten OpenAI Codex, GitHub Copilot oder Gemini CLI, und jedes Tool ergab ein anderes Ergebnis. Als wir also begannen, Ordnung in die Arbeitsweise des Teams mit KI zu bringen, taten wir das Erste, was wir taten, und entschieden uns für ein einzelnes Tool.

Dies ist nicht nur unsere Praxis. Nehmen Sie die Geschichte des Teams bei Linear: bis Anfang 2026 liefen sie nach dem Prinzip “Jeder arbeitet, wie es ihm passt”, und im Januar gab die Führung diese Herangehensweise auf und brachte alle Entwickler auf eine einzige Arbeitsweise — die Wahl auf zwei KI-Tools einengend und die Entwickler auffordernd, Code nur mit ihnen und nicht von Hand zu schreiben. Laut dem Unternehmen stieg die durchschnittliche Produktivität bereits im nächsten Monat um 30% bei den zusammengeführten PRs und um 33% bei den pro Ingenieur abgeschlossenen Aufgaben.

Das bedeutet jedoch, dass ein gemeinsames Tool allein den Code nicht verbessert — es muss konfiguriert werden: Regeln festlegen, ähnlich wie eine rules.md, die ausführen, wie Code zu schreiben ist — welche Ansätze zu verfolgen sind, was zu vermeiden ist. Dann kommen benutzerdefinierte Fähigkeiten für die Aufgaben, die typisch für Ihr Projekt sind, damit Sie nicht immer wieder das Gleiche erklären müssen. Und schließlich ist es sinnvoll, den Agenten auf Ihre bestehende Codebasis zu verweisen: er analysiert, wie das Projekt geschrieben ist, und produziert neuen Code in demselben Stil, anstatt in einem generischen. Je mehr Kontext das Tool erhält, desto weniger müssen Sie von Hand nachbearbeiten.

Aber der schwierigste Teil ist nicht technisch. Der Übergang vom Autor des Codes zu seinem Evaluator geschieht nicht von selbst — dieser Übergang benötigt Hilfe. Der direkteste Weg ist Schulung und Zertifizierung. In unserem Fall zum Beispiel absolvieren zehn Entwickler ein Partnerprogramm mit dem Anbieter des Tools, während neben ihnen eine Person arbeitet, die für die Einführung verantwortlich ist und erklärt, warum das Tool ein bestimmtes Ergebnis produzierte und wie es zu korrigieren ist.

Sobald das Team auf eine koordinierte Weise arbeitet, bleibt ein Flaschenhals — die Überprüfung — und es lohnt sich, diese mit KI zu verstärken. Der Agent geht durch jeden Pull-Request und übernimmt das Offensichtliche: routinemäßige Fehler, Stil, Wiederholungen, Sicherheitslücken. Der menschliche Überprüfer muss dann nicht mehr alles ununterschieden ansehen, sondern nur noch die Architektur und die kritischen Entscheidungen. Der Effekt ist sogar innerhalb der Unternehmen, die diese Tools bauen, bemerkbar: bei Anthropic stieg nach der Einführung eines solchen Agenten der Anteil der Pull-Requests, die eine substantielle Überprüfung erhielten, von 16% auf 54%, und Ingenieure widersprachen weniger als 1% seiner Kommentare.

Für uns verkürzte dies einen Überprüfungszyklus, der früher über zwei oder drei Tage und mehrere Runden erstreckte, und es nahm die Routine von unseren leitenden Ingenieuren, indem es ihnen die wirklich harten Stellen überließ. Sobald das Tool schließlich Ergebnisse produzierte, die nicht neu geschrieben werden mussten, erschien auch das Vertrauen in es.

Wo das Vertrauen in KI-Tools sich auszahlt

Vor allem — beim Schreiben von Code: wenn das Tool das Projekt kennt und der Agent die erste Überprüfung durchführt, schreibt das Team mehr und besser in der gleichen Zeit. In unserem Fall beschleunigten KI-Tools die Arbeit um etwa 30-40%.

Darüber hinaus hat KI die Einarbeitung neuer Mitarbeiter erleichtert. Wenn ein neuer Mitarbeiter einem Projekt beitritt, muss normalerweise jemand mit Erfahrung Dutzende von Fragen über die Code-Struktur des Projekts beantworten. Jetzt übernimmt der Agent diese Rolle: wenn das Projekt gut dokumentiert ist, richtet der Neue bis zu 95% dieser Fragen an den Agenten und nicht an die Kollegen.

Es ist eine ähnliche Geschichte mit der Dokumentation: ein grober architektonischer Entwurf, der früher Stunden auffraß, wird nun größtenteils vom Agenten selbst geschrieben — nach unseren Schätzungen etwa 80% des Entwurfs, wenn man ihm genügend Kontext gibt. Was dem Menschen bleibt, ist das, was nicht im Repository ist — die Entscheidungen, die Kompromisse, die Expertise.

Genau so wichtig ist es, ehrlich über die Grenzen dessen zu sein, was KI tun kann, denn es sind die überhöhten Erwartungen, die zunächst Enttäuschung erzeugen. KI übernimmt nicht die Einhaltung von Vorschriften — ein Mensch unterzeichnet medizinische oder finanzielle Daten, und das Unternehmen, nicht das Modell, trägt die Verantwortung für einen Datenleck. KI beschleunigt nicht die Integrationen mit Partnern, bei denen Dutzende von Stunden in Anrufen und Koordination investiert werden.

Out-of-the-Box-KI ist tatsächlich ärgerlich — aber nur, wenn sie als fertige Lösung verwendet wird. Der ganze Unterschied zwischen Frustration und Nutzen liegt in dem, was Sie darum herum aufbauen: einen gemeinsamen Standard, den Kontext Ihres Projekts und die neue Rolle des Entwicklers.