Technischer Kontext
Ich stimme hier voll und ganz der Formel brainstorm → spec → plan → implementation zu. Wenn ich eine KI-Implementierung in der realen Entwicklung durchführe, bitte ich Claude fast nie, das gesamte Feature auf einmal zu schreiben. In diesem Moment versteht das Modell die Grenzen der Aufgabe noch nicht und beginnt, die Architektur für mich zu erfinden.
Zuerst nutze ich es als Kontext-Sammler. Ich gebe das Ziel des Features, Teile der aktuellen Architektur, Einschränkungen, API-Verträge und strittige Punkte ein und bitte darum, dies in komprimierter Form zurückzugeben: was es verstanden hat, was fehlt, wo die Risiken liegen. Allein dieser Schritt bewahrt mich vor der Hälfte aller seltsamen Entscheidungen.
Danach springe ich nicht sofort zum Code. Ich bitte um eine Spezifikation (spec): Was genau ändern wir, was sind die Non-Goals, Akzeptanzkriterien, Edge Cases, welche Module werden betroffen sein. Wenn die Spezifikation schwach aussieht, hilft eine neue Sitzung nicht, denn das Problem ist nicht das Kontextfenster, sondern die Tatsache, dass die Aufgabe noch nicht vollständig zusammengestellt ist.
Anschließend bitte ich darum, die Spezifikation in einen Plan umzuwandeln. Keinen abstrakten Plan auf dem Niveau von „Backend machen, dann Frontend“, sondern eine ordentliche technische Aufschlüsselung: Reihenfolge der Schritte, Abhängigkeiten, Dateien, Tests, Migrationen, Rollback-Risiken. Und erst aus diesem Plan starte ich die Implementierung, normalerweise in kleinen Stücken.
Ich öffne oft eine neue Sitzung, aber nicht magisch, „um Code zu generieren“, sondern um eine saubere Arbeitsphase zu etablieren. In eine neue Sitzung übergebe ich die bereits bereinigte Spezifikation, den Plan und den notwendigen Code-Kontext. Das ist viel besser, als ein langes Hin und Her mitzuschleppen, in dem Ideen, Widerlegungen und Sackgassen vermischt sind.
Delegation funktioniert auch, aber nicht als Ersatz für das Denken. Ich kann Claude bitten, separat Unbekanntes zu sammeln, eine Struktur für die Spezifikation vorzuschlagen oder den Plan auf Lücken zu prüfen. Das heißt, ich delegiere Teilaufgaben, nicht die Verantwortung für die technische Lösung.
Auswirkungen auf Geschäft und Automatisierung
In der Praxis gibt es hier drei Vorteile. Erstens: weniger überflüssiger Code, der später verworfen werden muss. Zweitens: Es ist einfacher, Zeitpläne zu schätzen, da der Plan bereits in reale Schritte unterteilt ist. Drittens: Es ist einfacher, Automatisierung mit KI in einem Team aufzubauen, in dem mehrere Personen und Assistenten an einem Feature arbeiten.
Es gewinnen Teams, die einen teuren Kontext haben: Legacy-Systeme, Integrationen, nicht standardmäßige Logik. Es verlieren diejenigen, die das Modell immer noch bitten, „ein fertiges System zu erstellen“ mit einem einzigen Prompt und sich dann wundern, warum alles bei der Überprüfung auseinanderfällt.
Bei Nahornyi AI Lab löse ich genau solche Aufgaben für Kunden: Ich zerlege eine chaotische Entwicklung in eine überschaubare Pipeline, in der die KI-Automatisierung die Veröffentlichung beschleunigt, anstatt neue Risiken zu schaffen. Wenn Ihre Features im Kontext untergehen, lassen Sie uns Ihren Prozess ansehen und ein KI-Integrationsschema erstellen, das wirklich überflüssige manuelle Arbeit beseitigt.