Der technische Kontext
Ich habe mir den Vortrag von Matt Pocock nicht nur als Zuschauer angesehen, sondern als jemand, der ständig auf dasselbe Problem stößt: Die KI-Implementierung in der Entwicklung scheitert nicht am Modell, sondern am Prozess. Und genau hier trifft sein Methodenset den Nagel auf den Kopf.
Das Erste, was mir auffiel, war /grill-me vor dem Plan Mode. Im Grunde sehe ich darin keinen „geheimen Prompt“, sondern einen Modus zur rigorosen Überprüfung der Aufgabenstellung. Ich stelle selbst oft fest, dass Code-Assistenten zu schnell zustimmen und dann falsche Annahmen in der weiteren Kette mitschleppen.
/grill-me ist deshalb so gut, weil es die KI zwingt, zu argumentieren, Lücken zu finden, Einschränkungen und Grenzfälle zu klären, bevor sie einen Plan oder Code schreibt. Für die reale Entwicklung ist das günstiger, als später eine schön formatierte, aber fehlerhafte Implementierung aufräumen zu müssen.
Der zweite starke Punkt, bei dem ich fast automatisch nickte, war TDD als absolutes Minimum. Nicht als Ideologie um der Ideologie willen, sondern als Absicherung gegen die Fantasien des Modells. Wenn ich den Assistenten zwinge, das Verhalten zuerst mit einem Test zu formalisieren, „erfindet“ er weniger und hält sich besser an den Vertrag.
Ein weiteres nützliches Muster, das diskutiert wurde, war /domain-model. Der Beschreibung nach klingt das wie eine kurze Zusammenfassung des Domänenmodells mit Wissensakkumulation in CONTEXT.md und ADRs. Mir gefällt dieser Ansatz wegen seiner Zurückhaltung: kein riesiger DDD-Altar, aber eine Fixierung von Entscheidungen, damit der nächste Durchlauf der KI nicht mit Amnesie beginnt.
Und ja, /improve-codebase-architecture würde ich auch nicht als magischen Knopf betrachten. Es ist eher eine Möglichkeit, den Assistenten zu einer Architekturbewertung anzuleiten, aber das Design von Schnittstellen würde ich trotzdem nicht vollständig der Maschine überlassen. Je einfacher die Schnittstelle, desto geringer die Wahrscheinlichkeit, dass das Modell sie zu einem Monster „optimiert“.
Auswirkungen auf Business und Automatisierung
Für Teams ist die praktische Schlussfolgerung hier sehr bodenständig. Es gewinnen diejenigen, die die Automatisierung mit KI um Prüfungen, Tests und expliziten Kontext herum aufbauen. Es verlieren diejenigen, die darum bitten, „es schön zu machen“, und sich dann über unnötige Komplexität wundern.
Der zweite Effekt, den ich bei Kunden sehe, sind Einsparungen bei Nacharbeiten. Wenn das Domänenmodell und Architekturentscheidungen kurz und bündig festgehalten werden, wird die KI-Integration in die Pipeline stabiler: weniger wiederholte Erklärungen, weniger Abweichungen bei Entscheidungen zwischen den Iterationen.
Und die wichtigste Schlussfolgerung scheint mir für Entwickler überhaupt nicht beunruhigend. Nein, das sieht nicht nach „KI wird alle ersetzen“ aus. Es sieht aus wie ein Verstärker für diejenigen, die wissen, wie man den Rahmen vorgibt, und nicht wie ein Ersatz für ingenieurmäßiges Denken.
Wenn Ihr Team bereits Code mit Claude, Cursor oder ähnlichen Werkzeugen schreibt, das Ergebnis aber zwischen exzellent und seltsam schwankt, würde ich genau mit solchen Leitplanken beginnen. Und wenn Sie dies in einen ordentlichen Arbeitsprozess ohne Herumprobieren überführen wollen, helfen wir bei Nahornyi AI Lab dabei, die KI-Automatisierung so zu gestalten, dass das Unternehmen eine vorhersagbare Geschwindigkeit erhält und nicht eine weitere Quelle des Chaos.