Oct 02 2026

KI Tools für Softwareentwicklung richtig einordnen

Philipp Deutscher

Arbeitsplatz mit Laptop und technischen Entwürfen als Motiv zur Auswahl von KI Werkzeugen für Softwareentwicklung.

Mit welchem KI Tool sollen wir unsere Software entwickeln? Diese Frage beschäftigt gerade mehrere meiner Kunden. Sie begegnet mir auch auf Konferenzen. Eine Demo zeigt, wie aus einem Prompt eine App entsteht. Die nächste zeigt einen Agenten, der ein Repository bearbeitet. Ein anderer Anbieter verspricht, ganze Arbeitspakete zu übernehmen. Alles sieht nach Softwareentwicklung aus. Für die eigene Entscheidung hilft das zunächst erstaunlich wenig.

Denn im Unternehmen treffen unterschiedliche Situationen aufeinander. Ein Fachbereich will eine Idee ausprobieren. Ein Entwicklungsteam muss ein bestehendes Produkt erweitern. Eine über Jahre gewachsene Anwendung braucht ein Framework-Upgrade. Und irgendwann steht eine Anwendung auf dem Tisch, die jemand außerhalb des Teams bereits gebaut hat. Jetzt soll Engineering übernehmen.

Die passende Lösung hängt deshalb von zwei Fragen ab: Welche Arbeit liegt heute vor uns? Und welche Änderung unserer Arbeitsweise wird durch den nächsten verbindlichen Schritt nötig? Ein Werkzeug kann für den Einstieg sehr gut passen und später ergänzt werden. Ebenso kann ein scheinbar einfacher Builder länger sinnvoll bleiben, als die erste technische Einschätzung vermuten lässt.

Dieser Beitrag ordnet die Landschaft entlang dieser Entscheidungen. Die Produktangaben beruhen auf aktueller Herstellerdokumentation, nicht auf einem eigenen Leistungsvergleich. Die Empfehlungen sind meine fachliche Einordnung. Eine vollständige Liste aller Anbieter wäre schnell veraltet; entscheidend ist, die unterschiedlichen Einsatzschwerpunkte zu verstehen.

Die Landschaft lässt sich nach Arbeitsaufgaben ordnen

Ein Sprachmodell, ein Coding-Agent und eine Plattform für Anwendungen sind verschiedene Bestandteile. Das Modell liefert Fähigkeiten zum Verstehen und Erzeugen von Inhalten. Der Agent verbindet diese mit Werkzeugen und führt Arbeitsschritte aus. Eine Plattform stellt zusätzlich beispielsweise Datenbank, Anmeldung, Vorschau und Veröffentlichung bereit. Orchestrierung koordiniert Arbeit über mehrere Schritte oder Agenten hinweg.

Ein Anbieter kann mehrere dieser Bestandteile liefern. Die folgende Karte zeigt deshalb Schwerpunkte, keine festen Produktklassen und keine Reifestufen.

Neue Anwendungen bauen

Lovable, v0 und Replit gehören zu den relevanten Einstiegspunkten, wenn eine neue Anwendung schnell nutzbar werden soll. Der Vorteil liegt in der engen Verbindung zwischen Beschreibung, Umsetzung und sichtbarem Ergebnis. Die konkrete technische Umgebung unterscheidet sich jedoch erheblich.

Lovable dokumentiert den Export und die bidirektionale Synchronisierung seiner Projekte mit GitHub sowie externe Bereitstellung. Ein beliebiges bestehendes GitHub-Repository lässt sich laut FAQ dagegen nicht in Lovable importieren. Wer bereits Software besitzt, muss diesen Unterschied beachten. [1]

v0 kann Backend-Logik, API-Endpunkte und Datenbankanbindungen erstellen. Seine Full-Stack-Dokumentation nennt Next.js als Standard und bevorzugten Rahmen. Replit dokumentiert einen Agenten innerhalb seiner Entwicklungsplattform. Diese Angebote nur als Generatoren für hübsche Oberflächen zu behandeln, wäre zu kurz gegriffen. [2, 3]

