Angenommen, Sie möchten einen Assistenten, der die Fragen Ihrer Kolleginnen und Kollegen zu Reisekosten beantwortet. Sie könnten ihn auf einer Plattform per Klick zusammenstellen, ohne eine einzige Zeile Code. Sie könnten dieselbe Art von Plattform nutzen und ein paar Zeilen Code ergänzen, wo sie an ihre Grenzen stößt. Oder Ihr Entwicklerteam schreibt ihn als ganz normale Software. Alle drei Wege können zu einem funktionierenden Assistenten führen. Sie unterscheiden sich darin, wie schnell Sie starten, wie viel Sie selbst entscheiden und wie schwer es später fällt, den Kurs zu ändern.
Dies ist Teil 4 von Level 0 unseres Lernpfads AI Development. Teil 1 hat drei Wege der KI-Entwicklung beschrieben. Hier sehen wir uns den häufigsten genauer an: ein Produkt auf einem fertigen Modell aufbauen. Sie erfahren, was No-Code, Low-Code und Code bedeuten und wie sich die drei Ansätze bei fünf Kriterien unterscheiden. Außerdem sehen Sie, was Sie mit welchem Ansatz bauen und wann ein Wechsel an der Zeit ist.
Drei Ansätze, ein Beispiel
Bleiben wir beim Reisekosten-Assistenten. Er soll Fragen wie „Darf ich mit dem Taxi zum Flughafen fahren?“ anhand der Reiserichtlinie Ihres Unternehmens beantworten. So sieht der Bau in jedem der drei Ansätze aus.
No-Code heißt: Sie bauen in einem visuellen Editor. Sie klicken, füllen Formulare aus und schreiben Anweisungen in Alltagssprache. Programmcode bekommen Sie nie zu sehen. Für den Assistenten laden Sie die Reiserichtlinie hoch und schreiben eine Anweisung wie „Antworte nur auf Grundlage der Richtlinie“. Dann wählen Sie ein Modell aus einer Liste und testen das Ergebnis in einer Vorschau. Die Plattform betreibt die App für Sie.
Low-Code beginnt ebenfalls in einem visuellen Editor. Wo die fertigen Bausteine enden, ergänzen Sie kleine Stücke Code. Ihr Assistent könnte zum Beispiel mit einem kurzen Skript die aktuellen Erstattungsgrenzen aus Ihrem Finanzsystem abrufen. Meist betreibt weiterhin die Plattform die App.
Mit Code schreibt Ihr Entwicklerteam den Assistenten als normale Software, etwa in Python oder JavaScript. Das Programm schickt jede Frage zusammen mit den passenden Abschnitten der Richtlinie an das Modell. Dafür nutzt es die API des Modells: die Schnittstelle, über die Programme mit dem Modell sprechen. Das Team entscheidet, wo die App läuft, welches Modell sie nutzt und was sie protokolliert.
Diese Arbeitsweise heißt oft Vibe Coding. Unser Artikel VibeCoding: Wie wir Experimente schneller umsetzen zeigt, wo sie uns hilft und wo wir aufhören.
Fünf Kriterien für die Wahl
Keiner der Ansätze ist grundsätzlich der beste. Welcher passt, hängt davon ab, was Sie bauen, wer baut und wie lange die App halten soll. Fünf Kriterien machen die Wahl klarer:
- Tempo: wie schnell Sie eine erste funktionierende Version haben.
- Kontrolle: wie viel Sie selbst entscheiden — von der Oberfläche über das Modell bis zu der Frage, wohin Ihre Daten gehen.
- Änderungsaufwand: wie viel Arbeit eine spätere Änderung macht, etwa eine neue Datenquelle oder ein anderes Modell.
- Skalierung: was passiert, wenn zehn- oder hundertmal so viele Menschen die App nutzen.
- Lock-in: wie schwer es fällt, eine Plattform zu verlassen. Fachleute sprechen von Vendor-Lock-in (Anbieterbindung), wenn ein Wechsel so viel kosten würde, dass Sie lieber bleiben.
Die Tabelle zeigt typische Tendenzen. Einzelne Plattformen weichen davon ab.
| Kriterium | No-Code | Low-Code | Code |
|---|---|---|---|
| Tempo | Schnellster Start, nichts einzurichten | Schnell; Code-Schritte kosten etwas Zeit | Langsamster Start: Einrichtung, Hosting, Tests |
| Kontrolle | Nur, was die Plattform bietet | Mehr: Code füllt die Lücken | Voll: Sie entscheiden jedes Detail |
| Änderungsaufwand | Gering innerhalb der Grenzen der Plattform, hoch darüber hinaus | Mittel; Code-Schritte brauchen jemanden, der programmiert | Jede Änderung braucht jemanden aus der Entwicklung, aber nichts blockiert Sie |
| Skalierung | Grenzen und Preismodell der Plattform geben den Rahmen vor | Wie No-Code, plus Ihre eigenen Dienste | Sie planen selbst: Server, Modellwahl, Kostenkontrolle |
| Lock-in | Hoch: Die App existiert nur auf der Plattform | Mittel bis hoch | Gering für Ihren Code; ein Wechsel des Modellanbieters kostet trotzdem Arbeit |
Tempo und Kontrolle ziehen in entgegengesetzte Richtungen. Die Abbildung ordnet die drei Ansätze auf beiden Achsen ein.
Eine Ecke verdient eine Warnung: langsam und begrenzt zugleich. Dort landen Sie, wenn Sie eine Plattform zu etwas zwingen, wofür sie nicht gebaut ist. Jede Behelfslösung macht die App schwerer verständlich, und jede Änderung dauert länger, als sie in Code dauern würde.
Wer welchen Teil der App liefert
Teil 2 dieses Levels erklärt die sieben Teile, aus denen eine KI-App besteht. Die drei Ansätze unterscheiden sich darin, wer welchen Teil liefert.
Zwei Zeilen sehen in jedem Ansatz gleich aus: Sie schreiben die Anweisungen, und Sie bringen die Daten mit, etwa die Reiserichtlinie. Zusammen mit Ihren Testfragen steckt darin das meiste, was Sie über die Aufgabe gelernt haben. Diese Teile können Sie mitnehmen. Bei der Oberfläche und den Schritten im Backend ist das anders: Auf einer Plattform existieren sie nur in deren Format. Genau diese Teile bauen Sie neu, wenn Sie gehen.
Was Sie mit welchem Ansatz bauen
Die meisten Projekte passen zu einem Ansatz besser als zu den anderen. Diese Beispiele zeigen typische Startpunkte:
| Projekt | Starten mit | Warum |
|---|---|---|
| Assistent, der Fragen der Belegschaft aus einem Handbuch beantwortet | No-Code | Ein Chat über eigene Dokumente ist eine häufige Funktion von No-Code-Plattformen |
| Helfer, der Produkttexte aus einem kurzen Formular entwirft | No-Code | Einfache Eingabe, einfache Ausgabe, ein kleines Team |
| Eingehende E-Mails sortieren und Tickets anlegen | Low-Code oder eine Automatisierungsplattform | Braucht Verbindungen zu Ihrem E-Mail- und Ticketsystem |
| Support-Bot, der den Bestellstatus in Ihrem Shop prüft | Low-Code | Ein kurzer Code-Schritt, der Ihr Shopsystem abfragt, schließt die Lücke |
| KI-Suche in Ihrer eigenen App oder Website | Code | Muss zu Ihrem Produkt passen und für viele Nutzer schnell bleiben |
| Funktion mit strengen Datenregeln, etwa Daten, die auf Ihren Servern bleiben müssen | Code | Sie bestimmen Hosting, Protokolle und die Wahl des Modells |
Unser Tool-Vergleich führt 5 Tools für App-Bau und Tests und 3 für Agenten und Automatisierung. Fünf davon zeigen die Bandbreite. Laut den Anbietern ist MindStudio eine No-Code-Plattform, mit der Sie eigene KI-Agenten bauen. Turbotic baut Automatisierungen aus einer Beschreibung in natürlicher Sprache. Emergent und Devs.ai sind KI-App-Builder. Dry Ground AI ist teils Beratung, teils Produkt: Hier arbeiten Sie mit einem Team, statt allein zu bauen. Wir haben diese Tools nicht getestet.
Kurzbeschreibungen aus unserem Tool-Vergleich, nach Angaben der Anbieter — nicht von ABXK getestet.
Ein Team zu beauftragen, ist ein vierter Weg, wenn ein Projekt Code braucht, aber bei Ihnen niemand programmiert. Stellen Sie dieselben Fragen wie bei den anderen Ansätzen — und eine weitere: Wem gehört die App, und wer ändert sie, wenn das Projekt vorbei ist?
Wann ein Wechsel an der Zeit ist
Viele Projekte durchlaufen die Ansätze, während sie wachsen. Ein No-Code-Prototyp zeigt, ob Menschen die Idee überhaupt nutzen. Ein Pilot bindet sie an Ihre Systeme an. Eine App für viele Nutzer mit strengen Regeln landet oft bei Code.
Diese Signale zeigen, dass es Zeit ist, sich in Richtung Code zu bewegen:
- Die Plattform kann nicht, was Sie brauchen. Eine Datenquelle, ein Modell oder ein Teil der Oberfläche fehlt, und die Behelfslösungen häufen sich.
- Die Kosten wachsen schneller als der Nutzen. Plattformen rechnen unterschiedlich ab, etwa pro Nutzer oder pro Ausführung. Prüfen Sie, was mit der Rechnung passiert, wenn sich die Nutzung verdoppelt.
- Die Datenregeln werden strenger. Ihr Sicherheitsteam verlangt vielleicht, dass Daten in einer bestimmten Region bleiben, oder es braucht genaue Protokolle und Zugriffsrechte.
- Mehrere Menschen ändern die App. Sie brauchen eine Historie jeder Änderung, Reviews und automatische Tests, bevor eine Änderung live geht. Werkzeuge für Code sind genau dafür gebaut.
- Die App wird kritisch. Wenn ein Ausfall die Arbeit vieler Menschen stoppt, brauchen Sie Monitoring und einen Plan B.
Der Wechsel funktioniert auch in die andere Richtung. Verbringt jemand aus der Entwicklung Stunden mit kleinen Textänderungen, die eine Kollegin selbst machen könnte, sind die Anweisungen in einem No-Code-Werkzeug vielleicht besser aufgehoben. Und viele interne Helfer müssen die Plattform nie verlassen.
Level 1 zeigt beide Enden in der Praxis: eine einfache KI-App ohne Code bauen und Ihr erster LLM-API-Aufruf.
Häufige Fehler bei der Wahl
- Nach Gewohnheit wählen. Entwicklungsteams schreiben gern alles in Code. Fachabteilungen reizen eine Plattform gern zu weit aus. Gehen Sie stattdessen von der Aufgabe und den fünf Kriterien aus.
- Zuerst das ganze Produkt bauen. Ein grober Prototyp mit echten Nutzern beantwortet früh die wichtigste Frage: Braucht das überhaupt jemand?
- Die laufenden Kosten vergessen. Modellanbieter rechnen meist pro Token ab, also pro kleinem Stück Text, und Plattformen verlangen eigene Gebühren. Schätzen Sie die Kosten für das Zehnfache der heutigen Nutzung, bevor Sie breit ausrollen.
- Generierten Code für fertig halten. Code aus einem KI-App-Builder braucht weiterhin jemanden, der ihn liest, testet und auf Sicherheitslücken prüft.
- Prototypen ohne Verantwortliche laufen lassen. Sobald ein Helfer wichtig wird, muss jemand seine Dokumente aktuell halten und reagieren, wenn er ausfällt.