AI Coding Discipline — Warum strukturierte Prompts und Contracts wichtig sind
Die KI richtig einrichten
KI-gestütztes Programmieren wirft echte, oft unbeantwortete Fragen auf: Wie werden die KI und ihre einzelnen Agents so konfiguriert, dass alles korrekt funktioniert, ohne bereits vorhandenen Code und vorhandene Logik zu zerstören? Ein Refactoring darf die bereits in der Codebasis vorhandene Struktur niemals brechen.
Was für die KI am wichtigsten ist
- Ein präziser, detaillierter Prompt — je klarer eine Anforderung beschrieben ist, desto besser wird sie umgesetzt.
- Die Arbeit in kleinere, granulare Schritte mit Verifizierung nach jedem einzelnen zu zerlegen, liefert bessere Ergebnisse als ein großer Prompt.
- Halluzinationen verringern — die KI wählt tendenziell die am ähnlichsten klingende Option per Schlüsselwort-Treffer, auch wenn sie nicht zur tatsächlichen Anforderung passt.
- Geschäftslogik und ausdrückliche Einschränkungen, was nicht kaputtgehen darf, in den Prompt einzubetten, liefert bessere Ergebnisse als ein Prompt mit Unit-Tests allein.
- Unit-, Integrations- und End-to-End-Tests dienen dazu zu bestätigen, dass eine bestimmte Änderung keine Funktionalität außerhalb des eigenen Scopes des Tasks gebrochen hat.
Was AITM zusätzlich zu einem Standard-KI-Agent bietet
- Contracts, DOM-Elemente, Verhaltensketten und Beschreibungen der Geschäftslogik, auf die ein gewöhnlicher KI-Agent keinen Zugriff hat.
- Aus Chat oder Brainstorm erzeugte Tasks nutzen Contracts, Dokumentation und verhaltensbezogene Geschäftslogik, um schnell die Teile des Codes zu finden, die sich nicht ändern dürfen, und speisen die relevante Geschäftslogik in den Prompt ein, bevor die KI irgendetwas anfasst — das ergibt einen auf die KI zugeschnittenen Prompt mit minimalen Halluzinationen und der bestmöglichen Umsetzung.
- Prompts erhalten außerdem Skills und spezifische Contracts, sodass ein Task präzise auf vorhandene Coding-Muster und vorhandene Geschäftslogik gelenkt werden kann, was die Passgenauigkeit der Änderung zum bestehenden Code verbessert.
- Jeder Pipeline-Task wird gemäß seinem Anfragetyp — Bug, Enhancement oder Feature — erzeugt und in der Pipeline für jeden Typ unterschiedlich ausgeführt und verifiziert, wodurch die Codequalität durchgehend hoch bleibt.
- Große Anforderungen werden in kleinere, voneinander abhängige Tasks zerlegt, die aufeinander aufbauen; der letzte Task der Kette verifiziert, dass alle korrekt und präzise erstellt wurden.
- Große oder unlogische Änderungen lassen den Task anhalten, sodass ein Mensch (oder ein stärkeres Modell) bestätigen muss, dass die Änderung tatsächlich korrekt ist, bevor es weitergeht.
- Der Schritt Architect sammelt, was sich wo ändern wird, prüft Code-Coverage-Metriken und hält präzise fest, was geschieht — nicht mehr, nichts Spekulatives.