Meine Einordnung: Builder sind interessant für Produktvalidierung und neue Anwendungen, deren Anforderungen zum angebotenen Rahmen passen. Ungeeignet ist die Auswahl allein aufgrund einer überzeugenden Oberflächendemo, wenn die entscheidende Arbeit in einer vorhandenen Codebasis oder einer schwierigen Integration liegt.

In vorhandenen Codebeständen arbeiten

Claude Code, Codex, Cursor und GitHub Copilot bieten agentische Entwicklungsabläufe. Je nach Produkt und Oberfläche bearbeiten sie Dateien, nutzen Entwicklungswerkzeuge oder arbeiten an delegierten Änderungen. Cursor dokumentiert beispielsweise Codeverständnis, Planung, Fehlerbehebung und Review; GitHub beschreibt einen Cloud-Agenten im Repository- und Pull-Request-Kontext. [4–7]

Hier liegt der Einstieg näher an der tatsächlichen Entwicklungsarbeit des Teams. Architektur, Programmiersprache, Testsystem und Veröffentlichungsprozess sind häufig schon vorhanden. Der Agent muss darin sinnvoll handeln können.

Meine Einordnung: Diese Werkzeuge gehören auf die Shortlist für Features, Fehlerbehebung, Tests und Refactoring im bestehenden Produkt. Sie können ebenso neue Anwendungen bauen. Der wichtige Unterschied zum integrierten Builder liegt im konkreten Arbeitsablauf und in der Verantwortung für die Umgebung. Auch mit einem leistungsfähigen Agenten muss jemand wissen, ob eine Änderung fachlich richtig ist.

Größere Arbeitspakete delegieren

Factory und Devin adressieren Entwicklungsarbeit, die über eine einzelne interaktive Änderung hinausgeht. Factory beschreibt für Missions die Zerlegung größerer Projekte, parallele Bearbeitung und Koordination. Devin veröffentlicht Hinweise zur Auswahl geeigneter Aufgaben. Das sind dokumentierte Produktansätze; daraus folgt noch kein belastbarer Produktivitätsgewinn im eigenen Unternehmen. [8, 9]

Auch andere Coding-Agenten erweitern ihre Möglichkeiten zur Delegation. „Wir brauchen mehrere Agenten“ ist deshalb noch kein ausreichender Grund für einen weiteren Anbieter.

Meine Einordnung: Interessant wird diese Kategorie, wenn Aufgaben klar abgrenzbar sind, Ergebnisse geprüft werden können und das Team heute viel Zeit für wiederholte Betreuung oder Koordination aufwendet. Fehlen fachliche Entscheidungen oder müssen mehrere Aufgaben dieselben Komponenten gleichzeitig verändern, kann mehr Parallelität zusätzliche Arbeit erzeugen.

Interne Anwendungen auf Unternehmensdaten entwickeln

Superblocks mit Clark und Retool setzen an Anwendungen und Arbeitsabläufen im Unternehmen an. Superblocks beschreibt Clark als Agenten für interne Apps auf privaten Unternehmensdaten; Retool dokumentiert verschiedene Wege zur Erstellung von Anwendungen. [10, 11]

Bei einem internen Freigabeprozess, einer Supportoberfläche oder einem Verwaltungswerkzeug kann die vorhandene Integration wichtiger sein als maximale Freiheit beim Frontend. Dabei bleibt zu prüfen, welche Rollen, Datenquellen und Sonderfälle das konkrete Angebot abdeckt.

Meine Einordnung: Eine neue Bedienoberfläche auf bestehenden Systemen kann ein guter Einsatzfall sein. Wenn die eigentliche Schwierigkeit in ungeklärten Datenrechten oder widersprüchlichen Geschäftsregeln liegt, muss diese Arbeit trotzdem erledigt werden. „Intern“ bedeutet außerdem nicht automatisch unkritisch.

Entwicklungsumgebungen und Agentenausführung kontrollieren

Coder ist ein Beispiel dafür, wie stark die Kategorien inzwischen überlappen. Die Plattform unterstützt kontrollierte Entwicklungsumgebungen und dokumentiert mit Coder Agents auch eine Chatoberfläche, eine API und einen eigenen selbst betriebenen Coding-Agenten. Sie ist damit nicht bloß eine neutrale Hülle für andere Werkzeuge. [12]

