KI-Agenten in der Softwareentwicklung: aus dem Werkzeug wird ein Betriebsmodell

Wer in den letzten Monaten viel mit Entwicklungsteams gesprochen hat, weiß es. Agentengestützte Softwareentwicklung ist kein Trend mehr, um den man sich in Ruhe eine Meinung bilden kann. Sie ist da, sie funktioniert, und sie verändert Projekte messbar. Was sich dabei längst nicht so schnell ändert, sind die Anforderungen an einen sauberen Betrieb, an Regulatorik, Zugriffe und Robustheit. Genau dort wird gerade der Unterschied zwischen einem netten Experiment und einer tragfähigen Unternehmenslösung gemacht.

Was gerade wirklich passiert

Bis vor etwa einem Jahr galt: KI-Assistenten helfen an einzelnen Stellen, aber wer sie an ein großes Regelwerk band, sah nach ein paar hundert Zeilen Code das Chaos. Diese Grenze hat sich verschoben. Die neuen Modell-Generationen halten sich zuverlässig an große Guideline-Kataloge, arbeiten über lange Sessions diszipliniert und können komplexe Vorgaben zu Architektur, Testing und Dokumentation umsetzen[1]. Aus dem cleveren Autocomplete ist ein Werkzeug geworden, das mit dem richtigen Setup ganze Feature-Stränge selbstständig durchentwickelt.

Praxisberichte aus mehrmonatigen Experimenten sprechen von Geschwindigkeits-Gewinnen jenseits jeder bisherigen Vorstellung. Ganze Enterprise-Anwendungen mit hunderten User-Stories, vollständigen Test-Suiten und produktionsreifer Dokumentation, entwickelt in Wochen statt Personenjahren. Selbst wenn man diese Zahlen konservativ interpretiert und mehr als die Hälfte abzieht, bleibt eine Neuvermessung der Produktivität übrig, die kein Team ignorieren kann. Der Stack Overflow Developer Survey 2024 zeigt schon vor dem aktuellen Modell-Sprung, dass 76 Prozent der Entwickler KI-Werkzeuge nutzen oder deren Einsatz planen[2].

Die Branche vor dem Umbau

Wo sich das besonders klar zeigt, ist der Markt für branchenspezifische Standard-Software. Custom-ERP-Anbieter, gewachsen über 20 oder 30 Jahre, kommen an der neuen Realität nicht vorbei. Historisch entstandene Monolithe mit riesigen Klassen und tiefen Vererbungsketten sprengen bereits das Kontextfenster moderner Modelle in der reinen Analyse-Phase. Ohne belastbare Test-Suite ist an ein Refactoring nicht zu denken. Währenddessen bauen Zwischenhändler und Endkunden mit kleinen Teams eigene Lösungen. Nicht in gleicher Funktionsbreite, aber oft nach dem Pareto-Prinzip nah genug an dem, was ihre Anwender wirklich brauchen. Die Branche kannibalisiert sich gerade selbst.

Für Mittelständler bedeutet das doppelte Aufmerksamkeit. Einerseits sinkt die Schwelle, eigene Anwendungen für spezifische Prozesse zu bauen. Andererseits wächst der Druck auf bestehende Software-Landschaften, die nicht mit dem neuen Tempo mithalten.

Der Trick liegt nicht im Prompt, sondern im Kontext

Die Ergebnisse, die man in gut aufgesetzten Projekten sieht, entstehen nicht durch ein besonders cleveres Chat-Ping-Pong mit dem Modell. Sie entstehen, weil das Team Zeit in den sogenannten Harness investiert: eine Sammlung strukturierter Dateien, die dem Agenten sagen, wie in diesem Unternehmen entwickelt wird. Architektur-Regeln, Coding-Guidelines, Test-Strukturen, Namens-Konventionen, gekoppelt an statische Analyse-Werkzeuge, die nach jedem Schritt prüfen, ob der Agent im Rahmen geblieben ist. In der Community spricht man von Context Engineering, und die Reifen dieses Konzepts trennt heute die Projekte, die liefern, von denen, die frustriert bleiben[3].

