Methode · Software mit KI · Open Source
Urazuke, die Nachweis-Methode.
Urazuke (裏付け) ist das japanische Wort für die Rückendeckung, die eine Behauptung hat: das, was sie von hinten trägt. Es ist meine Methode, um Software mit künstlicher Intelligenz zu bauen, die robust und produktionsreif herauskommt, ohne dass der Projekteigentümer eine einzige Zeile Code lesen muss. Ich habe sie aus drei realen Systemen destilliert, die ich heute produktiv betreibe, gestützt auf das Systems Engineering von jeher und auf das, was mir diese Systeme darüber beigebracht haben, wo Modelle es brüchig anwenden.
Autor: Pablo Kuschniroff, unterstützt von Claude Code.
Creative Commons BY-SA 4.0 · Acht Sprachen · Werkzeugneutral · Drei Produktivsysteme als Quelle · Open Source und kollaborativ
Die These
KI unterbricht die Methode nicht: sie setzt sie fort.
Vor der These eine Klarstellung, die mir wichtig ist: Diese Methode ist keine Sammlung von Flicken, die ich nach jedem Rückschlag angebracht hätte. Sie entsteht aus zwei Faktoren zusammen. Der erste ist mein eigenes Wissen über Systems Engineering: Erhebung, Anforderungen, Dimensionierung, Tests als Nachweis, reproduzierbares Deployment, Audit; das bringe ich von lange vor diesen Modellen mit. Der zweite ist das, was mir drei Produktivsysteme Vorfall um Vorfall gezeigt haben: wo Modelle diese Prinzipien brüchig anwenden, und wo man deshalb schriftlich nachziehen muss. Die Narben belegen, wo Strenge nötig ist; sie sind nicht der Ursprung der Prinzipien.
Die Branche hat vor zwanzig Jahren aufgehört, dem Autor des Codes zu vertrauen. Als das Schreiben an Junior-, ausgelagerte oder wechselnde Teams ging, wurde die zeilenweise Prüfung unhaltbar, und an ihrer Stelle wuchs alles, was wir heute für selbstverständlich halten: automatisierte Tests, Continuous Integration, Abnahmekriterien, Pipelines, die ohne Grün nichts durchlassen. Das war die Antwort des Systems Engineering auf „wer schreibt, ist nicht vertrauenswürdig“: seinen Code nicht lesen, Nachweise verlangen. Das Modell ist der nächste Autor, nicht der erste, dem man misstraut.
Wohin die Anstrengung des Menschen geht
Der Mensch tut nur zwei Dinge: entscheiden und Artefakte prüfen. Verfassen, bauen, testen, messen und dokumentieren tut das Modell. Jede Stufe endet in einer Vollständigkeitsprüfung ohne Codelesen.
Der Nachweis beweist sich selbst
Ein Test, den man nie hat scheitern sehen, beweist vielleicht nichts. Ein Messgerät ohne Test lügt. Ein Bericht ohne blinde Flecken verbirgt. Die Unabhängigkeitsdisziplin der Qualitätssicherung, einen Schritt weiter nach innen getragen.
Die Kosten der Artefakte
Früher war Dokumentation teuer und alterte. Jetzt ist ihre Regeneration gratis, also lautet die Regel „im selben Commit“ und „von Hand reproduzierbar, ohne KI“. Was ein unerreichbares Ideal war, wird zum Gate.
Was es ist und was nicht
Systems Engineering, angewandt auf einen Bauenden, der nicht müde wird und dem man nicht glauben kann.
Wer aus dem Systembau kommt, dem klingt es vertraut: Erhebung, Anforderungen, Dimensionierung, Entwurf, Bau, Test, Deployment, Betrieb, Audit. Wer vom Vibecoding kommt, bekommt, was ihm fehlt, nämlich genau das Gerüst.
Was es ist
- Eine Methode: was in welcher Reihenfolge zu tun ist, was man vom Modell verlangt, was es liefern muss, und woran man erkennt, dass es vollständig ist.
- Vierundzwanzig Stufen in vier Abschnitten, jede mit einem Vertrag: Kontext, Prompts, erwartetes Ergebnis, Prüfung, Warnsignale.
- Werkzeugneutral: Claude Code, Cursor, Codex CLI, Gemini CLI oder Forge. Jedes Artefakt ist eine Datei, ein Test oder ein Skript.
- Destilliert aus drei realen Produktivsystemen, jede Regel an den Commit und den Rückschlag gebunden, der sie hervorgebracht hat.
Was es nicht ist
- Ein Programmier- oder Framework-Kurs.
- Eine Sammlung von Prompt-Tricks, damit das Modell besser schreibt.
- Eine Methode für den Prototyp der Freitagsdemo: sie ist für das, was danach weiterlaufen muss.
- Eine Methode, die für jedes Projekt taugt. Stufe 0 zieht die Grenze schriftlich.
Die Leiter
Vierundzwanzig Stufen, vier Abschnitte, in der Reihenfolge, in der man sie steigt.
Die Stufen sind in der chronologischen Reihenfolge nummeriert, in der man sie steigt. Die des Starts einmal pro Projekt; die der Schleife bei jeder Änderung; die der Produktivsetzung einmal, vor dem ersten Deployment; die des Betriebs, wenn das System lebt. Die 23 schließt den Zyklus und kehrt zu 0 zurück. Jede Stufe hat eine achtteilige Karte und einen Vertrag mit den Prompts. Keine Fristen: die Methode ist ein Prozess, kein Geschwindigkeitsversprechen.
Einmal pro Projekt, bevor Funktionalität geschrieben wird
Die fünf, die man am liebsten überspringt und deren Überspringen am teuersten ist.
Bei jeder Änderung, das ganze Projekt hindurch
In der Reihenfolge, in der sie bei jedem offenen Posten gemacht werden. Gelernt an den ersten zwei Blöcken, geübt im ganzen Projekt.
Einmal, vor dem ersten Deployment
Sie machen aus „es funktioniert“ ein „es ist tragfähig“: Audit, Sperren, Pipeline bis Produktion, Beobachtbarkeit, Persistenz, Schwachstellen, Leistung und Handbücher.
Wenn das System schon lebt
Die zwei Überwachungen mit zyklischem Bericht, der residente Agent und die Retrospektive, die den Zyklus schließt und zu 0 zurückkehrt.
Dreizehn Stufen, die in keinem Projekt verhandelbar sind
- Eignung (eine Stunde; spart Monate)
- Zusammenarbeitsvereinbarung
- Kurze Definition, mit „was es NICHT ist“
- Dimensionieren mit Zahlen des Fachbereichs
- Die offenen Punkte als Plan
- Entscheidungen mit Eigentümer und Datum
- Rot gesehene Tests
- Bericht geprüft / geglaubt / blinde Flecken
- Retrospektive mit Zahl
- Abhängigkeiten und Geheimnisse in der Pipeline scannen
- Zentrale Fehlererfassung und Bericht
- Codequalität in der Pipeline, im Minimum
- Manuelle Testfälle, von Menschen ausgeführt
Der Zeitplan
Wann jede Stufe erklommen wird, und was dazwischen passiert.
Eine Methode ohne Zeitlinie ist eine Liste guter Absichten. Das ist die Zeitlinie jedes Projekts: fünf Phasen, in Reihenfolge, und in jeder, was außer den Stufen getan wird: Anforderungsaufnahme, Infrastruktur, Integrations- und Deployment-Pipeline, Entwicklung, End-to-End-Tests, der menschliche Blick, menschliche Tests. Ohne Fristen: jede Phase dauert, was das System verlangt.
Aufnahme
Erhebung mit dem Eigentümer, mit den klassischen Methoden des Requirements Engineering: Interviews, Use Cases, Domänenmodell mit seinen Zuständen, Bildschirmprototypen. In Prosa, absichtlich unvollständig: der Agent vervollständigt sie durch Fragen.
Start (Stufen 0 bis 4)
Eignung, Vereinbarung, Definition mit semantischem Baum, Dimensionierung. Und die gesamte Anfangsinfrastruktur samt CI/CD-Kette: Repository, Testumgebung, Continuous Integration, erstes Deployment mit leerem System. Der Eigentümer öffnet die URL und sieht den leeren Bildschirm.
Schleife (Stufen 5 bis 12)
Fachlicher Block für Block. Mit jedem offenen Punkt: Spezifikation, Entscheidungen, rot gesehener Test, Ende-zu-Ende-Test des Ablaufs, Screenshot, den der Eigentümer ansieht. Zum Abschluss jedes Blocks: die vollständige Ende-zu-Ende-Suite und menschliche Tests in der Testumgebung.
Produktivsetzung (13 bis 20)
Audit durch eine andere Sitzung. Schlösser, bevor gebaut wird, was abbucht oder versendet. Abschluss der Kette in die Produktion mit getestetem Rollback. Die drei Handbücher. Abnahmetests des Eigentümers über alle Abläufe. Dazu die vier Stufen der Betriebsqualität vor dem Deployment: Beobachtbarkeit, Persistenz, Schwachstellen, Leistung.
Betrieb (21 bis 23 und die Schleife)
Residenter Agent im Namen einer Person. Periodisches Audit. Jede Weiterentwicklung geht durch die volle Schleife hinein und über die Deployment-Kette hinaus. Retrospektive mit Zahlen zum Abschluss jeder Etappe. Die beiden Überwachungen, Ressourcen und Fehler, in der Woche des ersten Deployments eingerichtet, mit einem zyklischen Bericht, den der Eigentümer liest.
Ende-zu-Ende-Tests sind nicht einmalig am Ende
Mit jedem offenen Punkt der Ablauf, den er berührt hat. Zum Abschluss jedes Blocks alle Abläufe, die es gibt. Vor der Produktion alle Abläufe mit genau der Version, die befördert wird. Wer nur das Dritte tut, kommt mit wochenlang Ungetestetem am Ende an.
Die drei Anwendungsfälle
Leerer Ordner, System mit Methode, oder geerbtes System: wo man einsteigt.
Die Leiter ist mit Blick auf einen leeren Ordner geschrieben, dem klarsten Fall zum Lernen und nicht dem häufigsten. Bevor du den Agenten öffnest, lohnt es sich zu wissen, in welchem der drei Fälle du bist, denn das ändert, wo man einsteigt. Und der dritte, das System, das schon existiert und nicht mit der Methode geboren wurde, hat einen eigenen Weg: es wird normalisiert, ohne es neu zu schreiben, und erst dann steigt man die Leiter hoch.
Neues Projekt
Ein leerer Ordner und ein Eigentümer mit einem Auftrag. Man steigt bei Stufe 0 ein und geht die vierundzwanzig der Reihe nach hoch: eine Woche Start vor der ersten Funktion. Das beschreiben das Hauptdokument, die Verträge und der Kurs.
Evolutiv-korrektiv mit Methode
Das System ist die Leiter schon hochgestiegen: es hat eine Arbeitsvereinbarung, eine Karte, mit Nachweis geschlossene offene Posten, eine Testbatterie, ein Deployment und Handbücher. Man steigt bei Stufe 5 ein, öffnet einen Block und folgt der Schleife. Es ist die 15, die zur 0 zurückkehrt.
Evolutiv-korrektiv ohne Methode
Ein laufendes System mit Nutzern, von jemand anderem oder von dir selbst ohne Nachweis gebaut. Acht Normalisierungsstationen (N0 bis N7): die Eingaben, die niemand geschrieben hat, per Selbsterkundung zurückgewinnen, mit Quellmarken; ein Sicherheitsgurt als hartes Tor; die Schuld wird bezahlt, sobald ein Modul berührt wird. Danach die Schleife, im korrektiven oder evolutiven Modus.
Den evolutiv-korrektiven Weg lesen → Der Kurs, Teil 2: das geerbte Projekt →
Der Vertrag jeder Stufe
Wie man fragt, was zurückkommen muss, und woran ich erkenne, dass es vollständig zurückkam.
Jede Stufe wird mit einem Vertrag aus fünf Abschnitten ausgeführt. Die Prompts für das Modell sind auf Englisch, ein einziges Stück, identisch in den acht Versionen des Dokuments, und unter jedem die Erklärung in der Sprache des Lesers, was wir verlangen und warum jede Klausel dort steht.
Erforderlicher Kontext
Generisch benannt. Erhebungen sind von Natur aus unvollständig; sie werden nicht mit einem Formular vervollständigt, sondern vom Modell, indem es fragt.
Prompts
Wörtlich. Alle mit derselben Klausel: das Modell bewertet, ob der Kontext reicht, fragt nach dem Fehlenden, bevor es weitergeht, und schätzt oder erfindet keine Angabe, die nur der Fachbereich hat.
Erwartetes Ergebnis
Die detaillierten Merkmale des Artefakts: welche Datei, welche Abschnitte, was nicht fehlen darf.
Vollständigkeitsprüfung
Was der Eigentümer am Artefakt prüft, ohne Code zu lesen. Lautet eine Antwort „nein“, ist die Stufe nicht erklommen.
Warnsignale
Die Symptome, dass die Stufe schlecht erklommen wurde, obwohl sie erklommen scheint. Die man Wochen später sieht, wenn es schon wehtut.
Ein Beispiel-Prompt · Stufe 7
docs/PENDING.md; die bereits umgesetzte Änderung; der Befehl für die Testsuite in docs/STATUS.md; und die laufende Testumgebung mit Daten für den betroffenen Ablauf. In der Dokumentation geht jedem Prompt ein solcher Block voraus: welche Dateien du baust, mit welchem Inhalt, und was der minimal akzeptable Zustand ist.Warum auf Englisch: derselbe Inhalt braucht in einer anderen Sprache 30 bis 50 % mehr Tokens, Modelle folgen Anweisungen auf Englisch präziser, und das Fachvokabular ist englisch. Aber Englisch soll keine Hürde sein: in der Dokumentation bringt jeder Prompt seine Übersetzung in die Sprache des Dokuments mit, samt einem Knopf wie diesem. Dem Modell gibt man das Englische; die Übersetzung ist zum Verstehen da. Alle enden mit „Reply in my language“.
Von der Anforderung zum offenen Punkt
Requirements Engineering wie eh und je, zerlegt in Einheiten, die ein Modell bauen und Sie prüfen können.
Eine Anforderung ist kein Satz des Kunden in einem Chat. Es ist dieser Satz, verarbeitet mit Methoden, die es seit Jahrzehnten gibt und die das Modell sehr gut anwendet, wenn man es verlangt, und sehr schlecht, wenn nicht: Interviews, Use Cases, Domänenmodell, Abnahmekriterien, Bildschirmprototypen, Nachverfolgbarkeit. In der Methode tragen drei Artefakte sie.
Der semantische Baum
Das System als Baum: Domänen; darunter Akteure, Prozesse (die Use Cases), Entitäten mit ihren Zuständen, Bildschirme und Integrationen; und an jedem Knoten hängen die offenen Punkte und die Entscheidungen. Der Agent baut ihn, Sie korrigieren ihn, und er ist das, was der Agent liest, bevor er Code anfasst. Ein offener Punkt, der an keinem Knoten hängt, liegt außerhalb des Umfangs, und das sieht man in zehn Sekunden.
Die detaillierte Spezifikation lebt in jedem offenen Punkt
Das lange Spezifikationsdokument, das alterte, wird zerlegt: jeder offene Punkt trägt seinen Baumknoten, die Ursprungsgeschichte in den Worten des Kunden, die Beschreibung, die Geschäftsregeln mit Entscheidung und Datum, die Daten, die Bildschirme, die Randfälle, die Abnahmekriterien und die Art der Prüfung. Diese Spezifikation zu lesen ist das Nächste am Codelesen, das Sie erreichen werden, und es ist die richtige Distanz.
Geschlossene offene Punkte sind Dokumentation
Ein geschlossener Punkt wird nicht gelöscht: er bleibt mit seiner Spezifikation, der Entscheidung, die ihn ausgelöst hat, dem Nachweis, mit dem er geschlossen wurde, dem Commit und dem Datum. Die Warteschlange der geschlossenen Punkte ist die fachliche Historie des Systems; daraus entstehen das Änderungsprotokoll, das Benutzerhandbuch und die Antwort auf „warum tut das System das“ sechs Monate später.
Mit jedem Werkzeug
Die Artefakte sind Dateien, Tests und Skripte. Was sich ändert, ist, wohin sie gehören.
Claude Code
Vereinbarung und Routinen gehören in die CLAUDE.md des Projekts; die Stufen-Prompts werden beim Erklimmen jeder Stufe in den Chat eingefügt.
Cursor
Die Routinen gehören in .cursor/rules/ als ständig aktive Regeln; der Rest ebenso.
Codex CLI / Gemini CLI
In AGENTS.md oder GEMINI.md im Wurzelverzeichnis des Repositorys.
Yujin Forge
Vereinbarung und Routinen sind Doktrinen, die Prompts werden beim Passieren jedes Gates automatisch injiziert, und das Register der offenen Punkte ist nativ. Dieselbe Methode mit weniger Kopieren und Einfügen. Forge kennenlernen →
Der Kurs
Vierundzwanzig Lektionen mit praktischen Aufgaben, bis zur Anwendung in Produktion.
Ein Handbuch im Kursformat, eine Lektion pro Stufe, um die Methode auf ein eigenes Projekt oder das Leitprojekt anzuwenden („Turnera“, ein Terminbuch mit Erinnerungen, Anzahlungen und personenbezogenen Daten: alles, was nötig ist, damit keine Stufe vorgetäuscht ist). Es endet mit der Produktionscheckliste: vierundzwanzig Bedingungen, die der Eigentümer prüft, ohne den Code zu öffnen. Teil 2 des Kurses nimmt dieselbe Praxis mit einem geerbten System („Turnera, geerbt“) und lehrt, es zu normalisieren, bevor man es korrigiert und weiterentwickelt.
Was Sie verstehen müssen
Das Konzept jeder Stufe, erklärt wie man es einem Menschen erklärt, mit dem realen Fehler, der es hervorgebracht hat.
Die Aufgabe, Schritt für Schritt
Mit dem exakten Prompt für den Agenten und dem, was mit der Antwort zu tun ist. Mit absichtlichen Proben: eine Frage unbeantwortet lassen und sehen, was er tut.
Die Prüfung und das Lieferergebnis
Die Fragen, die Sie sich zum Gelieferten stellen, ohne den Code zu öffnen, und die Datei oder der Nachweis, der am Ende existieren muss.
Typische Fehler und das Leitprojekt
Was fast allen beim ersten Mal passiert, und wie jede Lektion auf Turnera angewandt aussieht.
Für den Einsteiger
Der Junior-Entwickler in der Zeit nach dem Programmieren von Hand.
Wenn das Modell den Code schreibt: Wie lernt ein Junior, was lernt er, und um was zu werden? Ein eigenes Dokument über die Ausbildungsschwerpunkte, die an Gewicht verlieren, die, die gewinnen, die weiterhin verpflichtende Grundbildung, das Ziel und einen Zwölf-Wochen-Plan mit Mentor. Für Anfänger geschrieben, wie die ganze Methode.
Im Team
Mehrere Entwickler, jeder mit seinem Agenten, auf einem gemeinsamen Branch.
Die Methode ist im Singular geschrieben. Dieses Dokument sagt, wie sie gilt, wenn es mehrere sind: die sieben Regeln des gemeinsamen Branches (der offene Posten als Eigentumseinheit, klein und oft integrieren, die Integration als Schiedsrichter, Halbfertiges hinter einem Schalter, die Karte als Konfliktdetektor, Entscheidungen mit Namen, Nachweise statt Code prüfen), wie die Stufen verteilt werden, und die Prompts.
Das gesamte Material, in acht Sprachen
Lesen Sie es in Ihrer Sprache.
Spanisch ist die Quelle der Wahrheit; die anderen sieben Versionen sind Übersetzungen, und bei Abweichungen gilt das Spanische. Die Prompts sind in allen identisch. Drei Dokumente pro Sprache: das Hauptdokument (die These, die Erhebung der drei Systeme, die vierundzwanzig Stufen, die realen Fehler und das Glossar), die vierundzwanzig Verträge und das Kurshandbuch. Und seit Version 5 zwei weitere Dokumente pro Sprache: der evolutiv-korrektive Weg für Systeme, die schon existieren, und Teil 2 des Kurses mit dem geerbten Leitprojekt.
Die Methode erscheint unter Creative Commons Namensnennung-Weitergabe unter gleichen Bedingungen 4.0: sie darf genutzt, übersetzt und angepasst werden, mit Namensnennung und unter gleicher Lizenz. Das Repository ist öffentlich und kollaborativ: github.com/pkuschnirof/urazuke. Verbesserungen kommen per Pull Request aus einem Fork, mit ihrem Nachweis, und ich führe sie nach Prüfung zusammen.
Gibt es das schon unter anderem Namen? Ich habe gründlich recherchiert, was es bis Oktober 2026 an Ähnlichem gibt (Uncle Bob und sein „Gauntlet“, Tsumiki, Spec Kit, Consort, IACDM, Osmani und andere), was man besser zitiert als beansprucht, was ich nirgends gefunden habe, und den ernstesten Einwand mit seiner Antwort. Es steht in Teil F des Hauptdokuments, „Verwandte Arbeiten“.
Zwei Ausführungshandbücher in Forge, Schritt für Schritt mit Screenshots, an echten Übungsprojekten erstellt: neues Projekt (Turnera) und bestehendes Projekt (geerbte Turnera). Mit der auf jeder Stufe gesammelten Evidenz (auf Spanisch).
Zwei weitere Dokumente, außerhalb des übersetzten Korpus: die erklärten Tore, auf Englisch, weil es Werkzeug-Dokumentation ist und aus den Daten erzeugt wird; und die Bewertungen von KI-Modellen zur Methode, auf Spanisch.
Wenn du die Methode mit einem Werkzeug konsumieren willst, musst du das Repository nicht lesen: die Datenschnittstelle liegt unter yujin.app/urazuke/api/. Ihr Index führt jede Ressource mit ihrer kanonischen Adresse, ihrer Version und ihrem Hash auf: gates.json, die mechanische Definition der Tore, und prompts.json, die Prompts. Der Hash wird über den Inhalt neu berechnet, eine veraltete Kopie verrät sich also selbst.
Woher es kommt
Drei Produktivsysteme und sechsundvierzig dokumentierte Fälle mit Datum und Nachweis.
Ich habe nur lesend drei Repositorys erhoben, die heute mit echten Menschen produktiv laufen: das Werkzeug, in dem sich die Methode formte (tausendneunzig Commits in fünf Monaten), ein Automatisierungssystem für eine Gesundheitseinrichtung mit Geld und sensiblen Daten im Spiel (sechshunderteinundvierzig offene Punkte, alle geschlossen), und einen Omnichannel-Empfang für einen zivilen Verein (das erste, in dem die Messung dem Bau systematisch vorausgeht). Jeder Fall, den ich in der Methode zitiere, ist im Referenzdokument nummeriert, damit die Verfahren sauber bleiben und das Detail einen Klick entfernt ist. Die Kunden sind anonymisiert; Zahlen, Daten und Commits sind echt.
Wo das Modell am Offensichtlichen scheitert
Das Messgerät, das zweimal log. Der Authentifizierungsfehler, der als Erfolg gemeldet wurde. Die drei von vier Behauptungen, die falsch waren. Jeder Fall sagte mir, wo ein für mich offensichtliches Prinzip zur expliziten Klausel des Prompts werden musste.
Retrospektive mit Zahlen
Ich habe ein ganzes Agententeam mit sechzig Dollar und dreiundsiebzig Minuten gegen neunzig Minuten beendet. Ich habe das Deployment mit vierundzwanzig bis siebenundzwanzig Minuten gegen elf geteilt. Die Leiter selbst ist genau das.
Pablo Kuschniroff, unterstützt von Claude Code
RPAForce / Yujin. Die Methode wendet sich auf sich selbst an: ihre Entscheidungen sind mit Datum und wörtlichen Worten festgehalten, und das Repository ist seit dem 18. Oktober 2026 öffentlich unter github.com/pkuschnirof/urazuke.
Häufige Fragen
Häufige Fragen.
- Muss ich programmieren können?
- Nein. Sie brauchen einen Fachbereichseigentümer mit Urteilsvermögen und Zeit zum Entscheiden, und Grundbegriffe davon, was ein Repository, ein Commit und ein Push sind. Die Methode existiert genau dafür, dass der Eigentümer Nachweise prüft, statt Code zu lesen.
- Taugt sie für jedes Projekt?
- Nein, und das ist kein Mangel. Es gibt zwei Ausschlussbedingungen: ein Standard-Repository, in dem die Nachweise liegen, und Bildschirme, die sich programmatisch steuern lassen, um Ende-zu-Ende zu testen. Stufe 0 zieht die Grenze schriftlich.
- Brauche ich Forge oder NAC3?
- Nein. Die Methode ist werkzeugneutral; jedes Artefakt ist eine Datei, ein Test oder ein Skript. Forge automatisiert die Gates und die Prompt-Injektion, aber die Stufe existiert ohne Forge. NAC3 ist das Mittel, mit dem wir heute die Bildschirm-Testbarkeit erreichen, keine Bedingung.
- Warum sind die Prompts auf Englisch, wenn die Dokumentation in meiner Sprache ist?
- Weil Modelle Anweisungen auf Englisch präziser und mit weniger Tokens befolgen. Jeder Prompt ist ein einziges, in den acht Versionen identisches Stück, darunter in Ihrer Sprache erklärt, und endet mit „Reply in my language“.
- Wie lange dauert ein kleines Projekt von Anfang bis Ende?
- Ich nenne absichtlich keine Frist. Die Methode ist ein Prozess, um Systeme betreibbar und wartbar zu machen, ohne ein Bit Code zu verstehen; sie ist kein Prozess, um schneller zu bauen, auch wenn Geschwindigkeit als Folge auftaucht. Was die Methode festlegt, sind die Reihenfolge und die Tore; wie lange jede Etappe dauert, bestimmen Größe und Komplexität deines Systems.
- Wie schlage ich eine Verbesserung vor?
- Mit Nachweisen: Stufe 15 verlangt, dass jede Retrospektive in einem konkreten Änderungsvorschlag zur Leiter endet, mit dem Vorfall, der ihn rechtfertigt. Vorschläge kommen per Pull Request aus einem Fork unter github.com/pkuschnirof/urazuke, und ich prüfe sie vor dem Zusammenführen.
Verlangen Sie Nachweise. Lesen Sie seinen Code nicht.
Eine Methode, damit das Modell baut und Sie entscheiden und prüfen. In acht Sprachen, unter offener Lizenz, und mit den Rückschlägen dreier realer Systeme, damit Sie nicht dieselben einstecken müssen.