Meine Einordnung: Relevant wird diese Ebene, wenn reproduzierbare Umgebungen, zentrale Zugriffsregeln und der Betrieb vieler Agentensitzungen zum Engpass werden. Ein kleines Team mit einer funktionierenden Umgebung muss daraus nicht sofort ein zusätzliches Plattformprojekt machen. Selbst betriebene Ausführung beantwortet zudem noch nicht, wohin ein angebundener Modellanbieter Daten übermittelt.

Modernisierung wiederholbar ausführen

Bei wiederkehrenden technischen Migrationen gehören auch spezialisierte Werkzeuge in den Vergleich. OpenRewrite stellt Rezepte für konkrete Transformationen bereit, etwa Framework-Upgrades. Moderne ergänzt deren Einsatz über Codebestände hinweg. AWS Transform dokumentiert anpassbare Modernisierungsvorhaben. [13, 14]

Meine Einordnung: Wenn viele Komponenten dieselbe technische Änderung benötigen, kann eine wiederholbare Transformation sinnvoller sein als viele freie Einzelaufträge an einen Agenten. Agenten können bei Analyse und Ausnahmen helfen. Ob das gewünschte Verhalten erhalten bleibt, muss separat nachgewiesen werden.

Der Ausgangspunkt verändert die Auswahl

Greenfield beginnt mit der nächsten verbindlichen Anforderung

Bei einer neuen Anwendung sind viele technische Entscheidungen noch offen. Ein Builder kann hier den Weg zum ersten Nutzertest verkürzen. Das ist ein echter Vorteil, wenn zunächst unklar ist, ob jemand das Produkt überhaupt braucht.

Trotzdem würde ich vor der Auswahl einen Schritt weiterdenken. Braucht der nächste Kunde unterschiedliche Rollen? Muss eine bestehende Datenquelle eingebunden werden? Wird die Anwendung Teil eines verbindlichen Geschäftsprozesses? Die schwierigste bereits bekannte Anforderung gehört in den ersten Versuch. Eine gelungene Startseite beantwortet diese Fragen nicht.

Ein erfahrenes Team kann direkt im Repository mit einem Coding-Agenten beginnen. Das ist sinnvoll, wenn der technische Rahmen ohnehin feststeht oder spezielle Anforderungen früh relevant sind. Eine eigene Multi-Agent-Architektur muss dafür nicht vorausgehen.

Brownfield beginnt mit dem vorhandenen System

Bei einem bestehenden Produkt zählen die tatsächlichen Abhängigkeiten. Ein neues Feature muss zu vorhandenen Schnittstellen, Berechtigungen und Betriebsabläufen passen. Eine Plattform, die lediglich einen neuen Codebestand erzeugen kann, löst eine andere Aufgabe.

Für einen Vergleich würde ich einen reproduzierbaren Fehler und eine kleine Erweiterung mit echter Integration auswählen. Beide Änderungen müssen im normalen Review bestehen. So wird sichtbar, ob das Werkzeug die Arbeit im Unternehmen erleichtert oder vor allem in einer isolierten Demo überzeugt.

Dabei ist Repository-Zugriff nur die erste Voraussetzung. Der Agent braucht eine ausführbare Umgebung und Zugang zu den relevanten fachlichen Regeln. Wo diese Regeln nur in den Köpfen einzelner Mitarbeiter existieren, wird ihre Klärung Teil der Einführung.

Legacy beginnt mit dem Verhalten das erhalten bleiben muss

Legacy ist für diese Entscheidung vor allem Software, deren Änderung durch unbekannte Regeln, Abhängigkeiten oder fehlende Absicherung erschwert wird. Das kann auch eine junge Anwendung betreffen.

Vor einem größeren Refactoring muss deshalb klar sein, was heute tatsächlich passiert. Charakterisierungstests halten dieses Verhalten fest. Fachliche Beispiele helfen, gewollte Regeln von Fehlern zu unterscheiden, die ausdrücklich korrigiert werden sollen.

Ein erfolgreicher Build beweist lediglich einen Teil der technischen Funktionsfähigkeit. Er zeigt nicht, ob eine Abrechnung dieselben Ergebnisse liefert oder eine historisch gewachsene Ausnahme weiterhin behandelt wird. Je schwerer diese Fragen zu beantworten sind, desto kleiner sollten die ersten Änderungsschritte sein.

