Research-Driven Development

Build software you understand. AI in the loop — not human in the loop.

"It matters what stories we tell to tell other stories with; it matters what thoughts think thoughts."
— Donna Haraway, Staying with the Trouble

"You cannot create results. You can only create conditions in which something might happen."
— Anne Bogart, A Director Prepares

"Problem setting is a process in which, interactively, we name the things to which we will attend and frame the context in which we will attend to them."
— Donald Schon, The Reflective Practitioner

If you tell the story of nature through competition and survival of the fittest, you get one set of possible questions — optimization, dominance, scarcity. If you tell it through symbiosis and entanglement, you get entirely different questions. The framing isn't neutral. It determines what thoughts are even available to you. Software works the same way: start from a delivery story and you get delivery questions. Start from research — from genuine inquiry into the problem space — and different questions emerge. Probably a different system too.

None of the ideas in RDD are new. Research before building, name things precisely, question your assumptions, write about what you learned — people have been doing this for as long as there have been hard problems. BDD and TDD are decades old. Reflective practice, domain modeling, architectural decision records — all established. RDD also draws from places software methodology usually doesn't look: devised theater (discovery through structural experimentation), OuLiPo (formal constraint generates content), Value Sensitive Design (stakeholder mapping that holds tensions rather than resolving them), and curatorial practice (meaning through selection, juxtaposition, and the spaces between).

What's new is the need to say it out loud. Research before building, understand before shipping — it sounds obvious, like reminding yourself to put one foot in front of the other. But AI has a short-circuiting effect: it makes the output so easy that the thinking becomes optional — and optional thinking tends toward no thinking. RDD rewires for intentional work. AI changed what's easy and what's hard. Generation is now trivial — essays, code, architecture, all produced in seconds. AI is a powerful tool for understanding code — but the forcing function that used to produce understanding (doing the tedious work yourself) has been removed, and the volume of plausible output you can produce without understanding has exploded. If it's not worth reading, it's not worth writing — and AI makes it trivially easy to produce plausible-sounding text that doesn't hold up under scrutiny. Good writing serves many audiences — colleagues, future you, even AI agents bootstrapping into a project — but text for its own sake is waste. A provenance chain from module to decision to research finding matters because no one reliably carries that chain in their head when AI generated the architecture. RDD exists because of this shift: it enshrines a process around the generation — using AI for what AI is good at while structuring the practices that produce the understanding. It wraps BDD and TDD in a research layer that changes what you build — not just how you build it.

Most AI-assisted development is "human in the loop" — the AI does the work, the human checks it. RDD inverts this: it is AI in the loop. The human builds understanding; the AI is in their loop — generating, fetching, synthesizing, checking, all in service of the human's journey. The reverse centaur problem (where the human rubber-stamps AI output at AI speed) only exists when the AI is the primary actor. In RDD, the human is primary. The "research" in the name is not just upfront investigation — it is the ongoing practice of reflecting on what was built, looping back when understanding shifts, and capturing what the practitioner thinks. Research-driven development is also reflection-driven development.

RDD is slow on purpose. It's a mindful process of making — a counter-practice to the scattered exhaustion of constant AI generation, context switching, and the productivity loop that produces output without understanding. When you investigate a problem before committing to a solution, you discover that the problem isn't what you assumed — stakeholders you hadn't considered reshape the requirements, assumptions you'd never questioned turn out to be wrong. The system you build after research is a different system than the one you would have built without it. This is thinking as craft — and as AI coding becomes the norm, it's the process that matters. Code is cheap. Software is fast becoming a commodity. What's scarce is knowing what to build and why. The ideas are the hard part now, and ideas come from figuring out how to ask the right questions. The right questions rarely arrive as flashes of insight — they emerge from the process of investigating, writing, and placing findings next to each other until the gaps become visible. Research, writing, and structured reflection are how you learn what to ask. That's what RDD protects. And honestly — researching and understanding what you're working on is fun and good for your brain.

The Pipeline

RDD moves through phases. Each phase produces an artifact and ends with reflection time — an invitation to inquiry. Not a quiz, not a conversation for its own sake, but a deliberate pause to ask: what kind of engagement would deepen understanding right now? The form adapts — but producing something is non-negotiable. Sometimes that means explaining what was built in your own words. Sometimes it means challenging the choices that were made. Sometimes a colleague, a facilitator, or anyone with a different perspective helps you see what you missed — even an LLM in the right setting — teaching you something you didn't know you needed to understand. The goal is not to test understanding but to build it. These moments of genuine inquiry are where learning happens — grounded in research on the generation effect (Slamecka & Graf), desirable difficulties (Bjork), and reflective practice (Schon). The research essays trace the full evidence base.

