KI-Agenten in der Softwareentwicklung: Was sich in einem echten Studio ändert und was nicht

Kurz gesagt: Bei LabForty schreiben KI-Coding-Agenten den ersten Entwurf des Codes für klar definierte Aufgaben, öffnen Pull Requests und führen Tests aus. Jede Änderung wird jedoch von Menschen geprüft, und jeder Merge und jedes Release wird von Menschen freigegeben. Architektur, Sicherheit, Freigaben und das Urteil über die Bedürfnisse des Kunden bleiben menschlich. Der Gewinn ist mehr Zeit erfahrener Entwickler für Spezifikationen, Reviews und schwierige Probleme, nicht weniger Schutzmechanismen.

Rund um KI, die Software schreibt, gibt es viel Lärm. Die einen sagen, Entwickler seien überflüssig. Die anderen, Agenten produzierten nur Fehler. Beides deckt sich nicht mit dem, was ich jeden Tag sehe.

Wir setzen KI-Coding-Agenten in echten Kundenprojekten ein. Cloud-Agenten öffnen Pull Requests. Menschen prüfen und mergen sie. Tests laufen auf dev, dann main, dann production. KI-Bots helfen bei der Vorsortierung von Supportanfragen. So funktioniert das in der Praxis, und hier behalten Menschen klar die Kontrolle. Der Beitrag knüpft an unseren früheren Artikel darüber an, wie KI die Website-Entwicklung verändert.

Der Ablauf: Spezifikation, Agent, PR, Tests, Review

Die Arbeitseinheit ist weiterhin eine kleine, klar definierte Aufgabe. Geändert hat sich, wer den ersten Entwurf des Codes schreibt.

1. Spezifikation. Ein Entwickler beschreibt die Aufgabe klar: Ziel, Rahmenbedingungen, betroffene Dateien, Abnahmekriterien und was sich nicht ändern darf. Vage Aufgaben führen zu vagem Code, bei Agenten wie bei Menschen.
2. Agent. Ein Cloud-Coding-Agent arbeitet auf einem eigenen Branch in einer isolierten Umgebung. Er liest die Codebasis, nimmt die Änderung vor, schreibt oder aktualisiert Tests und führt sie aus.
3. Pull Request. Der Agent öffnet einen PR mit einer Beschreibung, was er getan hat und warum. Ohne PR erreicht nichts einen gemeinsamen Branch.
4. Tests. Bei jedem PR laufen automatische Prüfungen: Typprüfungen, Linting, Unit- und Integrationstests sowie Build-Checks. Danach durchläuft die Änderung dev, main und production, mit Tests in jeder Stufe.
5. Review durch einen Menschen. Ein Entwickler liest den Diff, führt ihn bei Bedarf aus, fordert Änderungen an oder lehnt ab. Der Merge ist eine menschliche Entscheidung.

Entwickler tippen weniger Boilerplate und verbringen mehr Zeit mit Spezifikationen, Reviews und den schwierigen Problemen. Die Arbeit verschwindet nicht. Sie verlagert sich.

Was menschlich bleibt

Manche Entscheidungen delegiere ich nicht an einen Agenten, egal wie gut das Modell ist.

Architektur. Wie ein System aufgeteilt wird, wo Daten liegen, welche Dienste miteinander sprechen und wie es skaliert. Ein Agent kann Optionen vorschlagen. Entscheiden muss ein erfahrener Entwickler, der den Kunden, das Budget und die nächsten drei Jahre kennt.

Sicherheit. Authentifizierung, Berechtigungen, der Umgang mit Secrets, Datenschutz und alles, was Zahlungen oder personenbezogene Daten berührt. Hier werden Agenten strenger geprüft, nicht nachsichtiger.

Freigaben. Merges in main, Produktions-Releases, Datenbankmigrationen und alles Unumkehrbare. Eine namentlich benannte Person gibt frei und trägt die Verantwortung.

Urteil über den Kunden. Zu verstehen, was der Kunde wirklich braucht, und das ist oft etwas anderes als das, was im Ticket steht. Das ist ein Gespräch, kein Prompt.

Entwickler sehen diese Aufteilung im Großen und Ganzen genauso. In der Developer Survey 2026 von Stack Overflow gaben 48 % der Befragten an, KI-Ergebnissen zu vertrauen, wenn sie sie leicht überprüfen können, während nur 6,6 % ihnen bei wichtigen beruflichen Entscheidungen vertrauen (Stack Overflow, 2026). Das deckt sich mit meiner Erfahrung: Agenten sind dort stark, wo sich Ergebnisse prüfen lassen, und Menschen verantworten die Entscheidungen, bei denen das nicht geht.

Die echten Risiken

Agentisches Programmieren hat Schwachstellen. Wer so tut, als gäbe es sie nicht, bekommt Probleme.