Übergänge sind eine eigene Entscheidung

Die Auswahl beim Start beantwortet noch nicht, wie ein Vorhaben weitergeführt wird. Gerade bei der Übernahme einer vorhandenen Anwendung lohnt es sich, vier mögliche Änderungen getrennt zu betrachten.

Verantwortung übernehmen: Ein Team übernimmt fachliche Abnahme, Änderungen und Betrieb. Die Plattform kann dabei unverändert bleiben. Auslöser sind beispielsweise verbindliche Nutzungszusagen oder eine betriebliche Abhängigkeit.

Werkzeuge ergänzen: Zusätzliche Tests, ein Review im Repository oder eine andere Arbeitsoberfläche werden nötig. Das Produkt bleibt bestehen. Ein Builder und ein Coding-Agent können Teil desselben Ablaufs sein, sofern Synchronisierung und Zuständigkeiten geklärt sind.

Komponenten oder Betrieb verändern: Eine Integration, ein Backend oder die Hosting-Umgebung genügt einer konkreten Anforderung nicht. Dann kann eine gezielte Herauslösung ausreichen. Ein Wechsel der Autorenwerkzeuge und ein Wechsel der Laufzeitumgebung sind unterschiedliche Vorhaben.

Den Entwicklungsablauf stärker automatisieren: Wiederkehrende Aufgaben werden an Agenten delegiert, später möglicherweise koordiniert. Auslöser sollte ein belegter Engpass im Ablauf sein. Dass eine Anwendung produktiv genutzt wird, begründet für sich allein noch keine umfassende Orchestrierung.

Diese Übergänge können unabhängig voneinander auftreten. Ein Team kann eine Lovable-Anwendung übernehmen und dort weiterarbeiten. Es kann einzelne Änderungen extern umsetzen oder nur eine Integration ersetzen. Umgekehrt kann ein klassisch entwickeltes Produkt früh von delegierten Agentenaufgaben profitieren.

Wann Lovable oder ein anderer Builder nicht mehr genügt

Dafür gibt es keine allgemeine Zahl von Nutzern, Features oder Codezeilen. Eine kleine Anwendung kann hohe Ausfallfolgen haben. Eine größere kann innerhalb einer Plattform gut beherrschbar bleiben.

Ich würde an drei konkreten Situationen prüfen, ob sich das Setup ändern muss. Erstens: Eine notwendige Anforderung lässt sich darin nicht zuverlässig erfüllen. Zweitens: Eine andere Person kann eine typische Änderung nicht nachvollziehbar testen und veröffentlichen. Drittens: Wiederkehrende Workarounds verursachen mehr Aufwand als eine benannte Alternative einschließlich Migration und künftigem Betrieb.

Fehlende Tests sind zunächst eine Lücke im Entwicklungsprozess. Ein fehlender technischer Zugang kann dagegen eine Plattformgrenze sein. Diese Unterscheidung entscheidet darüber, ob das Team seine Arbeitsweise verbessern oder tatsächlich Technik ersetzen sollte.

Ein einfaches Beispiel: Ein Fachbereich hat ein Portal gebaut. Nun benötigt es einen zusätzlichen Kundentyp und eine Anbindung an ein bestehendes System. Das Team sollte genau diese Änderung erproben und fachlich abnehmen. Gelingt sie im vorhandenen Setup nachvollziehbar, gibt es keinen sachlichen Zwang zum Komplettumbau. Scheitert nur die Integration, ist zunächst deren Lösung zu untersuchen.

Die Frage „Dürfen wir mit Lovable bauen?“ würde ich deshalb technisch so beantworten: Ja, wenn der konkrete Einsatz zu seinen Möglichkeiten passt und die nötige Verantwortung organisiert ist. Ob eine Plattform organisatorisch freigegeben ist, muss das Unternehmen anhand seiner Daten, Verträge und Vorgaben separat entscheiden. Eine Herstellerdemo ist weder eine Freigabe noch ein Ausschlussgrund.

Ein agentischer SDLC ist keine Pflicht beim Start

