Method · software with AI · open source
Urazuke, the evidence method.
Urazuke (裏付け) is the Japanese word for the backing a claim has: what holds it up from behind. It is my method for building software with artificial intelligence that comes out robust and production-ready, without the project owner having to read a single line of code. I distilled it from three real systems I have in production today, leaning on systems engineering as it has always been and on what those systems taught me about where models apply it fragilely.
Author: Pablo Kuschniroff, assisted by Claude Code.
Creative Commons BY-SA 4.0 · Eight languages · Tool-neutral · Three production systems as the source · Open source and collaborative
The thesis
AI does not interrupt the method: it continues it.
Before the thesis, a clarification I care about: this method is not a collection of patches I added after each hard knock. It comes from two factors combined. The first is my own knowledge of systems engineering: survey, requirements, sizing, tests as evidence, reproducible deployment, audit; I brought it from long before these models existed. The second is what three systems in production showed me, incident after incident: where models apply those principles fragilely, and therefore where things must be tightened in writing. The scars prove where rigour is needed; they are not the origin of the principles.
The industry stopped trusting the author of the code twenty years ago. When writing moved to junior, outsourced or rotating teams, line-by-line review became impossible to sustain, and what grew in its place is everything we take for granted today: automated tests, continuous integration, acceptance criteria, pipelines that let nothing through without green. That was systems engineering's answer to "the one who writes cannot be trusted": do not read their code, demand evidence. The model is the next author, not the first untrustworthy one.
Where the human's effort goes
The human does only two things: decides, and verifies artifacts. Drafting, building, testing, measuring and documenting is done by the model. Every step ends in a completeness check without reading code.
Evidence proves itself
A test you never saw fail may prove nothing. A meter without a test lies. A report without blind spots hides. The independence discipline of quality control, taken one step further in.
The cost of artifacts
Documentation used to be expensive and would age. Now regenerating it is free, so the rule becomes "in the same commit" and "reproducible by hand, without AI". What was an unattainable ideal becomes a gate.
What it is and what it is not
Systems engineering applied to a builder that never tires and cannot be believed.
To those coming from systems it sounds familiar: survey, requirements, sizing, design, construction, testing, deployment, operation, audit. To those coming from vibecoding it gives what they lack, which is precisely the skeleton.
What it is
- A method: what to do in what order, what to ask the model, what it must deliver, and how to know it is complete.
- Twenty-four steps in four stretches, each with a contract: context, prompts, expected result, verification, warning signs.
- Tool-neutral: Claude Code, Cursor, Codex CLI, Gemini CLI or Forge. Every artifact is a file, a test or a script.
- Distilled from three real systems in production, with every rule tied to the commit and the hard knock that originated it.
What it is not
- A programming course, or a framework course.
- A collection of prompt tricks to make the model write better.
- A method for Friday's demo prototype: it is for what has to keep working afterwards.
- A method that works for any project. Step 0 defines the boundary in writing.
The ladder
Twenty-four steps, four stretches, in the order they are climbed.
The steps are numbered in the chronological order in which they are climbed. The start-up ones once per project; the loop ones on every change; the going-live ones once, before the first deployment; the operation ones once the system is alive. Step 23 closes the cycle and returns to 0. Every step has an eight-part card and a contract with the prompts. No deadlines: the method is a process, not a promise of speed.
Once per project, before writing functionality
The five most tempting to skip, and the most expensive to skip.
On every change, throughout the project
In the order they happen with every pending item. Learned on the first two blocks and practised through the whole project.
Once, before the first deployment
They turn "it works" into "it can be sustained": audit, locks, the path to production, observability, persistence, vulnerabilities, performance and manuals.
Once the system is alive
The two monitors with a cyclic report, the resident agent and the retrospective that closes the cycle and returns to 0.
Thirteen steps that are not negotiable in any project
- Eligibility (one hour; saves months)
- Working agreement
- Short definition, with "what it is NOT"
- Sizing with the business's numbers
- Pending items as the plan
- Decisions with owner and date
- Tests seen red
- Verified / believed / blind spots report
- Retrospective with numbers
- Dependency and secrets scanning in the pipeline
- Centralized error capture and report
- Code quality in the pipeline, at its minimum
- Manual test cases executed by people
The timeline
When each step is climbed, and what happens in between.
A method without a timeline is a list of good intentions. This is the timeline of any project: five phases, in order, and in each one what is done besides the steps: requirements intake, infrastructure, the integration and deployment pipeline, development, end-to-end tests, the human look, human tests. No deadlines: every phase lasts what the system requires.
Intake
Survey with the owner, using the classical requirements-engineering methods: interviews, use cases, a domain model with its states, screen prototypes. In prose, incomplete on purpose: the agent completes it by asking.
Start-up (steps 0 to 4)
Eligibility, agreement, definition with the semantic tree, sizing. And all the initial infrastructure and the CI/CD chain: repository, test environment, continuous integration, first deployment with the system empty. The owner opens the URL and sees the empty screen.
Loop (steps 5 to 12)
Functional block by block. With every pending item: specification, decisions, test seen red, end-to-end test of the flow, a screenshot the owner looks at. At the close of every block: the full end-to-end suite and human testing in the test environment.
Going live (13 to 20)
Audit by another session. Locks before building anything that charges or sends. Closing the chain to production with a tested rollback. The three manuals. The owner's acceptance tests over every flow. Plus the four operational-quality steps before deployment: observability, persistence, vulnerabilities, performance.
Operation (21 to 23 and the loop)
A resident agent acting on behalf of a person. Periodic audit. Every evolution enters through the full loop and leaves through the deployment chain. Retrospective with numbers at the close of each stage. The two monitors, resources and errors, set up in the week of the first deployment, with a cyclic report the owner reads.
End-to-end tests are not a one-off at the end
With every pending item, the flow it touched. At the close of every block, every flow that exists. Before production, every flow with the exact version to be promoted. If you only do the third, you reach the end with weeks untested.
The three use cases
Empty folder, a system built with the method, or an inherited system: where you enter.
The ladder is written looking at an empty folder, which is the clearest case to learn from and not the most frequent one. Before opening the agent it is worth knowing which of the three cases you are in, because it changes where you enter. And the third one, the system that already exists and was not born with the method, has a path of its own: it is normalized without rewriting, and only then is the ladder climbed.
New project
An empty folder and an owner with a request. You enter at step 0 and climb the twenty-four in order: one week of start-up before the first feature. It is what the main document, the contracts and the course describe.
Evolutive-corrective, with the method
The system already climbed the ladder: it has a working agreement, a map, pending items closed with evidence, a test suite, deployment and manuals. You enter at step 5, opening a block, and follow the loop. It is step 15 returning to 0.
Evolutive-corrective, without the method
A running system with users, built by someone else or by you without evidence. Eight normalization stations (N0 to N7): recover by autodiscovery the inputs nobody wrote, with source tags; a safety belt as a hard gate; debt paid as each module is touched. Then the loop, in corrective or evolutive mode.
Read the evolutive-corrective path → The course, part 2: the inherited project →
Each step's contract
How to ask, what must come back, and how I know it came back complete.
Every step is executed with a five-section contract. The prompts for the model are in English, a single piece identical across the eight versions of the document, and under each one the explanation, in the reader's language, of what we are asking and why every clause is there.
Required context
Named generically. Surveys are incomplete by nature; they are not completed with a form, the model completes them by asking.
Prompts
Verbatim. All with the same clause: the model evaluates whether the context is sufficient, asks for what is missing before going on, and never estimates or invents a figure only the business has.
Expected result
The detailed characteristics of the artifact: which file, which sections, what cannot be missing.
Completeness check
What the owner checks on the artifact without reading code. If one answer is "no", the step is not climbed.
Warning signs
The symptoms that the step was climbed badly even though it looks climbed. The ones seen weeks later, when it already hurts.
An example prompt · step 7
docs/PENDING.md; the change already implemented; the test-suite command in docs/STATUS.md; and the test environment running, with data for the flow being touched. In the documentation, every prompt is preceded by a block like this one: which files you build, with what content, and what the minimum acceptable state is.Why in English: the same content in another language takes 30 to 50 % more tokens, models follow instructions more precisely in English, and the trade's vocabulary is English. But I do not want English to be a barrier: in the documentation every prompt comes with its translation into the document's language and a button like this one. The English is what you paste to the model; the translation is for you to understand it. Every prompt ends with "Reply in my language".
From requirement to pending item
Requirements engineering as it has always been, broken down into units a model can build and you can verify.
A requirement is not a sentence from the client in a chat. It is that sentence processed by methods that have existed for decades and that the model applies very well if you ask and very badly if you do not: interviews, use cases, domain model, acceptance criteria, screen prototypes, traceability. In the method, three artifacts hold them up.
The semantic tree
The system as a tree: domains; beneath them, actors, processes (the use cases), entities with their states, screens and integrations; and from every node hang the pending items and the decisions. The agent builds it, you correct it, and it is what the agent reads before touching code. A pending item that hangs from no node is out of scope, and you see it in ten seconds.
The detailed specification lives in each pending item
The long specification document that used to age gets decomposed: every pending item carries its node of the tree, the originating story in the client's words, the description, the business rules with their decision and date, the data, the screens, the edge cases, the acceptance criteria and how it is verified. Reading that specification is the closest you will get to reading code, and it is the right distance.
Closed pending items are documentation
A closed pending item is not deleted: it stays with its specification, the decision that originated it, the evidence it was closed with, the commit and the date. The queue of closed items is the system's functional history; from it come the changelog, the user manual, and the answer to "why does the system do this" six months later.
With any tool
The artifacts are files, tests and scripts. What changes is where they go.
Claude Code
The agreement and the routines go in the project's CLAUDE.md; the step prompts are pasted into the chat when climbing each step.
Cursor
The routines go in .cursor/rules/ as always-on rules; the rest, the same.
Codex CLI / Gemini CLI
In AGENTS.md or GEMINI.md at the repository root.
Yujin Forge
The agreement and the routines are doctrines, the prompts are injected automatically when crossing each gate, and the pending-items register is native. It is the same method with less copy and paste. Meet Forge →
The course
Twenty-four lessons with hands-on tasks, up to the application in production.
A course-style manual, one lesson per step, to apply the method on your own project or on the guide project ("Turnera", an appointment book with reminders, deposits and personal data: everything needed so that no step is fake). It ends with the production checklist: twenty-four conditions the owner verifies without opening the code. Part 2 of the course takes the same clinic with an inherited system ("Turnera, inherited") and teaches how to normalize it before fixing and evolving it.
What you need to understand
The concept of each step, explained the way you explain it to a person, with the real failure that originated it.
The task, step by step
With the exact prompt for the agent and what to do with what it returns. It includes deliberate tests: leave a question unanswered and see what it does.
The check and the deliverable
The questions you ask yourself about what was delivered, without opening the code, and the file or evidence that must exist at the end.
Typical mistakes and the guide project
What happens to almost everyone the first time, and how each lesson looks applied to Turnera.
For the newcomer
The junior developer in the era after hand programming.
If the model writes the code, how does a junior learn, what do they learn, and to become what? A separate document on the training focuses that lose weight, the ones that gain, the literacy that remains mandatory, the objective, and a twelve-week plan with a mentor. Written for beginners, like the whole method.
As a team
Several developers, each with their own agent, on one shared branch.
The method is written in the singular. This document says how it applies when there are several people: the seven rules of the shared branch (the pending item as the unit of ownership, integrating small and often, continuous integration as the referee, unfinished work behind a switch, the map as a conflict detector, decisions with a name, reviewing evidence and not code), how the steps are shared out, and the prompts.
All the material, in eight languages
Read it in your language.
Spanish is the source of truth; the other seven versions are translations and, if they diverge, Spanish prevails. The prompts are identical in all of them. Three documents per language: the main document (the thesis, the survey of the three systems, the twenty-four steps, the real failures and the glossary), the twenty-four contracts, and the course manual. And since version 5, two more documents per language: the evolutive-corrective path, for systems that already exist, and part 2 of the course with the inherited guide project.
The method is published under Creative Commons Attribution-ShareAlike 4.0: it can be used, translated and adapted, with attribution and under the same licence. The repository is public and collaborative: github.com/pkuschnirof/urazuke. Improvements come in by pull request from a fork, with their evidence, and I merge them after review.
Does this already exist under another name? I researched in depth what is similar up to October 2026 (Uncle Bob and his "gauntlet", Tsumiki, Spec Kit, Consort, IACDM, Osmani and others), what is better cited than claimed, what I found nowhere, and the most serious objection with its answer. It is in Part F of the main document, "Related work".
Two execution manuals in Forge, step by step with screenshots, made on real practice projects: new project (Turnera) and existing project (inherited Turnera). With the evidence collected at every step (Spanish).
Two more documents, outside the translated corpus: the gates explained, in English, because it is tool documentation and it is generated from the data; and the AI model reviews of the method, in Spanish.
If you are going to consume the method with a tool, you do not need to read the repository: the data interface is at yujin.app/urazuke/api/. Its index lists every resource with its canonical address, its version and its hash: gates.json, the mechanical definition of the gates, and prompts.json, the prompts. The hash is recomputed over the content, so a stale copy gives itself away.
Where it comes from
Three systems in production, and forty-six cases documented with date and evidence.
I surveyed, read-only, three repositories that are in production today with real people using them: the tool where the method took shape (one thousand and ninety commits in five months), an automation system for a healthcare entity with money and sensitive data at stake (six hundred and forty-one pending items, all closed), and an omnichannel front desk for a civil association (the first where measurement systematically precedes construction). Every case I cite in the method is numbered in the references document, so that the procedures stay clean and the detail stays one click away. The clients are anonymised; the numbers, dates and commits are real.
Where the model fails to apply the obvious
The meter that lied twice. The authentication error reported as success. The three out of four claims that were wrong. Each one told me where a principle that was obvious to me needed to become an explicit clause of the prompt.
Retrospective with numbers
I killed an entire crew of agents with sixty dollars and seventy-three minutes against ninety minutes. I split the deployment with twenty-four to twenty-seven minutes against eleven. The ladder itself is that.
Pablo Kuschniroff, assisted by Claude Code
RPAForce / Yujin. The method applies to itself: its decisions are recorded with date and verbatim words, and the repository has been public since 18 October 2026 at github.com/pkuschnirof/urazuke.
Frequently asked questions
Frequently asked questions.
- Do I need to know how to program?
- No. You need a domain owner with judgement and time to decide, and minimal notions of what a repository, a commit and a push are. The method exists precisely so that the owner verifies evidence instead of reading code.
- Does it work for any project?
- No, and that is not a flaw. There are two exclusionary conditions: a standard repository to leave the evidence in, and screens that can be driven programmatically to test end to end. Step 0 puts the boundary in writing.
- Do I need Forge or NAC3?
- No. The method is tool-neutral; every artifact is a file, a test or a script. Forge automates the gates and the prompt injection, but the step exists without Forge. NAC3 is the means by which we achieve screen testability today, not a condition.
- Why are the prompts in English when the documentation is in my language?
- Because models follow instructions more precisely and with fewer tokens in English. Each prompt is a single piece identical across the eight versions, explained in your language underneath, and ends with "Reply in my language".
- How long does a small project take end to end?
- I give no deadline, on purpose. The method is a process to make systems operable and maintainable without understanding a bit of code; it is not a process to build systems faster, even if speed shows up as a consequence. What the method fixes is the order and the gates; how long each stage takes is set by the size and complexity of your system.
- How do I propose an improvement?
- With evidence: step 15 asks that every retrospective end in a concrete proposal to change the ladder, with the incident that justifies it. Proposals come in by pull request from a fork at github.com/pkuschnirof/urazuke and I review them before merging.
Demand evidence. Do not read its code.
A method for the model to build and for you to decide and verify. In eight languages, under an open licence, and with the hard knocks of three real systems so you do not have to take the same ones.