• Plausibler, aber falscher Code. Er kompiliert, sieht sauber aus und übersieht einen Randfall. Tests und sorgfältige Reviews sind der Schutz.
• Ausufernder Umfang in einem PR. Ein Agent refaktoriert Dateien, die er nicht anfassen sollte. Große Diffs verstecken Probleme.
• Schwache Tests. Ein Agent kann Tests schreiben, die bestehen, weil sie das Falsche prüfen. Reviewer lesen die Tests, nicht nur den grünen Haken.
• Abfließender Kontext. Secrets, Kundendaten oder Zugangsdaten, die in Prompts, Logs oder Tools von Drittanbietern landen.
• Abhängigkeitsrisiko. Neue Pakete, ohne dass jemand Wartung, Lizenz oder Sicherheitshistorie prüft.
• Verlust von Fähigkeiten. Wenn Junior-Entwickler nur noch Agentenergebnisse freigeben, lernen sie nicht mehr, wie Systeme funktionieren.

Leitplanken, die für uns funktionieren

Diese Regeln machen agentische Entwicklung sicher genug für Kundenprojekte.

1. Kleine Aufgaben, kleine PRs. Ein Thema pro PR. Ist ein Diff zu groß für ein ordentliches Review, geht er zurück.
2. Geschützte Branches. Agenten können weder mergen noch deployen noch die Produktionskonfiguration ändern.
3. Tests als Schranke. Fehlgeschlagene Prüfungen blockieren den Merge. Die Abdeckung kritischer Pfade wird von Menschen geprüft.
4. Minimale Rechte. Agenten laufen in isolierten Umgebungen mit genau dem Zugriff, den die Aufgabe braucht. Keine Produktions-Secrets.
5. Stufenweise Freigabe. Dev, dann main, dann production, mit Prüfungen in jeder Stufe und einem klaren Weg zurück.
6. Schriftliche Projektregeln. Coding-Standards, Architekturnotizen und „Nicht anfassen“-Listen liegen im Repository, damit jeder Agentenlauf vom selben Kontext ausgeht.
7. Verantwortung für das Review. Jeder PR hat einen namentlich benannten Reviewer. „Die KI war es“ ist nie eine Erklärung.

Governance hinkt der Nutzung oft hinterher. In derselben Umfrage gaben nur 24 % der Entwickler an, dass ihre Organisation zugelassene KI-Tools oder eine offizielle KI-Richtlinie veröffentlicht (Stack Overflow, Pressemitteilung 2026). Wenn Sie Software bei einem Studio einkaufen, lassen Sie sich dessen Richtlinie zeigen.

Was das für Kunden bedeutet

Für unsere Kunden bedeutet agentisches Programmieren schnellere Iterationen bei klar definierter Arbeit, mehr Zeit erfahrener Entwickler für die entscheidenden Teile und eine bessere Testabdeckung, weil Tests zu schreiben heute günstiger ist.

Es bedeutet nicht, an der Qualität zu sparen. Reviews, Sicherheit und Verantwortung kosten weiterhin echte Entwicklungszeit, und das ist richtig so. Das gilt, ob wir eine Website, eine mobile App oder ein individuelles CRM bauen.

Dasselbe Prinzip gilt für die KI, die wir für Kunden bauen. Unsere individuellen KI-Agenten bereiten Arbeit vor und leiten Ausnahmen weiter, und Ihr Team gibt wichtige Ergebnisse frei, bevor sie weitergehen. Wenn Ihre Daten Ihre Umgebung nicht verlassen dürfen, können wir die Modelle auf Ihren eigenen Servern betreiben.

FAQ

Schreiben KI-Agenten bei LabForty Produktionscode?

Agenten schreiben Entwürfe für klar definierte Aufgaben auf isolierten Branches. Jede Änderung durchläuft einen Pull Request, automatische Tests und ein Review durch einen Entwickler, und Merges und Releases gibt ein Mensch frei.

Werden Kundencode oder Kundendaten an KI-Tools gesendet?

Agenten arbeiten mit minimalen Rechten und ohne Produktions-Secrets. Welche Tools welches Kundenmaterial sehen dürfen, wird pro Projekt vereinbart.

Werden Projekte durch agentisches Programmieren günstiger?

Klar definierte Arbeit wird schneller und Tests werden günstiger. Reviews, Sicherheit und Verantwortung brauchen weiterhin Zeit erfahrener Leute. Der Hauptgewinn sind also Tempo und Qualität bei den richtigen Aufgaben, nicht ein niedrigerer Anspruch.

Was sollte ich ein Studio zu seinem KI-Einsatz fragen?

Wer jede Änderung prüft, wer Releases freigibt, welche Kundendaten in KI-Tools gelangen und ob es eine schriftliche KI-Richtlinie gibt. Konkrete Antworten sind ein gutes Zeichen.

Sprechen Sie mit einem erfahrenen Team

Wenn Sie sehen möchten, wie ein erfahrenes Team KI-gestützte Entwicklung mit klaren Leitplanken umsetzt, von Webplattformen bis zu Fintech-Produkten, senden Sie uns eine kurze Beschreibung. Wir antworten innerhalb von 24 bis 48 Stunden an Werktagen.