Für Technik-Teams

KI im Editor zu nutzen ist nicht dasselbe wie mit KI zu bauen.

Code-Vervollständigung macht das Tippen schneller. Der Weg von der Anforderung bis in den Betrieb bleibt derselbe, und die technischen Schulden entstehen einfach zügiger. KI-nativ heisst, dass der ganze Ablauf über ein gemeinsames Wissen läuft und nicht nur der Editor.

Diese Seite beschreibt, wie das funktioniert und was ich Entwicklungsteams davon beibringe. Ich arbeite selbst so; was es in meinem eigenen Betrieb gebracht hat, steht mit Zahlen auf der Belege-Seite.

Der Unterschied

Drei Arten, mit KI Software zu bauen.

Alle drei können schnell sein. Der Unterschied ist, ob das Engineering-Wissen im Ablauf steckt oder in einzelnen Köpfen. Es sind die drei Stufen von der Methode-Seite, auf die Softwareentwicklung angewendet: Vibe Coding steht davor, KI-nativ ist das Ziel.

Vibe Coding

Wer und was: Menschen ohne Entwicklungshintergrund: Gründerinnen und Gründer, Fachleute aus dem Betrieb. Aus einer Beschreibung entsteht lauffähige Software.
Gut für: Ideen prüfen, Prototypen, interne Werkzeuge, Lernen.
Wo es bricht: Alles, was bleiben soll. Architektur, Sicherheit und Wartbarkeit bleiben ungeprüft, wenn niemand sie mitbringt.

KI-unterstützt

Wer und was: Entwicklungsteams mit KI-Werkzeugen im Editor. Einzelne Aufgaben gehen schneller: Vorschläge, Refactoring, Tests.
Gut für: Eingespielte Teams bei bekannten Mustern.
Wo es bricht: Wachstum. Das Wissen bleibt in einzelnen Personen, ein neues Teammitglied erbt nichts davon.

KI-nativ

Wer und was: Entwicklungsteams plus eingerichtete Agenten über alle Phasen. Jede Rolle arbeitet mit demselben Wissen.
Gut für: Software, die zuverlässig, sicher und wartbar bleiben muss.
Wo es bricht: Einmalarbeiten. Die Einrichtung lohnt sich erst, wenn dauerhaft entwickelt wird.

Wie es funktioniert

Ein gemeinsames Wissen, aus dem jede Rolle speist.

Die meisten Teams holen KI über einzelne Werkzeuge ins Haus: ein Assistent im Editor, ein Generator für die Doku. Jedes Werkzeug mit eigenem Kontext, eigenem Gedächtnis, eigenen Grenzen. KI-nativ dreht das um. Es gibt eine gepflegte Wissensbasis, aus der jeder Agent liest und in die er zurückschreibt.

Spezifikationen

Anforderungen, Stories und Akzeptanzkriterien als lebende Dokumente, nicht als PDF im Archiv.

Architektur

Entscheide, Komponenten, Schnittstellen, Datenmodelle. Ein Vorschlag wird gegen den Bestand geprüft, bevor er entsteht.

Regeln

Coding-Standards, Namensgebung, Sicherheitsvorgaben, Qualitätsschranken. Das, was nicht verhandelbar ist.

Anweisungen und Vorlagen

Getestete, versionierte Arbeitsanweisungen statt vager Prompts.

Code

Die echte Codebasis mit ihrer Geschichte. Es wird zum Bestand passend erzeugt, nicht im luftleeren Raum.

Betrieb

Monitoring, Runbooks, Vorfälle, Messwerte. Was das System im Betrieb gelernt hat.

Modelle und Editoren wechseln jedes halbe Jahr. Was bleibt, ist dieses Wissen und die Methodik darüber.

Ein Durchlauf

Von der Anforderung bis in den Betrieb.

Beispiel: «Kunden sollen ihre Rechnungen selbst herunterladen können.» So läuft das durch.

01
Verstehen

Agent
Wertet Rückmeldungen, Tickets und Nutzungsdaten aus und liefert eine Kurzfassung mit Grenzfällen.

Mensch
Prüft, ergänzt, was nicht in den Daten steht, und setzt die Priorität.
02
Festlegen

Agent
Zerlegt in Anforderungen, Akzeptanzkriterien, Datenmodell und Schnittstellen und markiert Abhängigkeiten zum Bestand.