1. Research — Investigate the problem space. Read the literature, run spikes, search for prior art. Produce a written account of what you found — an essay, a report, whatever form suits the material. Writing is the forcing function: if you can't explain it clearly in prose, you don't understand it yet. The research often reframes the problem in ways that change what you'd build. Ask yourself: What surprised you? What do you understand differently now than when you started?
2. Discover — Surface who this is for, what they need, and what you're assuming. Donna Haraway calls it "staying with the trouble" — sitting with value tensions rather than resolving them prematurely. The inversion principle is central here: for every major assumption, state its opposite and take it seriously. The assumptions you never question are the ones that become the most expensive architecture mistakes. Ask yourself: Who is this actually for, and which assumption are you most nervous about?
3. Model — Name things precisely. Extract the vocabulary of concepts, actions, relationships, and invariants that the system must respect. Ask yourself: What did naming things precisely reveal that was hidden before?
4. Decide — Make architectural decisions, write refutable behavior scenarios, and produce interaction specifications — how each stakeholder actually works with the system. Each decision traces to research; each scenario is testable. Ask yourself: Why this approach and not the alternatives? What would change your mind?
5. Architect — Decompose the system into modules. Every boundary should answer the question: why here and not somewhere else? Provenance chains should link each design choice back through a decision to a research finding to a user need. If you can't follow the chain, the boundary may be arbitrary. Ask yourself: Pick a module boundary — what user need does it trace back to?
6. Build — Scenarios become tests. Tests become software. BDD and TDD. At natural boundaries — when you finish a feature or cross a component line — pause for a stewardship check: is the code landing where the architecture says it should? Are responsibilities drifting? Is coupling growing in ways the design didn't anticipate? Catching anti-patterns here is cheap. Discovering them three months later is not. Ask yourself: Is what you're building still conforming to what you designed — and if not, which one needs to change?
7. Play — Now play with it. Like a game you've never played — pick a user you've never been, step into their world, and just go. Ask the magic "what if": what if I didn't care about the main feature at all and just wanted to do this other thing? What if I ignored the instructions entirely? What if I'm in a rush and have no patience for this? Nothing is at stake — play is consequence-free, and that's what makes it generative. You run into challenges and figure out what to do, in a space where it's safe to be wrong. You'll discover what no spec could have told you: the moment that delights, the wall that frustrates, the path users actually take instead of the one you designed. Ask yourself: What did the system show you that you couldn't have predicted?
8. Synthesize — Play and synthesis are the profoundly human steps. Don't let your discoveries die in the artifacts that produced them. Make something from what you learned — write about it, present it, teach it. Laurel Richardson called writing "a method of inquiry": you write to find out what you think, not to report what you already know. Try unexpected forms to see what they uncover — a hermit crab essay that borrows the shell of another genre, an arrangement where meaning emerges from juxtaposition, a structure inspired by Cage's indeterminacy where elements have relationships but no fixed sequence. The odd forms aren't affectation — they're experiments designed to surface what conventional structure conceals. Sometimes the act of synthesis surfaces new questions the pipeline hasn't addressed — when that happens, loop back into research. Understanding generates new questions. Ask yourself: What was the real discovery — the thing you didn't expect when you started?
9. Graduate — Fold the durable knowledge — architectural decisions, domain vocabulary, product context, key rationale — into your project's native documentation. Archive the RDD artifacts. The scaffolding has done its job; the understanding lives in you and in the project's own docs now. RDD comes down until the next problem warrants it. Ask yourself: Can you explain this system to someone new without reaching for the RDD artifacts?

Core Principles

This is a heavy process — but it's what you might do anyway for a hard problem that matters: research, name things, question assumptions, design carefully, test, reflect. AI can help speed up the parts it's good at while still allowing you to reap the understanding — if you follow these principles.

1. Research before architecture. The system you build after investigating a problem is different from the one you'd build on assumptions. RDD is grounded in what research finds, not what you assumed going in.
2. Understanding requires human generation, not review. At each phase transition, produce something — an explanation, prediction, or articulation — rather than merely assessing an output. That's where learning happens.
3. Assumptions are inverted before they harden. Every major product assumption gets systematically questioned — "what if this were wrong?" — before it's encoded in architecture.
4. Provenance links design to research. Every module, every responsibility allocation, every architectural decision traces back to a research finding or a user need. When someone asks "why is it this way?", you can follow the chain.
5. Understanding compounds. What you articulate after research enriches domain modeling; your modeling insights sharpen architectural decisions. Each reflection builds on the last. The quality effect is cumulative — and it's the difference between software you own and software that owns you.
6. Reflection should be productive, not merely brief. The constraint is on waste — formulaic exchanges that build nothing — not on duration. When a pause for reflection turns into a genuine teaching moment or a challenging conversation that deepens understanding, that's the methodology working. When it's a box to check, that's the methodology failing. The time spent should be earned.
7. The scaffolding fades. RDD is a deep work tool you reach for when a problem warrants it and put away when the knowledge has been absorbed. The project's native documentation is the permanent home; RDD artifacts are the working space.

These principles emerged from personal experience across research settings, devised theater, and writing — domains where discovery feels good because it's yours. When you steer the generative process intentionally, the understanding that emerges belongs to you. That's the sense of ownership RDD is after, and the research backs it up. The framework itself is an experiment in this. The developer who understands why a boundary exists — who can trace a module back through a decision to a research finding to a user need — produces software they can explain, defend, and extend.

The Test

After completing an RDD cycle, you should be able to explain the system's design rationale, key decisions, domain vocabulary, and the user needs those decisions serve — without assistance. Not because you memorized the output, but because you shaped the process and the result. If you can do this, the methodology worked. If you can't, it failed — regardless of whether the software runs.

When to Use It — and When to Stop

RDD is for the problems that reward depth: unfamiliar domains, ambiguous requirements, expensive-to-reverse decisions, conflicting stakeholder needs, or when you just want to think carefully about something interesting. For problems where user feedback teaches you more than research would, ship and iterate. RDD is for the 20% where understanding determines whether the other 80% goes in the right direction.

When the work shifts from identity-forming ("we're figuring out what this is") to feature-extending ("we know what this is, now we're adding to it"), the scaffolding has done its job. Fold the durable knowledge into your project's native docs, archive the RDD artifacts, and take it down. The knowledge stays. You can always run another cycle when the next hard problem arrives.