Technischer Kontext
Ich spreche hier nicht über eine große Veröffentlichung, sondern über eine weitaus nützlichere Nachricht: Bei der praktischen Arbeit mit Opus 4.7 und Codex tritt ein altes Problem erneut zutage. In der Planungsphase klingen sie vernünftig, aber sobald ich beginne, den Diff Zeile für Zeile zu lesen, erscheint die KI-Integration in die Entwicklung plötzlich nicht mehr sicher.
Die Details sind unangenehm. In einem Fall hat ein Modell in einem Projekt mit Domänenmodellen einfach die Domänenschicht umgangen, ein neues Repository erstellt und nach seinen eigenen Regeln gearbeitet. In einem anderen Fall bat ich darum, eine Domänenschicht hinzuzufügen, und erhielt einen Ordner mit einer Repository-Schnittstelle und einem seltsamen Value Object mit einem Array, aber ohne Entity. Formal wurde etwas getan. Architektonisch ist es Müll.
Und hier ist der wichtige Punkt: Ich habe keine externe Bestätigung dafür, dass Opus 4.7 oder Codex systematisch bei DDD als Aufgabenklasse versagen. Es gibt viele Beschwerden über Rauschen, buchstabengetreues Befolgen von Anweisungen, fragwürdige autonome Aktionen und allgemeine Unzuverlässigkeit im Code, aber nicht über dieses spezielle Muster mit Domänenschichten. Daher würde ich dies ehrlich gesagt nicht als nachgewiesene Eigenschaft des Modells bezeichnen, sondern als wiederkehrendes praktisches Risiko, das ich schon jetzt in den Prozess einplanen würde.
Was mich am meisten stört, ist nicht der Fehler selbst, sondern sein Stil. Das Modell sagt nicht: „Ich habe die Architektur nicht verstanden.“ Es baut selbstbewusst eine für sich passende Struktur auf, als ob die Domänenschicht, Invarianten und Aggregatgrenzen nur dekorative Teile des Projekts wären.
Wenn der Plan keine festen Einschränkungen hat, wird es improvisieren. Wenn es Einschränkungen gibt, kann es trotzdem leise einen einfacheren Weg einschlagen. Deshalb betrachte ich gut geschriebene Pläne und Kommentare schon lange nicht mehr als Qualitätssignal.
Auswirkungen auf Geschäft und Automatisierung
Für ein Team bedeutet dies eine einfache Sache: KI-Automatisierung im Code darf nicht ohne Leitplanken in architektonisch sensible Bereiche gelassen werden. CRUD, Tests, Migrationen, routinemäßiges Refactoring – ja. Domänenlogik, Verträge, Invarianten – nicht ohne manuelle Kontrolle.
Diejenigen gewinnen, die über architektonische Checklisten, Regeln für den Agenten und schichtweise Überprüfungen verfügen. Teams, die Qualität an der Generierungsgeschwindigkeit und der Anzahl der geschlossenen Aufgaben messen, verlieren.
Ich betrachte dies bereits als ein Problem der KI-Architektur und nicht nur als eine Modellwahl. Wir benötigen Leitplanken in Prompts, Linter für Architekturverstöße, Verzeichnisvorlagen, Tests für Schichtgrenzen und eine obligatorische menschliche Diff-Überprüfung. Bei Nahornyi AI Lab entwickeln wir genau solche Lösungen für Kunden, die KI-Automatisierung ohne Überraschungen in der Produktion aufbauen müssen.
Wenn Sie feststellen, dass ein Agent die Entwicklung vermeintlich beschleunigt hat, der Code sich aber über die Schichten verteilt, ist es besser, jetzt aufzuhören, als später für eine Neufassung zu bezahlen. Bei Nahornyi AI Lab können wir gemeinsam Ihren Workflow analysieren und eine KI-Lösungsentwicklung so gestalten, dass die Automatisierung Zeit spart, anstatt das System von innen zu zerstören.