Mensch
Prüft fachlich, ergänzt Kontext aus Gesprächen und gibt frei.
03
Entwerfen und bauen

Agent
Schlägt den Entwurf vor, gleicht ihn gegen die bestehende Architektur ab und schreibt Code samt Tests nach den Mustern des Projekts.

Mensch
Entscheidet die Abwägungen, reviewt, löst das wirklich Neue.
04
Prüfen

Agent
Erzeugt Testfälle aus den Anforderungen, lässt die Suite laufen, prüft gegen die Vorgaben und beginnt die Doku.

Mensch
Bewertet die Ergebnisse und entscheidet, was für dieses Release gut genug ist.
05
Ausliefern und lernen

Agent
Doku, Release Notes und Deploy-Anleitung aus Code und Spezifikation. Danach Monitoring, und alles Gelernte geht zurück ins Wissen.

Mensch
Gibt frei, prüft die Zahlen aus dem Betrieb und schärft nach.

Das ist keine gerade Linie. Im Entwurf lernt man Dinge, die die Anforderung ändern, im Test Dinge, die den Entwurf ändern. Der Unterschied ist, dass diese Schleifen Stunden dauern statt Tage, weil der Kontext nicht bei jedem Schritt neu erklärt werden muss.

Wie lange das dauert, kommt darauf an. Ein klarer Durchlauf in einer eingerichteten Umgebung kann in Tagen fertig sein. In einem regulierten Umfeld mit Altlasten dauert es länger: dieselben Schritte, mehr Tiefe, mehr Review.

Was ich unterrichte

Damit Ihr Team das selbst fährt.

Ich richte das nicht ein und gehe. Die Methodik hält nur, wenn Ihre Leute sie ohne mich führen können. Das sind die Blöcke, die ich dafür unterrichte:

Grundlagen: was ein Sprachmodell tut, wie ein Assistent aufgebaut ist, und warum der Kontext wichtiger ist als das Modell
Entwickeln mit KI-Assistenten, von der Anforderung bis zum Review
Spezifikationen schreiben, mit denen ein Agent tatsächlich arbeiten kann
Die Wissensbasis aufbauen und pflegen: Regeln, Anweisungen, Vorlagen, Architekturentscheide
Dokumentation und Tests, die nicht veralten, weil sie im Ablauf entstehen
Qualitätsschranken setzen, und beurteilen, wann man einen Agenten überstimmt
Wann eine eigene Anwendung sinnvoller ist als ein weiteres Werkzeug

Format und Umfang klären wir im Erstgespräch: von einem einzelnen Tag bis zu einem Programm über mehrere Wochen, meistens begleitend zur echten Arbeit.

Alles zur Schulung und zum KI-Tag

Grenzen

Ehrliche Grenzen.

Sie braucht eine Einrichtung.

Die Wissensbasis auf Ihren Stack, Ihre Standards und Ihre Vorgaben einzurichten kostet Zeit. Bei einem einfachen Projekt Tage, in einem regulierten Umfeld Wochen. Es ist nichts für «morgen loslegen».

Sie verstärkt gutes Engineering, sie ersetzt es nicht.

Routine können Agenten hervorragend. Produktentscheide, Organisationspolitik und das, was im Kundengespräch unausgesprochen bleibt, nicht. Die Erfahrung Ihrer Leute bleibt der Hebel, die Agenten vervielfachen sie.

Sie lohnt sich nicht für Wegwerfarbeit.

Für den schnellen Prototyp, der eine Idee prüfen soll, sind die einfachen Werkzeuge schneller und billiger. Wer nicht pflegen will, soll nicht überbauen.

Ohne Fundament bleibt sie stecken.

Wenn die Abläufe in Tabellen und E-Mails leben und keine dokumentierte Architektur existiert, hat ein Agent nichts, woran er andocken kann. Das wird zuerst geschlossen, sonst beginnt man gar nicht.

Sehen, wie das bei Ihnen aussieht? Das klären wir in 30 Minuten.

Sie zeigen mir Ihr Setup und Ihren Stack, ich sage, wo diese Methodik bei Ihnen den grössten Hebel hat und wo sie nichts bringt.

Kostenloses Erstgespräch vereinbaren 30 Minuten. Kein Verkaufsgespräch.