Wer hier schreibt

Ich bin seit über 35 Jahren in der IT zuhause. Lange Jahre als Softwareentwickler, danach in vielen weiteren Rollen, bis hinauf in die Geschäftsleitung einer kleinen Softwarefirma. Nach Jahren ohne aktive Entwicklungsarbeit habe ich das Programmieren wiederentdeckt. Diesmal allerdings nicht mehr klassisch, sondern mit KI. Was ich hier beschreibe, ist also nicht theoretisches Wissen, sondern mein gelebter Alltag.

Worum es geht

Über KI im Coding wird viel geredet. Selten konkret. Ich möchte dir deshalb zeigen, wie ich tatsächlich mit KI-Modellen entwickle, nicht als Theorie, sondern als gelebter Prozess, der sich bei mir über Monate eingespielt hat.

Vorweg ein Wort zur Haltung: Ich nutze KI nicht, um schneller Code zu produzieren. Ich nutze sie, um in jedem Schritt bewusster zu entwickeln. Klingt paradox, ist aber der Kern. Wer den Prozess richtig aufzieht, gewinnt nicht nur Geschwindigkeit, sondern auch Klarheit. Und Klarheit ist die Währung, die in komplexen Projekten am meisten zählt.

1. Anforderungsdefinition per Diktat

Ich diktiere dem Modell, was ich umsetzen will. Sprache ist für mich der schnellste Weg, Gedanken zu sortieren. Nebenbei entsteht so direkt eine saubere, dokumentierbare Anforderung.

Das ist kein Detail. Wer einmal versucht hat, eine vage Idee als Tickettext zu schreiben, kennt den Effekt: Die Sprache zwingt zur Präzision. Beim Diktat passiert genau das, nur niederschwelliger. Du redest, das Modell hört zu, und du bekommst eine Formulierung zurück, die du anschließend nur noch schärfen musst.

2. Die KI erstellt einen Plan

Bevor irgendeine Zeile Code entsteht, lasse ich das Modell einen Umsetzungsplan entwerfen. Das ist der wichtigste und am meisten unterschätzte Schritt im ganzen Workflow.

Warum? Weil ein Plan Annahmen sichtbar macht. Die KI denkt sich Sachen aus, über deine Architektur, über Datenstrukturen, über das, was du angeblich willst. Wenn sie direkt loscodet, verstecken sich diese Annahmen im Code, und du findest sie erst, wenn sie schon Schaden angerichtet haben. Im Plan stehen sie schwarz auf weiß. Du kannst sie korrigieren, bevor sie teuer werden.

3. Plan prüfen und in ein GitHub-Issue überführen

Ich gehe den Plan durch, schärfe ihn, und bitte das Modell dann, daraus ein GitHub-Issue zu erzeugen. Damit entsteht automatisch eine saubere Dokumentation. Gleichzeitig habe ich einen Ort, an dem die Anforderung verbindlich liegt.

Das ist nicht Bürokratie um der Bürokratie willen. Das Issue wird gleich noch eine wichtige Rolle spielen.

4. Mein „GO“

Erst wenn ich zufrieden bin, gebe ich das GO. Das ist mein zentraler Kontrollpunkt: Die KI startet nichts, bevor ich es freigegeben habe.

Ich halte diesen Punkt für nicht verhandelbar. Wer das GO automatisiert oder weglässt, gibt die Verantwortung ab. Und Verantwortung lässt sich nicht delegieren, schon gar nicht an ein Modell.

5. Das Issue als verbindliche Quelle

Mein GO bezieht sich immer auf das Issue, nie auf den Chatverlauf. Das ist ein wichtiger Unterschied. Im Chat verschwimmt schnell, was wirklich gemeint war. Das Issue dagegen ist statisch, klar referenzierbar, und ich kann es bis zur letzten Sekunde noch anpassen.

Die Implementierung folgt dann genau dem, was im Issue steht, nicht dem, was im Chat irgendwann mal angedeutet wurde. Wer schon einmal in einer langen Konversation den Überblick verloren hat, weiß, warum das wichtig ist.

6. Lokale Prüfung

