Eine Entscheidung in ein ADR oder die versäumte Dokumentation verwandeln
Dokumentation ist die Aufgabe, die Entwickler am liebsten abgeben — Code-Kommentare oder Dokumentation schreiben und aktuelle Codeänderungen zusammenfassen gehören zu den fünf häufigsten KI-Aufgaben, und beim Dokumentieren von Code verlassen sich bereits 31% überwiegend auf KI. Besonders bei Architecture Decision Records: Die Begründung ist frisch im Kopf, aber das Aufschreiben ist die lästige Pflicht, die ausfällt — und der nächste Ingenieur muss rekonstruieren, warum das System so ist, wie es ist.
Sie sind ein Staff Engineer, der präzise technische Dokumentation schreibt. Verwandeln Sie meine Notizen in ein klares {{doc_type}} für andere Ingenieure. Zielgruppe und wo es abgelegt wird: {{audience}} Meine groben Notizen — die Entscheidung, der Kontext und die Trade-offs, die ich abgewogen habe: {{notes}} Verwenden Sie für ein ADR diese Struktur: Titel; Status; Kontext (das Problem und die Randbedingungen); Entscheidung (was wir gewählt haben, klar formuliert); Konsequenzen (Trade-offs, was schwieriger wird, worauf wir uns jetzt festgelegt haben); Betrachtete Alternativen (jeweils mit Begründung für die Ablehnung). Regeln: - Verwenden Sie nur die Fakten, Entscheidungen und Trade-offs aus meinen Notizen. Erfinden Sie keine Benchmarks, Anforderungen, Daten oder Alternativen, die ich nicht erwähnt habe. Wo eine benötigte Angabe klar fehlt, fügen Sie „[TODO: bestätigen]“ ein, statt sie selbst auszufüllen. - Halten Sie es prägnant und überfliegbar — kurze Abschnitte, aktive Sprache, keine Marketingsprache. - Bewahren Sie meine technischen Entscheidungen exakt — Sie schreiben sie auf, Sie treffen sie nicht neu. - Schließen Sie mit einer kurzen Liste offener Fragen, die ein Reviewer klären sollte.
Tragen Sie Ihre Angaben ein — der Prompt aktualisiert sich live. Dann kopieren.
Titel: Postgres Row-Level Security für Mandantenisolation verwenden Status: Vorgeschlagen Kontext: Wir hosten mehrere Mandanten in einer Datenbank. Anwendungsseitige Filterung hat dieses Quartal zu zwei mandantenübergreifenden Datenlecks geführt. Entscheidung: Isolation mit Postgres Row-Level-Security-Policies durchsetzen, die auf tenant_id schlüsseln und pro Verbindung gesetzt werden. Konsequenzen: Starke Garantie auf Datenbankebene; jede Verbindung muss die Mandanten-ID setzen, sonst liefern Queries nichts zurück. Migrationen werden komplexer. [TODO: bestätigen] Performance-Auswirkung unter unserer Last. Betrachtete Alternativen: separate Datenbank pro Mandant — wegen Betriebsaufwand abgelehnt; anwendungsseitige Filterung fortsetzen — nach wiederholten Lecks abgelehnt. Offene Fragen: Kompatibilität mit Connection-Pooler; Rollout-Reihenfolge über Services hinweg.
Der komplette Arbeitsablauf
- Schreiben Sie Entscheidung, Kontext und Trade-offs zuerst als grobe Notizen nieder
- Generieren Sie das ADR oder Dokument und lesen Sie es dann gegen das, was Sie tatsächlich entschieden haben
- Füllen Sie jedes „[TODO: bestätigen]“ mit einem echten Wert und löschen Sie alles, was das Modell eigenständig abgeleitet hat
- Committen Sie das Dokument zusammen mit dem Code, damit es auffindbar und versioniert bleibt
Worauf Sie achten sollten
Das Modell füllt Lücken, indem es Begründungen, Anforderungen oder Alternativen erfindet, die Sie nie in Betracht gezogen haben. Dokumentation ist eine Quelle der Wahrheit, nach der andere Ingenieure handeln — prüfen Sie, dass jede Aussage die tatsächliche Entscheidung widerspiegelt.
Fügen Sie keine vertrauliche Architektur, Sicherheitsdetails oder proprietären Code in ein Consumer-Tool ein. Interne Design-Dokumente sind Geschäftsgeheimnisse; nutzen Sie ein freigegebenes Tool mit deaktiviertem Training.
KI kann eine Entscheidung wiedergeben, aber nicht verantworten. Das technische Urteil in einem ADR liegt bei Ihnen, und ein Reviewer sollte es weiterhin absegnen.
Woher das stammt
Jeder Anwendungsfall auf dieser Website beruht auf echten Berichten, die Softwareentwickler aus der Praxis geteilt haben — nichts davon ist von uns erfunden.