Ein Beitrag im GitHub Blog untersucht fünf verbreitete Annahmen über den Einsatz künstlicher Intelligenz in der Softwareentwicklung. Dazu gehört die Annahme, dass generierter Code nicht gelesen werden müsse, dass RAG überholt sei und dass Skills das Model Context Protocol (MCP) abgeschafft hätten. Der Autor ist der Ansicht, dass der Wert dieser Aussagen nicht in ihrer verkürzten Formulierung oder ihrer bloßen Richtigkeit liegt, sondern darin, ihre Voraussetzungen und Grenzen bei der Anwendung auf die tatsächliche Arbeit herauszuarbeiten.
Die Verantwortung für den Code geht nicht auf das Modell über
Die grundlegende Regel des Artikels lautet, dass Entwickler den Code so weit überprüfen müssen, dass sie das Ergebnis erklären und dafür Verantwortung übernehmen können. Das bedeutet nicht, dass jede Zeile mit derselben Tiefe geprüft werden muss; eine Änderung an einem produktiven Authentifizierungssystem verdient eine andere Überprüfung als ein einfaches CSS-Experiment.
Die Überprüfung kann beginnen, bevor der Agent überhaupt Code schreibt, indem die bestehende Implementierung verstanden, Abhängigkeiten und Randfälle ermittelt und ein Plan erstellt werden. In anderen Fällen muss der erzeugte Code unmittelbar auf Fehlerbehandlung, Berechtigungen, Datenzugriff, Leistung, Barrierefreiheit und Tests geprüft werden. Dem Artikel zufolge verändert künstliche Intelligenz den Ort des Aufwands, beseitigt die Arbeit selbst jedoch nicht.
Die wichtigste Fähigkeit ist gutes Urteilsvermögen
Der Beitrag weist die Vorstellung zurück, dass Unternehmen überhaupt niemanden einstellen werden, der künstliche Intelligenz nicht nutzt. Zugleich räumt er ein, dass immer mehr Teams Bewerber fragen, wie sie diese Werkzeuge einsetzen. Das stärkste Signal ist der Darstellung zufolge nicht die Begeisterung für das Werkzeug an sich, sondern die Fähigkeit zu erklären, wann ein Entwickler es nutzt und wann er manuell arbeitet, wie er seine Ausgaben überprüft und wie er zwischen Geschwindigkeit, Qualität, Sicherheit und Wartbarkeit abwägt.
Der Verzicht auf künstliche Intelligenz kann in einem Unternehmen, das entsprechende Produkte entwickelt oder stark auf sie setzt, ein Hindernis sein. Eine vollständige Abhängigkeit davon ist jedoch keine bessere Lösung. Erforderlich ist, den Menschen in der Schleife zu halten und klar erläutern zu können, worauf der Entwickler vertraut und worauf nicht.
MCP, Skills und RAG erfüllen sich ergänzende Aufgaben
Der Artikel unterscheidet zwischen den drei Werkzeugen. MCP bietet eine standardisierte Möglichkeit für Agenten, auf Werkzeuge und Daten zuzugreifen und sie aufzurufen, während Skills gebündeltes Wissen über die Arbeitsweise des Teams, Regeln zur Änderung des Projekts oder die geltenden Konventionen bereitstellen. Da Skills meist im Markdown-Format verfasst werden, ist ihre Lesbarkeit für Menschen ein Teil ihres Nutzens.
RAG, also die durch Retrieval erweiterte Generierung, bringt relevante Informationen außerhalb der Trainingsdaten des Modells in das System ein, etwa Dokumentation, Supportverläufe, Produktdetails, internes Wissen und den Kontext der Codebasis. Guter Informationsabruf hilft dem Modell, seine Arbeit mit einem Kontext zu beginnen, der der Antwort näher ist, und verringert dabei den Suchraum sowie die Wahrscheinlichkeit einer unvollständigen Antwort.
Deshalb ist der Autor nicht der Ansicht, dass Skills MCP getötet hätten oder RAG tot sei. Ein Agent kann MCP verwenden, um auf ein Werkzeug zuzugreifen, einer Skill folgen, um projektspezifische Anweisungen anzuwenden, und Informationsabruf nutzen, um den unterstützenden Kontext zu laden. Der Gegensatz zwischen diesen Komponenten ignoriert die Möglichkeit, dass sie sich in einem einzigen Arbeitsablauf ergänzen.
Wartbarkeit unter einem neuen Test
Der Beitrag erörtert auch die Vorstellung, dass die Notwendigkeit, ein Modell auf eine bestimmte Codebasis zu trainieren, zwangsläufig bedeutet, dass der Code schlecht ist. Es gibt legitime Gründe für benutzerdefiniertes Training. Die Unfähigkeit des Modells, die Codebasis zu verstehen, kann jedoch ein Problem aufdecken, mit dem auch ein neuer Kollege konfrontiert wäre.
Eine klare Struktur, konsistente Benennung, verständliche Tests, nützliche Abstraktionen und aktuelle Dokumentation machen Code sowohl für Agenten als auch für Menschen leichter verständlich. Die redaktionelle Schlussfolgerung lautet hier, dass KI-Werkzeuge Teams nicht von Praktiken der Softwareentwicklung entbinden. Vielmehr können sie Mängel bei der Wartbarkeit deutlicher sichtbar machen.
Von der Debatte zum Experiment
Der Artikel schließt mit der Aufforderung, Ansichten praktisch zu testen, anstatt jede Ansicht einfach durch eine Gegenansicht zu ersetzen. Er verweist auf das Projekt Pollinations AI, bei dem Mitwirkende durch die Verbesserung des Projekts Credits namens pollen verdienen können, sowie auf das Projekt Avian Visitors. Dieses dokumentiert ein E-Ink-Display, das Vögeln zuhört und ihre Besuche mithilfe eines Mikrofons, eines Raspberry Pi, dreidimensional gedruckter Komponenten und generierter Bilder in wechselnde Darstellungen umwandelt.
Diese Projekte entscheiden nicht jede Debatte über künstliche Intelligenz, liefern jedoch Belege und machen Zielkonflikte sichtbar. Die grundlegende Einschränkung des Materials besteht darin, dass es einen allgemeinen Leitfaden und Beispiele bietet, jedoch keine vergleichenden Messergebnisse, die die Überlegenheit eines bestimmten Arbeitsablaufs belegen. Daher sollten seine Empfehlungen als Prüfsteine für die Praxis und nicht als endgültige Regeln verstanden werden.