Sobald die Implementierung fertig ist, schaue ich sie mir lokal an. Das klingt banal, ist aber der Schritt, an dem ich von der Vogelperspektive in die Detailperspektive wechsle. Hier sehe ich, ob das Konzept aus dem Plan auch in der Realität trägt.

7. Code-Review durch ein zweites Modell

Von Zeit zu Zeit lasse ich den Code zusätzlich von einem zweiten KI-Modell reviewen. Konkret arbeite ich mit Claude Code für die Implementierung (wobei ich je nach Komplexität zwischen Opus und Sonnet wechsle) und ziehe für das Review den OpenAI Codex CLI heran. Das ist mein praktisches Vier-Augen-Prinzip, dem ich weiter unten noch einen eigenen Abschnitt widme.

Schwerwiegende Fehler findet das Review selten. Was aber regelmäßig dabei herauskommt, sind die kleinen Dinge: eine Konvention, die nicht eingehalten wurde. Eine Edge-Case-Behandlung, die fehlt. Ein Namensschema, das inkonsistent ist. Einzeln wäre nichts davon dramatisch. In Summe machen sie aber den Unterschied zwischen „funktioniert“ und „ist gut gemacht“.

8. „Push-Main“

Wenn alles passt, gebe ich die Anweisung: Push-Main. Knapp, klar, eine Aktion.

9. Automatisches Deployment und Pull Request auf Produktion

Der Push auf Main triggert einen Workflow, der die Seite auf meinem Test-Server deployed. Ich mache dort einen finalen Check, diesmal nicht am Code, sondern am laufenden System. Erst danach erstelle ich den Pull Request auf Produktion.

Das Vier-Augen-Prinzip mit zwei Modellen

Ich möchte dem Review noch einen eigenen Abschnitt widmen, weil er für mich das Herzstück dieses Workflows ist und gleichzeitig der Punkt, an dem ich am häufigsten gefragt werde.

Die Idee ist simpel und stammt aus der klassischen Softwareentwicklung: Vier Augen sehen mehr als zwei. Bei mir sind das eben digitale Augen. Ein Modell schreibt, ein anderes prüft. Was nach Spielerei klingt, hat einen handfesten technischen Grund: Unterschiedliche Modelle haben unterschiedliche blinde Flecken.

Ein Modell, das eine Lösung gebaut hat, ist gegenüber dieser Lösung systematisch zu wohlwollend. Es kennt seinen eigenen Gedankengang, hat seine Annahmen verinnerlicht, und wird Lücken in der eigenen Argumentation eher übersehen. Ein zweites Modell kommt ohne diesen Kontext und schaut anders hin. Es liest den Code wie ein fremder Reviewer es täte, der das Issue noch nicht kennt.

In der Praxis bedeutet das: Ich bekomme regelmäßig Hinweise auf Inkonsistenzen, die das implementierende Modell selbst nicht gesehen hätte. Manchmal sind das Konventionen, manchmal Stilfragen, manchmal kleine logische Lücken. Ich übernehme nicht alles, was das Review vorschlägt. Aber jeder Hinweis ist ein Anlass, noch einmal hinzuschauen, und das schärft am Ende den Code.

Wichtig dabei: Das Review ersetzt nicht meinen Blick auf den Code. Es ergänzt ihn. Die finale Bewertung treffe immer ich.

Was diesen Prozess für mich trägt

Wenn du dir diese neun Schritte anschaust, fällt vielleicht auf, dass an mehreren Stellen ich entscheide, nicht die KI. Das ist Absicht.

Die KI macht das, was sie wirklich gut kann: strukturieren, formulieren, implementieren, prüfen. Ich konzentriere mich auf das, was meine Aufgabe ist und bleibt: einordnen, freigeben, verantworten.

Das ist für mich der eigentliche Punkt. Es gibt im Moment viel Aufregung darum, dass KI Entwickler ersetzen wird. Ich sehe es anders. Wer KI als Werkzeug versteht und einen klaren Prozess drumherum baut, wird produktiver, aber nicht ersetzt. Im Gegenteil: Die Rolle wird anspruchsvoller, weil du an jedem Übergabepunkt eine fundierte Entscheidung treffen musst.

Genau das macht den Workflow für mich tragfähig. Nicht die Geschwindigkeit, sondern die Kontrolle. Nicht die Magie, sondern die Klarheit.