Vier Regeln haben sich in der Praxis herausgeschält:

• Kontext-Dateien nicht automatisch generieren lassen. Das Ergebnis ist meistens oberflächlich und übersieht genau die Vorgaben, die im Alltag greifen. Selbst schreiben und pflegen.
• Sessions kurz halten. Eine Session pro Feature, dann neu starten. Sonst laufen Kontextfenster voll, Modelle komprimieren oder verwerfen Informationen, und die Ergebnisse driften weg.
• Statisch und dynamisch trennen. Der harte Kern (agents.md) wird bei jeder Session geladen. Details wie Architektur- oder Test-Konventionen liegen in separaten Dateien und werden bei Bedarf nachgeladen.
• Kontext nach jedem Feature abgleichen. Neue Muster, neue Konventionen, neue Ausnahmen: alles zurück in die Kontext-Dateien, sonst driften Anwendung und Vorgaben auseinander.

Wo aus Werkzeug ein Betriebsproblem wird

Und hier kommt der Punkt, an dem viele Diskussionen in der Praxis stoppen. Die Tools sind da, die Qualität stimmt, das Team ist begeistert. Dann kommt die IT-Sicherheit vorbei. Dann fragt der Datenschutzbeauftragte, welche Daten in welche Cloud fließen. Dann will die Geschäftsführung wissen, wer haftet, wenn ein Agent produktiv etwas Falsches tut. Dann meldet sich der Betriebsrat wegen der Prompt-Logs. Und plötzlich ist das Werkzeug ein Betriebsthema.

Genau an dieser Stelle setzt conn.AI an. Nicht bei den Coding-Tools selbst, davon gibt es genug am Markt und die Entwicklung dort ist schneller als jeder Beschaffungsprozess. Sondern bei der Betreiber-Schicht darunter. Ein Edge-Server im Haus, ein lokal betriebenes Modell, dokumentierte Zugriffe, protokollierte Nutzung, ein Update- und Konfigurationsprozess, der einen Audit übersteht. Damit werden aus zwei Zeilen KI-Werbung ein System, das man über Jahre betreiben, in Reviews vorzeigen und in einem Vorfall belastbar zurückverfolgen kann.

Für die inhaltlichen Baustellen liefern die zugehörigen Themenseiten die Argumente: die DSGVO-Perspektive auf lokale Verarbeitung, die NIS2-Anforderungen an Nachweisketten, der CRA-Rahmen für Produkte mit digitalen Elementen und der konkrete Umgang mit KI-Assistenten im täglichen Coding-Betrieb.

Wie ein realistischer Einstieg aussieht

Der Weg in agentengestützte Softwareentwicklung führt im Mittelstand nicht über große Strategie-Papiere. Er führt über ein überschaubares Erstprojekt mit einem Team, das die Grundlagen kennt: Architektur, Anforderungen, Test. Wer diese Grundlagen mitbringt, kann in Wochen einen Harness aufbauen, mit dem sich die eigenen Prozesse in KI-taugliche Vorgaben übersetzen lassen. Fehlen die Grundlagen, wird eine KI-Einführung teuer, weil das Ergebnis dann tatsächlich Zufallsprodukt ist.

Parallel entsteht die Frage nach dem Betrieb. Wo laufen die Modelle, wer darf sie nutzen, wie werden Prompts protokolliert, was passiert bei einem Ausfall. Diese Fragen haben nichts mit den Tools zu tun, sondern mit der Infrastruktur darum herum. Wer sie sauber beantwortet, kann die neuen Werkzeuge einsetzen, ohne sich in zwei Jahren mit einem Wildwuchs aus Einzellösungen wiederzufinden.

Kurz zusammengefasst: die Werkzeuge sind erwachsen geworden, der Betrieb ist es noch nicht. Wer beide Seiten zusammenbringt, gewinnt Geschwindigkeit und Kontrolle gleichzeitig. Wer nur auf die Werkzeuge starrt, riskiert das Gegenteil.

Häufige Fragen