SDLC steht für den Lebenszyklus der Softwareentwicklung, von der Anforderung bis zum Betrieb. Ein agentischer SDLC überträgt Agenten Aufgaben in mehreren Phasen dieses Ablaufs. Wie weit diese Delegation geht, muss ein Team konkret festlegen.

Für eine abgegrenzte Änderung kann ein einzelner Agent mit guten Werkzeugen und klarer Abnahme ausreichen. Zusätzliche Koordination wird interessant, wenn sich Arbeit sinnvoll aufteilen lässt und das Zusammenführen verlässlich geprüft werden kann. Eine selbst gebaute Orchestrierung braucht darüber hinaus einen Betreiber: Jemand muss Unterbrechungen, Wiederholungen, Rechte, Kosten und veralteten Kontext beherrschen.

Wer diese Arbeit unterschätzt, baut neben dem eigentlichen Produkt ein zweites System auf. Das kann sich lohnen, etwa bei besonderen Integrationen oder Freigabeschritten. Es braucht dafür aber eine konkrete Lücke, die vorhandene Funktionen nicht ausreichend schließen.

Vergleiche bis zur akzeptierten Änderung

Für eine belastbare Auswahl würde ich höchstens drei passende Kandidaten an einer repräsentativen Aufgabe vergleichen. Der Versuch beginnt mit der Vorbereitung der Umgebung und endet mit einer unabhängig akzeptierten Änderung. Auch erfolglose Versuche gehören in die Auswertung.

Erfasst werden die Durchlaufzeit, die aktive menschliche Arbeitszeit und die Gesamtkosten. Dazu kommen Review, Nacharbeit und Fehler, die erst nach der Abnahme auffallen. Wiederholt den Versuch mit weiteren Änderungen, damit ein einzelner guter Lauf die Entscheidung nicht dominiert.

Wichtig ist eine gemeinsame Abnahme, keine künstlich identische Bedienung. Ein Builder und ein Repository-Agent werden unterschiedlich geführt. Beide müssen am Ende die Anforderungen erfüllen, für die sie überhaupt infrage kommen. Ein strukturell nicht unterstützter Einstieg wird als nicht passend ausgewiesen; ihn mit Tricks passend zu machen, würde den Vergleich verzerren.

Meine Empfehlung für CTOs: Beschreibe die nächste verbindliche Aufgabe, wähle passende Werkzeuge und benenne schon vor dem Versuch die Bedingungen für eine Ergänzung oder einen Wechsel. So bleibt die Entscheidung überprüfbar, auch wenn sich der Markt weiter verändert.

Wer diesen Vergleich im eigenen Unternehmen aufsetzen möchte, findet im Angebot zur Agentic Engineering Transformation den passenden Einstieg für die Arbeit am konkreten Entwicklungsprozess.

Häufige Fragen zur Auswahl

Können Builder für produktive Anwendungen geeignet sein

Ja. Ob sie im Einzelfall passen, hängt von Anforderungen, Änderbarkeit und Betrieb ab. Produktive Nutzung verlangt einen verantworteten Prozess; daraus folgt kein automatischer Plattformwechsel.

Braucht ein bestehendes Produkt zwingend eine neue Architektur

Nein. Zunächst sollte geprüft werden, welche Änderungen im vorhandenen System sicher möglich sind. Eine neue Architektur braucht eine eigene Begründung und muss ihre Migrationskosten rechtfertigen.

Muss jedes Team mit mehreren Agenten arbeiten

Nein. Zusätzliche Agenten sind sinnvoll, wenn Aufgaben teilbar sind und Koordination einen messbaren Vorteil bringt. Fehlende Anforderungen oder langsame Abnahme werden durch zusätzliche Ausführung allein nicht gelöst.

Quellen und Aktualität

Offizielle Herstellerquellen, geprüft am 1. Oktober 2026. Sie belegen dokumentierte Funktionen und Einschränkungen. Tarif, Freischaltung und konkrete Einsatzfähigkeit sind im jeweiligen Zugang zu prüfen. Produktseiten enthalten auch Anbieterpositionierung; der Artikel übernimmt daraus keine Leistungsversprechen. Die Einordnung ist kein eigener Benchmark.