Then the next conversation starts, and you explain the same things again.
This is the most common failure mode in working with agents, and it is almost entirely avoidable. The corrections you made were not just fixes. They were training data. Specifically, they were the highest-quality training data possible for your use case, because they came directly from the gap between what the agent produced and what you actually wanted. That gap is information. Most people discard it.
And the problem is not limited to agent conversations. Any time a human has given input to push an output closer to what they actually wanted, the same thing is true. A code review comment. A tracked change in a document. A manager’s rewrite of a proposal. A designer’s markup on a mockup. A customer’s annotation on a prototype. The medium varies. The structure is always the same: something was produced, a human judged it against their actual standard, and they left a record of the gap. That record is a lesson. Almost no one treats it as one.
There is a framework from AI research called Reflexion. The core idea is that instead of updating a model’s weights after a failure, you convert the failure into natural language: “I tried X and it did not work because Y. Next time I should do Z.” That verbal summary gets stored and injected into the next attempt. The model improves without retraining.
This is precisely what happens every time a human corrects any output, except most of us are doing it implicitly and throwing the result away. The correction exists only as a mark in a closed review, a message in a conversation that ended, a diff that got merged and forgotten. It does not survive to the next session, the next colleague, the next time someone needs to produce something similar.
The question is not whether those corrections contain useful information. They obviously do. The question is whether you have a system for capturing them.
The pattern is not specific to agents or to code. It applies to any artifact that went through a human review loop, in any domain.
Agent conversation histories are the most direct case. When you review a completed session and notice what you had to fix, you are reading a list of the model’s blind spots relative to your specific context. Not general limitations, but the precise delta between its defaults and your preferences. Those corrections, when read together, form a description of what you want that is far more accurate than anything you would write from scratch, because it was produced under the pressure of an actual task.
Code reviews carry the same signal. When a senior engineer writes “we do not use global state here” or “this belongs in the service layer, not the controller,” they are articulating a rule that applies not just to that line of code but to an entire class of future decisions. That knowledge lives in closed pull requests, seen once by the author and then archived. Tools like PR-Distiller and braindump have built exactly this observation into pipelines that crawl comment histories, filter out the noise, and distill the recurring patterns into instruction files that agents can actually use.
Document reviews carry it too: PRDs, RFCs, strategy memos, architecture proposals, anything that went through a comment and revision cycle. The tracked changes reveal something the original did not, which is the gap between what the author thought was clear and what the reader actually needed. When a product lead rewrites a requirements section, they are encoding a mental model of what good requirements look like. That encoding almost never gets extracted.
But the class is larger than any of these examples. A designer’s annotations on a mockup encode a visual standard. A legal team’s redlines on a contract encode an acceptable risk threshold. A manager’s reply-all on a proposal encodes a strategic priority. An editor’s margin notes on a first draft encode a voice. A customer’s inline comments on a shared doc encode an unmet expectation. Any place where a human looked at something, judged it against their actual standard, and left a record of the gap is a source. The common structure is: an output existed, a human cared enough to correct it, and the correction encoded something real about what they wanted.
The practical move is to treat review as a production process, not just a quality gate.
After any substantive review cycle, whether it is a conversation, a code review, a document, or anything else, take the feedback that was produced and run a reflection pass on it. Not to relitigate what was corrected, but to ask: what is the generalizable rule that would prevent this correction from being necessary next time? That is the question an agent is well-suited to answer, given the raw material.
After a conversation where you made several corrections, the meta-task is simple: give an agent the transcript and ask it to generate the standing instructions that would have prevented the mistakes. What you get back is a draft skill file. It will not be perfect, but it will be faster to edit than to write from scratch, and it will be grounded in what actually happened rather than what you imagine you want.
The same process applies to any review artifact. After a code review closes, ask an agent to read the comment thread and extract the principles behind the corrections, not the specific changes. “We replaced this implementation because of performance constraints at scale” becomes a rule about data structure selection. “The error handling here doesn’t match our observability conventions” becomes a rule about how failures should surface. After a document review, the richest moment is right after comments are resolved, when the reviewer’s model of what the document should look like is still fully encoded in the thread. A reflection pass at that moment produces something that a pass six months later cannot.
The reflection step works on anything with the right structure: a human saw an output, wanted something different, and said so. The medium is irrelevant.
The output of this process is not just better context for future conversations. It is an accumulating record of your actual standards, derived from your actual decisions, in a form that agents can use directly.
The instructions you generate from a code review are not a generic style guide. They are the specific rules your team enforced on your actual work over a period of months. They contain the real constraints, not the aspirational ones in the wiki nobody reads. The instructions you generate from a design review are not a generic UX checklist. They are the specific judgments your designer applied to your actual product under actual conditions. An agent working with that context is not working from a model trained on the internet’s average standards. It is working from your history.
Research into agent learning frameworks has converged on this insight from a different angle. The most durable knowledge is not injected through better prompts; it is accumulated through episodic memory, the record of what worked, what failed, and what the agent was told to do differently. The difference is whether that accumulation is intentional or accidental.
Every review generates episodic memory. Right now, most of it is going into a system no one queries. The reflection step is just the decision to query it.
The previous post in this series argued that every agent task is a primitive, and primitives compound. This is the mechanism by which that compounding happens faster.
Teaching an agent from scratch requires deliberate effort. Teaching it from a review that already happened requires almost none; the work was done during the review itself. The cost of the reflection pass is nearly zero relative to the cost of the review that produced the raw material. What changes is just whether you treat the review as an endpoint or as a source.
The corrections you have already made, across every review cycle in the past year, contain a precise description of how you and your team work and what you actually want. Some of it is in closed pull requests. Some of it is in comment threads on documents that shipped months ago. Some of it is in conversation histories that have already been pruned. Some of it is in design files, contract redlines, customer feedback threads, and anywhere else people have been doing the work of pushing outputs toward standards.
The ones that are still accessible are worth recovering. Not because the individual corrections matter, but because the pattern across them is the closest thing to a curriculum that an agent could have for working in your specific context.
You wrote it already. You just need to keep it.
]]>The PDF is not the point.
When you delegate a task to an agent, two things happen. The obvious thing is that the task gets done. The less obvious thing is that the agent now has a demonstrated understanding of how you want that task done: the output format, the file naming conventions, where things go, what quality looks like. That understanding does not reset when the conversation ends, at least not if you have built your agent setup with any intention. Skill files, project context, persistent instructions: these are the mechanisms that turn a one-off execution into a reusable capability.
This is the distinction that the token-cost objection misses. Running a terminal command to generate a PDF gets you a PDF. Delegating the task to an agent and refining the output until it meets your standard gets you a PDF plus a documented workflow that the agent can reproduce reliably, combine with other workflows, and deploy as part of something larger.
The terminal command does not compound. The agent invocation does.
Think about what it actually means to teach an agent something. You describe how you want a PDF formatted: margins, font choices, how tables should render, what the header should contain. The agent does it. You correct what is wrong. The agent updates its understanding. After a few iterations, it can generate that PDF without guidance. The capability exists as a primitive: a discrete, reliable unit of work the agent can perform.
Now teach the agent something different. Teach it how to pull a sales report: which database, which query, how to calculate the metrics you care about, which time windows to use, how to handle edge cases when data is missing. Another primitive. Another reliable unit of work.
Neither primitive is impressive in isolation. But the moment both exist, something new becomes possible. “Generate a PDF of this week’s sales report” is now a single instruction. The agent does not need you to explain the PDF format. It does not need you to explain the reporting logic. It combines what it already knows and produces the output. You did not build an integration, write any glue code, or wire up a cron job. You just asked.
This is the compound effect that the token cost misses entirely. The cost of generating that PDF the first time was not just the cost of a PDF. It was an investment in a primitive. And the returns on a primitive are not the single task it enables; they are every task that task will eventually combine with.
There is a version of the token-cost argument that is worth taking seriously. For a genuinely isolated task with no future relevance, no compounding, and no context that transfers, delegating to an agent when a simpler tool would do is waste. The objection is correct in those narrow cases.
But the cases are much narrower than the argument assumes. The people making fun of agent-generated PDFs are treating every task as isolated. They are evaluating the cost of the individual invocation without accounting for what the invocation is building. That is like complaining about the cost of writing a function when you could have copied and pasted the code. Technically cheaper right now. Structurally worse in every direction that matters.
The question to ask about any task is not “is this the most efficient way to execute this specific step.” It is “is this building toward something.” If the answer is yes, the token cost is not a cost. It is a capital expenditure on a capability you will use again, at less cost, in more complex contexts.
What changes when primitives accumulate is not just speed. It is the complexity of what becomes delegatable.
With no primitives, you can ask an agent to do things it already understands from training. Write a function, summarize a document, translate a sentence. Useful, but limited to what the model knows out of the box. With a library of primitives built from your actual context, your actual systems, your actual preferences, the frontier of what becomes a single instruction expands continuously.
You get from “generate a PDF” to “prepare the board presentation with this week’s numbers, flag any metrics that are off-trend, and send it to the exec team.” Not because someone built a product for that workflow, but because you trained an agent on each piece of it, and the pieces combine. The compounding is not metaphorical. It is structural.
Research into multi-agent systems has formalized this intuition. Agents that accumulate skills and can hand them off to other agents, or invoke them as sub-tasks, scale logarithmically on task complexity while static agents scale linearly. Every new skill a skill-equipped agent adds to its library is immediately available for composition with every other skill it knows. The library does not just grow, it multiplies.
The practical implication is direct: the limit on how far this compounds is not the agent’s capability. It is the precision of your descriptions. Vague delegations produce workflows that almost work. Precise delegations, refined through correction until the output is exactly right, produce primitives that hold under composition. The investment is in the refinement, and the return is in everything that primitive eventually touches.
This is the same reason engineers write tested, documented functions rather than copying logic inline. Not because it is faster today, but because it is an asset. Because it handles the next case for free. Because it can be composed with something else without rework.
Every task you delegate to an agent and refine until it is right is a function in that library. The PDF your friend was laughing about is a function. The sales report is a function. The board presentation that combines twelve of those functions and produces something genuinely complex from a single instruction is what that library makes possible.
The person who asked the agent to generate the PDF was not wasting tokens. They were writing infrastructure.
]]>She submits a ticket. Engineering triages it as low-priority, behind revenue-critical features, a platform migration, and a compliance audit. It sits for months. She eventually stops asking and goes back to her spreadsheet.
That scenario is not exceptional. It is the default. Every organization runs a quiet tax on its own creativity—a backlog of ideas that never become software because the people who have the idea are not the people who can build it, and the people who can build it are already spoken for.
The interesting question is not why this happens. It is whether it still has to.
The engineering bottleneck existed for a clear reason: building software required a specific kind of expertise that took years to develop and could not be delegated. A great product sense alone could not ship code. Domain knowledge alone could not query a database. A tight feedback loop on customer pain alone could not produce a working internal tool. The gap between idea and implementation required crossing a technical threshold, and most people in most organizations never crossed it.
AI coding agents collapsed that threshold. Not partially—substantially. A customer success manager who can describe clearly what she wants can now get a working prototype in a day. A designer who understands the user flow can generate the front-end logic to implement it. A product manager who has been living in the analytics data for months can build the custom view that the off-the-shelf dashboard cannot provide. The synthesis that once required a trained engineer—reading requirements, writing code, connecting a data source, deploying the result—now runs on a description.
This is not the same as low-code tools from five years ago. Low-code still required you to think in the platform’s model, learn its component library, accept its constraints. What is different now is that the interface is language. If you can describe the problem precisely, you can get code. And the people in your organization who understand your customers, your operations, and your internal workflows most precisely are often not engineers. They are the people who deal with these systems every day.
The practical implication is direct: give everyone in your organization access to the same tools that engineers use. Code repositories. Databases with real data schemas. AI coding agents. Deployment pipelines. Not as a productivity experiment. As organizational infrastructure.
The single condition that makes this work—and the single condition that makes it safe—is the sandbox.
Separate this environment completely from production. Mirror the schemas, mirror the data structures, anonymize sensitive records where needed, but replicate enough of the real system that what people build reflects reality rather than a toy version of it. In this sandbox, a sales rep can build her dashboard. A customer success manager can automate the renewal alert. A finance analyst can generate the cash flow reconciliation view that Finance has been asking Engineering for since Q2 of last year. An operations lead can build the inventory tracker that currently lives in three disconnected spreadsheets.
None of it touches production. None of it creates compliance risk. Nothing breaks. The cost of experimentation goes to nearly zero, and the people with the best domain knowledge are now doing the building.
This is not a new idea in principle—the citizen developer movement has argued for it for years—but AI has changed its practical reach. Low-code platforms made building accessible to a few technically-minded business users. AI coding agents make it accessible to almost everyone who can express a problem clearly. The population of potential builders in your organization just expanded by an order of magnitude.
When organizations lock down their tools and refuse to give non-engineers access to infrastructure, they do not eliminate the building instinct. They push it underground. The result is shadow IT: unauthorized SaaS subscriptions, rogue Airtable bases connected to customer data, spreadsheets doing the job of databases, Zapier automations nobody in IT knows exist. By some estimates, enterprises have hundreds of unmanaged applications in use at any given time, most of them solving real problems that the official toolchain failed to address.
Shadow IT is what happens when the demand for building exceeds the permitted supply. The sandbox is the sanctioned alternative. It says: yes, build here, with proper tooling, connected to real schemas, governed by normal access controls. The builds stay visible, auditable, and contained. The people with ideas stop working around the system and start working inside it.
The governance question matters. Access controls should reflect roles. Production credentials should never live in the sandbox. Sensitive data should be anonymized before it reaches the exploratory environment. These are solvable infrastructure problems, not reasons to keep the workshop locked. Organizations with formal governance frameworks report meaningfully higher success rates for citizen development programs than those without—not because governance enables creativity, but because it makes creativity safe enough to sanction at scale.
Internal tools are the obvious first output. The dashboard the sales rep never got. The ops tracker that replaces three spreadsheets. The reconciliation view Finance has been requesting for two years. These are not glamorous, but they are real, and their value compounds. When the people closest to a problem own the solution, iteration is fast and the feedback loop is tight. A tool that sits in a backlog for four months before a sprint and then three more months before deployment gets revised when engineering has capacity. A tool built by the person who uses it daily gets revised the morning it stops working the way she needs it to.
The less obvious output is new products. When non-engineers have access to the full stack—data, code, deployment—some of what they build will reveal unmet market demand rather than just internal workflow gaps. The customer success team that builds a better renewal tracking tool internally might be sitting on the seed of a product that external customers would pay for. The sales team that automates its own pipeline hygiene might be discovering an integration that a category of buyers has been asking their vendors to build for years.
These are not guaranteed outcomes, but they are genuinely possible ones, and they only become possible if the building is happening in the first place. Ideas trapped in someone’s head because they cannot get engineering time never become products. Ideas built in an afternoon—even rough, even incomplete—can be shown to someone, iterated on, and eventually handed to engineering as a real spec rather than a verbal description.
That handoff matters. When something built in the sandbox shows clear signal—it gets used, it solves the problem, it attracts interest from other teams—engineering can formalize it. Move it to production, harden the architecture, integrate it properly. The sandbox is not a replacement for engineering. It is a filter that ensures engineering time goes to the ideas that have already been tested.
Nothing about this diminishes the engineering function. If anything, it clarifies it.
Engineers are not gatekeepers to software creation. They are the people who turn validated ideas into production-grade systems, who maintain the infrastructure everyone else builds on, who think about scale, security, and the long-term health of the codebase. When the sandbox works well, engineering receives better inputs. Instead of triaging a backlog full of speculative requests, they are evaluating tools that already work, have already been validated by real usage, and already have a clear owner who understands the requirements firsthand.
The role shift that AI is forcing in software engineering is not that engineers become obsolete. It is that the boundary between who builds and who does not becomes porous. Designers implement their own interactions. Analysts build the tools they need rather than waiting for engineering capacity. Customer-facing teams prototype solutions to their own problems. Engineers move toward architecture, governance, and the hard integration work that requires deep technical judgment.
This is a better use of everyone involved. The person who understands the problem best is building the solution. The person who understands system design best is ensuring it holds.
The bottleneck is no longer tooling. It is not access to engineering. It is clarity.
The sandbox does not produce good tools automatically. It produces tools proportional to the builder’s understanding of the problem. Vague requirements produce tools that almost work. Precise, well-articulated problems—the kind that come from sitting in a workflow for months—produce tools that actually solve the problem. The skill that matters is not programming. It is knowing what you want clearly enough to describe it.
That is an organizational capability worth developing. Not everyone will build. But the people who have been living inside a problem long enough to articulate it precisely are exactly the people who should have access to a workshop. The constraint on creativity in your organization is not engineering capacity. It is whether the people with the best ideas have the tools to act on them.
Open the sandbox. Let them build.
]]>These numbers do not cancel the productivity gains. But they do describe an asymmetry that most organizations are not treating seriously enough. The system that generates work is running faster. The system that catches errors is not keeping pace.
DORA calls the period of initial productivity dip the J-Curve: a temporary regression before long-term gains. Most leaders who encounter this framework treat it as a forecast. Get through the dip, reach the gains. Move fast, absorb the cost, wait for the payoff.
That reading is wrong in an important way. The dip is not random turbulence. It is a stress signal about specific systems that were designed around assumptions that AI adoption has invalidated. The DORA team identifies three causes: the learning curve as teams adapt their workflows, the verification tax of reviewing AI-generated code, and the downstream strain on testing and change approval systems that were built for lower code volume.
Each of these causes has a source. The verification tax does not shrink on its own. It shrinks when review processes are redesigned for AI-assisted output patterns rather than assuming the code was written by the person submitting it. The pipeline strain does not ease by waiting. It eases when testing infrastructure, deployment gates, and observability tooling are rebuilt to handle the new volume and surface the error patterns that agents specifically tend to produce.
Organizations that treat the J-Curve as a phase to endure will not exit it cleanly. Organizations that treat it as a diagnostic will identify which systems are under stress and redesign them. The difference in outcome between those two approaches compounds quickly.
The first thing to understand about AI-generated code and quality is that friction does not disappear when code generation gets faster. It relocates.
When engineers write code, understanding travels alongside it. The person who wrote the function understands it. The reviewer who read it carefully has built some model of it. The team that absorbed a discussion in a pull request thread has some exposure to what was decided and why. That distributed understanding is invisible until it is missing, and it is missing more often now.
When an agent generates code from a prompt, the output may be correct and even elegant, but the understanding that usually travels alongside handwritten code does not make the same journey automatically. The function exists. The reasoning that produced it is not embedded in the team’s working memory the way it would be if an engineer had spent time writing it.
This is the verification tax in concrete form: reviewing code you did not write, at a volume two to three times what your review process was calibrated to handle, with less ambient context than you would normally bring to a peer’s pull request. The work still exists. It is just arriving in a different form, and the systems designed for the old form are under pressure.
The DORA findings on organizational readiness are arguably more diagnostic than the incident metrics. Of 219 organizations surveyed, evaluating AI-generated code had become the top hiring priority. Yet only 19 of those 219 had formally updated their role definitions to reflect that shift.
Individual engineers adopted agents. Organizations changed almost nothing structurally. Process, accountability structures, review standards, and incentives remained calibrated to a world where the engineer who wrote the code was also the person who best understood it. That assumption is no longer reliably true, and the systems built on it are generating the instability numbers the report describes.
This is the organizational lag. It is not malicious or unusual. Organizations update their structures on cycles measured in quarters or years. Individual behavior updates in weeks. The gap between those cycles is where technical and organizational debt accumulate together, and right now that gap is unusually large.
When something breaks in a system where humans wrote the code, accountability is traceable enough to create feedback. The person who wrote the function, the reviewer who approved it, the engineer who shipped it: each played a visible role. The feedback loop is imperfect, but it exists. Engineers learn from failures in code they authored.
When an agent generated the code and a human approved it without fully understanding it, the accountability surface is blurrier. The incident exists. The feedback loop that would convert it into behavioral or process change is weaker. If the review process does not catch the pattern and update the constraints the agent operates under, the same class of error recurs. The incident becomes a tax on velocity rather than an input to improvement.
This is the structural gap that most organizations have not yet closed. They have agents generating code. They do not yet have systems that reliably convert agent-generated failures into improved agent behavior or improved human oversight.
The DORA report is careful to frame this as a foundation problem rather than a tooling problem. AI acts as an amplifier. Strong foundations produce amplified gains. Weak foundations produce amplified dysfunctions. The organizations exiting the J-Curve successfully share a structural characteristic: they redesigned the verification layer alongside the generation layer.
In practice, this means review processes that account for AI-output patterns rather than assuming human-authored code heuristics. It means test infrastructure that scales to handle the increased pull request volume without becoming a bottleneck that agents simply outrun. It means explicit human checkpoints at the specific decision points where agent judgment is least reliable; not everywhere, but at the high-risk junctions where failures are expensive. And it means role definitions that reflect the actual shift in what engineers do: not primarily authors of code, but accountable evaluators of correctness and fit for what they approve.
None of this is primarily a tooling gap. The tools exist or are being built. The constraint is organizational. Who is accountable for what, how that accountability creates learning, and whether the systems that reward and measure engineering work have caught up to the reality of how engineering work is now being done.
Throughput metrics are real. The productivity gains from AI adoption are measurable and significant. But throughput is not the goal. Working software in production, that users trust and that teams can maintain and evolve, is the goal.
A team shipping twice as much code with three times as many incidents is not twice as effective. It may be moving faster toward a larger pile of production problems and a codebase that fewer people truly understand.
The DORA team puts it plainly: AI should be measured not by the code it writes but by the bottlenecks it clears. The bottleneck worth clearing next is probably not code generation. It is the organizational systems that have not yet adapted to the code generation that is already happening. Velocity without comprehension is just a faster way to accumulate surprises in production, and the J-Curve will keep collecting its tuition until those systems catch up.
]]>Crossing from linear to exponential output requires changing the structure of how work flows through your team. Not the tools alone. The habits, the process, the way work is queued and executed and reviewed. Here is what that actually looks like in practice.
The single biggest structural change is moving from one work stream to many. In practice this means running multiple copies of the repository simultaneously: separate worktrees or separate clones, each on its own branch, each with an agent working through a discrete problem. When one stream gets blocked on a review, a flaky dependency, or an ambiguous requirement, you do not stop. You switch to the next one and let the agent continue when the blocker resolves.
Cloud environments extend this further. You are not limited to what fits on your local machine. Each work stream can run in its own isolated box, and you move between them as a foreman moves between workers, checking progress, unblocking, steering direction. The limit is cognitive, not technical. More than five parallel streams and your ability to maintain context across all of them degrades fast enough to cancel the gains.
The mental model shift is significant. You are no longer a single-threaded producer. You are a scheduler and a reviewer, and your job is to keep the streams moving, not to do the building yourself.
Parallel work streams only help if there is always something to work on. This is where PMs and EMs face a new failure mode that did not meaningfully exist before: the backlog running dry.
When execution capacity was the constraint, a two-week backlog felt healthy. There was always more work queued than the team could ship. Now, with agents running multiple streams simultaneously, that buffer evaporates quickly. The PM who still prepares work on a sprint-by-sprint cadence will find engineers and agents sitting idle waiting for the next well-defined task.
The new operating model requires the backlog to stay roughly three times deeper than current execution capacity. Not because all of it will get built, but because agents and engineers should never be the bottleneck in their own pipeline. The moment an engineer has to stop and ask what to work on next, the system has failed. That is a PM and EM problem, not an engineering problem.
Not all work requires human involvement at every step. Closed loops are the parts of the codebase where an agent can iterate autonomously: a well-defined scope, a test suite that functions as a fitness function, and a low cost of reverting if something goes wrong. Performance improvements, test coverage gaps, dependency upgrades, dead code removal, accessibility fixes. These are areas where you can hand off a task, let the agent run, and review the outcome rather than the process.
The value of closed loops is compounding. Once you identify them, they can run in the background across multiple cycles, returning results for human review without consuming your active attention. They are also a useful calibration tool: the quality of an agent’s output on a closed loop tells you how much latitude to grant it on more open-ended work.
Start by cataloging where your test coverage is strong enough to make agent iteration safe. Those are your first closed loops.
The fear that slows teams down is not technical. It is psychological. Engineers hold back changes because they are not sure they are ready. PMs delay releases because something might break. The process accumulates review gates and staging cycles that exist to manage anxiety more than to catch real errors.
Feature flags collapse that anxiety. If a change is gated behind a flag, it is not really released until you choose to enable it. You can deploy continuously and release deliberately. The addition cannot break the current system because the current system does not see it until you decide it should.
This changes the rhythm of development significantly. Merging and deploying become low-stakes routine events. The release decision is decoupled from the deployment decision. Teams that internalize this stop treating deployments as moments of risk and start treating them as infrastructure hygiene, which is what they should always have been.
Human review time is expensive and finite. It should go where human judgment is genuinely irreplaceable.
For large features, that place is the RFC. Before an agent writes a line of code on a significant new capability, a short written document should describe what is being built, why, and how the main pieces fit together. This is not a heavyweight design process. It is a one-to-two page artifact that gives both the agent and the team a shared model of what success looks like. Without it, agents and engineers make incompatible assumptions in parallel and the integration cost is brutal.
For code review, the calculus is different. An agent reviewing a pull request for correctness, style consistency, test coverage, and obvious edge cases is faster and more consistent than a human doing the same scan. Human reviewers should focus on whether the code is solving the right problem, not on whether the variable names follow convention. Use agents to surface the mechanical issues, and reserve human attention for the judgment layer.
The distinction is simple: RFCs get human review because they define intent. Code gets agent review because agents can verify execution against intent more reliably than humans checking line by line.
The hardest habit to break is opening the editor and making the change yourself. It is almost always faster in the moment. You know exactly where the file is, you know what needs to change, and the three-second edit feels more efficient than writing a prompt and reviewing the output. That instinct is correct in the short term and damaging in the long term.
Every time you reach into the codebase directly, you are reinforcing a workflow that does not scale. The engineers and teams operating at exponential pace have rebuilt their default behavior: the agent codes, the human directs and reviews. That shift requires deliberately practicing the slower path until it becomes the faster one.
This is not a rule to follow religiously. There are moments where a direct edit is the right call. The point is to notice when the reflex to do it yourself is habit rather than judgment, and to resist it. The throughput difference between a team where everyone has crossed that threshold and a team where most people have not is not incremental. It is the difference between two curves that are moving apart.
The last shift is the most counterintuitive for anyone who has spent time in a process-heavy organization. Planning costs have not changed. Coordination meetings, product discovery sprints, market validation cycles, GTM alignment: all of this consumes roughly the same time it did five years ago. Implementation costs have collapsed. This means the ratio that once justified heavy upfront planning no longer holds.
For reversible decisions, the bias should be strongly toward building and testing over planning and validating. If you are unsure whether a feature is worth building, the cost of building a version behind a flag and watching what happens is often lower than the cost of the research process that would have given you a confident answer three months later.
The process that survives this recalibration is the RFC: a lightweight artifact for irreversible or high-coordination decisions. The process that does not survive it is the discovery ritual performed before every feature, regardless of stakes. Most features are reversible. Most discovery cycles are expensive. The teams moving fastest have noticed this and adjusted.
Build more. Validate in production. Reserve the planning overhead for the decisions that genuinely cannot be undone.
]]>The more useful question is not whether a candidate can produce code alone in forty minutes. The useful question is whether that candidate can take a messy problem, use modern tools well, make sound tradeoffs, and evolve a solution with clear reasoning. If that is what we want to measure, the interview has to follow a different structure.
The first stage should be a take-home assignment where AI use is explicitly allowed. That policy does two important things immediately. It removes the performative game of pretending people do not use modern tools, and it shifts evaluation from raw typing speed toward engineering judgment. If the assignment has enough complexity, the candidate still has to decide architecture, boundaries, error handling, testing strategy, and scope control. AI can assist with implementation, but AI does not make those decisions for them.
A good take-home should feel like a thin slice of production work. It should be large enough to expose multiple design paths and small enough to complete in a reasonable window. It should include constraints that force prioritization. It should be open enough to reveal how the candidate thinks, but concrete enough that a reviewer can judge whether the solution is coherent.
Providing tests can be useful, especially when you want a baseline of correctness across submissions, but tests are not the only source of signal. Even without a formal test harness, a thoughtful submission still shows structure, assumptions, naming, organization, and risk awareness. In many cases, you can learn more from how someone frames the problem than from whether every edge case was fully covered in limited time.
Before inviting someone onsite, review the take-home exactly as you would review a peer’s pull request. Read it for maintainability, not only for correctness. Ask whether the architecture is easy to extend. Ask whether the abstractions are justified. Ask whether the code reads like something you would want on your team six months from now.
Reviewers should run a team-agreed agent review prompt against the submission and combine those agent notes with their own reviewer notes before the onsite. The agent surfaces blind spots and pattern-level issues at scale; the human reviewer adds context, taste, and role-specific judgment. Together they produce a stronger and more repeatable pre-onsite brief than either source alone, and they give every reviewer on the panel a shared baseline to work from.
This review will never be perfect, and that is fine. In fact, imperfections are useful because they generate real discussion prompts for the next stage. The goal is not to “catch” the candidate. The goal is to identify technical decisions worth examining in a collaborative conversation.
When teams skip this step, they often waste onsite time rediscovering first-pass impressions that could have been prepared in advance. When teams do this step well, onsite interviews become sharper because every discussion starts from concrete artifacts rather than hypotheticals.
The onsite should begin with the candidate walking through their own submission. This is where depth becomes visible very quickly. People who truly understand what they built can explain why they chose one approach over another, what tradeoffs they accepted, and what they would change with more time. People who only assembled output without understanding it struggle as soon as the conversation leaves the happy path.
Treat this conversation like a real engineering review, not like an oral exam. Raise questions from your pre-review. Challenge a boundary choice. Ask what breaks under load. Ask how they would validate a risky assumption. Ask which parts are most likely to generate operational issues after deployment. The point is to observe how the candidate reasons in the same collaborative pressure your team faces every week.
This format also evaluates communication quality, which becomes more important as AI accelerates implementation. Teams increasingly fail at handoffs and alignment, not at syntax. Engineers who can explain complex decisions clearly and absorb feedback productively create disproportionate leverage.
After the walkthrough, ask the candidate to extend the same solution with a new requirement. Add a feature. Introduce a constraint. Change an assumption. Request an operational guardrail. Anything that forces modification of existing design rather than fresh coding from scratch.
This is the strongest signal in the entire process because software work is mostly change, not greenfield creation. Extending an existing system reveals whether the candidate actually understood the original problem, whether their architecture can absorb new requirements, and whether they can make incremental progress without destabilizing what already works.
It also resolves the anxiety many teams now have around AI-assisted submissions. If someone cannot reason about their own code, they will fail quickly when asked to evolve it. If they can extend it coherently under discussion, then the interview has validated the capability that matters in production.
The traditional modules still belong in the loop. System design remains essential for evaluating decomposition, scaling instincts, and resilience thinking. Algorithms and data structures still matter for reasoning precision and complexity tradeoffs. Time and space analysis still matter when systems hit real constraints.
But these modules should no longer carry the entire hiring decision. They should complement evidence gathered from the end-to-end problem flow. In other words, fundamentals remain necessary, but they are no longer sufficient as standalone proxies for day-to-day engineering effectiveness.
When a candidate has already demonstrated practical implementation, code review maturity, and the ability to extend a live solution, a system design conversation becomes richer and more predictive. It moves from abstract performance to applied judgment.
The core change is simple. Stop treating interviews as disconnected tests. Treat them as one continuous engineering narrative. A candidate starts with a realistic problem, submits a solution in the same AI-assisted reality we all now operate in, defends it in a peer-level discussion, extends it under new requirements, and then demonstrates foundational reasoning in system design and algorithmic analysis.
That sequence aligns with modern engineering work far better than isolated coding drills, and it produces stronger hiring signal with less theatrics. In a world where code generation is increasingly commoditized, the real differentiator is still human judgment: what to build, why to build it, how to validate it, and how to evolve it safely. Interviews should be designed to find exactly that.
]]>That is the old model. Strategy is episodic, planning-heavy, and only occasionally corrected by real usage data. The new model is different: product strategy runs as a continuous evolutionary loop, where ideas are generated, tested in production, selected by outcomes, and replaced when they fail.
Karpathy’s AutoResearch points to the pattern. In that loop, an agent edits code, runs an eval, keeps what improves the score, and discards what does not. Applied to model research, this feels natural. Applied to product development, it looks radical until you notice we already do a slower, less consistent version of it. We ship changes, wait for behavior, and decide what survives.
The real shift is not that agents can write code. The shift is that product work can be treated as search.
Most roadmaps are expressions of confidence. But confidence is not the same thing as evidence. Before users interact with a change in real conditions, most product decisions are still informed guesses.
Seen through an evolutionary lens, every product decision is a mutation candidate. Rewrite onboarding copy. Remove one signup step. Change default settings. Move the paywall. Preload a result before a click. Adjust notification timing. Offer a different first-run workflow. Each of these creates a variant of the product. The market provides selection pressure.
When a team can generate and evaluate variants faster, it learns faster. When it can evaluate with discipline, it compounds.
In model training, feedback can be immediate. In product systems, truth is delayed and noisy. Conversion may need a day of traffic. Retention may need a week. Revenue impact may depend on seasonality and segment effects. Support burden may lag deployment by days.
So the loop becomes asynchronous. Agents generate and ship bounded experiments behind flags. The system waits for an observation window, scores outcomes, and either promotes, iterates, or reverts. While one experiment waits for D1 or D7 signal, other experiments continue in parallel.
This is where many teams fail. They optimize for experiment velocity without investing in evaluation quality. A fast mutation engine with weak selection criteria does not produce progress. It produces churn.
In practice, eval becomes the product operating system.
Single-metric optimization is fragile. If an agent is rewarded only for conversion, it can discover manipulative tactics that increase short-term clicks and erode long-term trust. If it is rewarded only for engagement, it may optimize for time spent rather than value delivered.
A Darwinian product system needs multi-objective scoring and hard constraints. Some trade-offs are acceptable. Some are not. Crash regressions, security violations, and policy breaches should be non-negotiable kill conditions, not soft penalties.
This is the governance layer people underestimate. The hardest artifact in an autonomous product system is not a prompt. It is a constitution: what must always be optimized, what can be traded, and what must never be sacrificed.
The more interesting move is not only mutating shipped features. It is mutating strategy inputs.
Agents can continuously parse support tickets, call transcripts, product analytics, public reviews, competitor changelogs, pricing pages, and community discussions. From that stream, they can infer repeated pain clusters, detect emerging demand shifts, and propose initiative candidates with explicit assumptions and confidence estimates.
Another layer of agents can map those opportunities to your current architecture and delivery constraints, producing backlog options that are both market-aware and implementation-aware. Instead of quarterly prioritization rituals dominated by opinion weight, you get a living backlog frontier that updates as evidence changes.
Product leadership does not disappear in this model. It becomes more important. Humans still define the mission, user hierarchy, and ethical boundaries. Agents can expand the option set and accelerate execution, but they cannot decide what kind of company you are trying to be.
Once agents can generate more ideas than teams can safely evaluate, the core management problem changes. Engineering capacity is still a constraint, but evaluation bandwidth and inference budget become first-class constraints too.
Not every idea deserves expensive reasoning or long observation windows. Low-cost models can generate and filter broad hypotheses. Mid-tier models can implement and instrument promising variants. High-capability models can be reserved for ambiguous results, cross-metric trade-off analysis, and high-risk decisions. Fast proxy signals can triage candidates before slower behavioral metrics confirm value.
This is portfolio management applied to product development. You are allocating time, traffic, and tokens across uncertain bets while preserving system stability.
Most organizations do not need full autonomy immediately. They need reliable scaffolding.
They need safe mutation surfaces with feature flags and rapid rollback. They need instrumentation that captures both business outcomes and quality regressions. They need evaluator pipelines that can separate signal from noise and account for lagging effects. They need policy enforcement that blocks unacceptable variants automatically. They need review loops where humans audit not just outputs, but also whether the fitness function is steering behavior in the intended direction.
The immediate goal is not “remove humans from product.” The immediate goal is “move humans to higher-leverage decisions and let the loop run faster between decisions.”
As these systems mature, role definitions shift.
Engineers spend less time on repetitive implementation and more time on experiment infrastructure, observability, and guardrail design. Product managers spend less time writing static roadmaps and more time defining objectives, constraints, and evidence thresholds. Design moves closer to evaluation design, because qualitative quality must be represented in the scoring system if it is going to survive automated selection.
The unifying skill becomes objective design. Teams that define fitness clearly will improve quickly. Teams that define it poorly will optimize themselves into local maxima that look good on dashboards and feel bad in real use.
The near term is hybrid. Human judgment remains central. But the structure is changing from roadmap-first execution to loop-first adaptation.
In a roadmap-first model, the core question is what we will ship next quarter. In a loop-first model, the core question is what selection environment we are creating and what behaviors that environment will reward.
Karpathy’s AutoResearch showed that autonomous variation and selection can accelerate model progress. The same pattern, applied carefully, can reshape product development end to end: from market sensing to backlog generation, from implementation to rollout decisions, from static planning to continuous adaptation.
In that world, competitive advantage comes less from who can ship a feature and more from who can design a trustworthy evolutionary system around users.
]]>He called it Dobby. A single WhatsApp-accessible agent that scanned his wireless network, found every connected device, and unified control behind a conversational interface he already used. Six apps became one. The interface became language. The friction became almost nothing.
That is not a productivity hack. That is the beginning of something different: software that belongs to you.
We have had personal computers for forty years. The word “personal” was always a lie—personal in the sense of individual ownership, not individual fit. The software running on those computers was designed for everyone, which means it was designed for no one in particular. Every Photoshop user gets the same Photoshop. Every Slack user gets the same Slack. The product teams make reasonable bets about what most users need most of the time, and the rest of the needs go unserved.
This was always a constraint of economics, not design intent. Custom software is expensive. A system built precisely for how you work, tuned to your habits, connected to your specific tools and data—that has always cost either a lot of money or a lot of time. Enterprise companies buy custom software and still pay millions for it to be wrong. Everyone else adapts to whatever shipped with the most comparable monthly subscription.
Karpathy framed this moment clearly. We are moving from Software 1.0—code written by engineers—through Software 2.0—neural network weights—into Software 3.0, where prompts written in English are the programs. The LLM is the runtime. Natural language is the interface. And if language is the interface, then anyone can build.
The term Karpathy coined in early 2025 is telling: vibe coding. You describe what you want and get working software. Not a prototype. Not a rough approximation. Working software. He built iOS apps without knowing Swift. He built a restaurant menu image generator, MenuGen, in hours rather than the weeks a traditional developer would need.
The actual coding became trivial. The deployment infrastructure remained complex—Google OAuth integrations still require clicking through seventeen configuration screens—but the core act of expressing software in code crossed a threshold. Anyone who can describe what they want clearly enough can get it built.
This is the inflection point the Dobby story illustrates. Karpathy did not buy a home automation platform or wait for some company to build the multi-vendor dashboard he wanted. He described the system he needed and built it himself, in the time he would have previously spent reading product documentation and filing support tickets.
The bottleneck is no longer building the software. It is knowing clearly enough what you want.
Every app in a store is a bet. A team of people decided that enough users shared a similar enough problem to justify building a general solution and charging for access. The store model created the intermediary layer we now navigate constantly: you have a specific need, you find the app that comes closest, you adapt your behavior to fit the tool rather than the reverse.
This works well when your needs match the developer’s assumptions. It works poorly at the edges, which is where most of us actually live. The to-do app that almost fits your workflow. The note-taking tool that has most of what you need and the one feature that is inexplicably missing. The habit tracker that sends notifications at the wrong time, in the wrong way, and has no option to change it.
Each of those friction points persisted because the economics of custom software made the alternative unreachable. That constraint is dissolving. When building the app that exactly fits how you work costs an afternoon instead of a quarter, the calculus changes entirely.
What emerges on the other side of this shift is not just more software. It is different software. Software that knows your context because you gave it your context. Software that connects to your actual systems—your calendar, your notes, your home, your data—rather than a generic API that works for everyone and therefore for no one specifically.
Karpathy’s agents run in tmux grids, managing code repositories. His home automation agent knows the layout of his specific house. These are not products. They are tools with a user base of one, optimized for that user without compromise.
This changes what it means to be technically skilled. The engineers who will build the most valuable things are not necessarily the ones who can write the most efficient code. They are the ones who can describe problems with enough precision that an agent can solve them, who can design systems with enough clarity that the implementation follows directly from the spec. I wrote about this in the context of specifications becoming the real source code—the judgment about what to build is where the hard work lives. The building is increasingly automatic.
But this capability is not restricted to engineers anymore. The five-to-ten year learning curve that once stood between an idea and working software is collapsing. Anyone who can articulate what they need precisely can build it. That is genuinely new.
The consumer software market as it exists—millions of users paying subscriptions for software that fits most of them well enough—will not disappear overnight. There are products where the network effect is the product. There are categories where the general solution is actually the right solution. And there are problems that require the kind of deep domain expertise that a product team accumulates over years and that a single person building their own tool will not replicate.
But at the edges, where your specific needs have never been served by the general solution, the era of personal software has started. The six-app dashboard becomes one agent. The to-do system that almost fits becomes one that actually fits. The workflow that required three tools and a spreadsheet becomes software that understands your workflow.
Software used to be designed for everyone. It is starting to become possible for it to be designed for you. That is a larger change than it first appears—not just in how software gets built, but in the relationship between people and the tools they use to work and live.
Personal computers were personal in name. Personal software might be personal in fact.
]]>The system builds itself. Not perfectly, not without iteration, but the shape of the pipeline is clear: human writes the spec, agent writes the code, another agent reviews, and the orchestrator manages the loop. The human never opens an editor to write production code.
This is what I meant when I said specifications are becoming the real source code. If the spec is the source, then code is a compilation target. And if code is a compilation target, then the compiler can be an agent.
The project is a CRDT-based sync engine for restaurant kitchen tablets. Offline-first, field-level conflict resolution, peer-to-peer sync over gRPC. The kind of system where edge cases matter and distributed semantics are the hard part. The pipeline has four stages.
PRD. One document. Problem statement, use cases, functional requirements, data model, flows. Written in Markdown with Protobuf schemas and Mermaid diagrams. This is the contract between the product vision and the engineering work. It defines what the system does and why, in language precise enough for an agent to consume but readable enough for a product manager to review. Twelve use cases, nineteen functional requirements, eight non-functional targets.
RFCs. Once the PRD was solid, I had an agent generate seven RFCs from it—one per technical decision. The core data model. Field-level conflict resolution. Node identity and bootstrap. Transport layer. Interest-based subscriptions. Safe deletion and eviction. Priority sync. The agent decomposed the PRD’s requirements into focused design documents, each answering the questions that would otherwise become production bugs: what happens when a tombstoned entity receives a new update? What if a tablet receives data from an unregistered node? What order must collections hydrate in?
I reviewed and refined the RFCs, but the agent did the heavy lifting of breaking a single product document into seven coherent technical designs. An eighth RFC compared the design against existing CRDT libraries to validate the approach. These questions were answered in prose, not in debuggers. The RFC forces clarity before any code exists.
Issues. Each requirement becomes a GitHub issue. Issues link to their RFC or PRD section. Dependencies are explicit: issue N requires issue N-1 to be closed. This turns the spec into a work queue with ordering constraints, and gives agents the context they need to implement each piece.
Agents. A bash script polls GitHub for issues labeled agent:coder. It ensures the repo is on latest main, builds a prompt from a template, and runs a coder agent. The coder reads the issue, follows links to the RFC, implements with TDD—E2E test first, then minimal code—pushes the branch, and posts a summary as an issue comment. The orchestrator captures the result, transitions the label to agent:reviewer, and runs the reviewer agent. The reviewer checks requirements compliance, code quality, and test coverage, then either approves and squash-merges to main, or requests changes and sends it back to the coder. The loop repeats until the issue is closed.
PRD, RFCs, issues, orchestrator, agents, code, review, merge. That is the pipeline.
The orchestrator itself is surprisingly simple. GitHub issue labels are the state. agent:coder means the coder should run. agent:reviewer means the reviewer should run. agent:done is terminal. A retries:N label tracks how many times the loop has cycled.
Transitions are configured in a few lines of YAML: coder succeeds, go to reviewer. Reviewer succeeds, mark done and close the issue. Either agent fails, send it back to the coder. A global retry cap prevents infinite loops.
The orchestrator does not know what a coder or reviewer does. It only knows the state machine. The intelligence lives in the skills—Markdown files that tell each agent its mission, workflow, and exit conditions. The coder skill says: fetch the issue, read linked docs, implement with TDD, push, post summary. The reviewer skill says: check the diff against requirements, run tests, post structured feedback or squash-merge.
This separation matters. The orchestrator is stable infrastructure. The skills evolve. You can add a security reviewer or a performance auditor by writing a new skill and adding a transition. The pipeline is extensible without changing the engine.
It is worth noting that tools like Cursor now ship first-class agent support—you can run agents directly from the IDE with full codebase context, skills, and subagents built in. The custom orchestrator I built was an experiment in understanding the workflow, but the infrastructure is catching up fast. The pattern matters more than the plumbing.
My role in this pipeline was three things: write the specs, create the issues, and review the output.
Writing the PRD took most of the effort. It defines the problem space, the data model with Protobuf schemas, and the flows with Mermaid sequence diagrams. This is where the hard engineering happened—not in code, but in the document that defines what the system should do and why. The RFCs were generated from the PRD by an agent, then reviewed and refined by a human. Thousands of words of design decisions, edge cases, and explicit non-goals—produced in minutes, validated over days.
Creating issues was also agent-assisted. The RFCs provided the structure; each section maps to one or more issues. Dependencies between issues mirror dependencies between concepts: you cannot implement subscriptions before the data model exists, and you cannot implement the merge engine before defining conflict resolution semantics.
Reviewing output was the feedback loop. When the reviewer agent requested changes, it posted specific, actionable items in the issue. The coder agent addressed the feedback and pushed again. Most issues closed in one or two cycles. The pattern was consistent: when the spec was precise, the agent got it right quickly. When the spec was ambiguous, the agent made assumptions and the reviewer caught them.
The slowest part of this pipeline is writing the PRD. That is exactly right. If the hardest work in software is understanding what to build and why, then that is where humans should spend their time. The PRD captures the judgment, domain knowledge, and taste that an agent cannot supply—what matters to the business, which tradeoffs are acceptable, what must never happen. Once that document exists, an agent can decompose it into RFCs, and those RFCs can be decomposed into issues, and those issues can be implemented and reviewed by agents. The human’s contribution compounds at every stage.
Once those decisions are captured in a document, the agent can implement them. The code becomes a projection of the spec. Tests validate behavior against the spec, not against the implementation. When storage is refactored from one backend to another, the tests still pass because they test the contract, not the internals.
This is the full arc. Specifications are the real source code. When they are missing, reverse them from the product. When they exist, feed them to agents and let the pipeline compile specs into working software.
The human writes the spec. The agent writes the code. And between them, a bash script manages the loop.
The full source is on GitHub—PRD, RFCs, orchestrator, skills, and all the agent-generated code.
]]>This follows from a simple idea: the spec is the real source code. If we believe that, then when the spec is missing we should recover it, not accept that “the code is the documentation.” A reverse PRD is the artifact you get when you infer intent from behavior, socialize it with stakeholders, and lock it in as the reference for tests and refactors. The only thing that matters is the spec. Everything else should align to it.
There is no denying that at the end of the day “code is law”: it is what runs. But not everyone can read it. Product, design, support, and many engineers think in behavior and intent, not in syntax. The PRD is the desired spec—the human-readable contract that says what the system does and why. Reverse PRD is how you get that contract when it was never written or has drifted out of view.
A reverse PRD is a hypothesis. You build it by watching the product, reading the code, and talking to people who use or maintain it. You write down what you think the system does and why. That draft is not the source of truth until it has been validated.
Validation is where most of the effort should go. Stakeholders must confirm that the described behavior matches what they expect. You sample real flows, edge cases, and failure modes and check them against the document. You use tests as evidence: scenarios that pass today become the stated behavior in the spec. Without that loop, the reverse PRD is just an opinion. With it, the spec becomes the agreed contract that the team can rely on for understanding, testing, and change.
Once you have a PRD, the biggest risk is drift. Code changes and the document is forgotten. The fix is to treat “spec in sync with code” as a hard gate, similar to code coverage.
Define rules that tie areas of the codebase to their artifacts. When someone changes code in an area covered by a PRD, the pipeline checks that the PRD was updated or explicitly acknowledged. If the spec is stale or the link is broken, the build fails. You do not merge without meeting the bar. That keeps the PRD from becoming a one-time deliverable and turns it into a living contract that the team is forced to maintain.
This is the same mindset as coverage thresholds. We do not accept “we will try to add tests later.” We fail the build. The same discipline applied to specs prevents the reverse PRD from decaying the moment the next feature ships.
Not every part of the system needs a PRD. Product behavior is captured in a PRD. Design and architecture decisions belong in RFCs. API surface is captured in OpenAPI or another API spec. Each area has one or more canonical artifacts that describe intent and behavior.
The rule is: this slice of the codebase is covered by one or more artifacts. The enforcement layer checks that when code in that slice changes, the corresponding artifact or artifacts exist, are updated, and stay consistent. A given area might have a PRD for behavior, an RFC for the design, and an API spec for the surface—multiple artifacts for the same slice. Same principle: everything that matters is written down and kept in sync.
Reverse PRD gets you to a spec when you did not have one. Enforcement and ownership keep it alive. Those are two phases. First you recover the contract from the product. Then you run the process that keeps the contract and the code aligned.
The literature has related ideas: reverse requirements engineering, Martin Fowler’s “From Black Box to Blueprint,” and tools that extract documentation or specs from code. The twist here is to treat the recovered artifact explicitly as the PRD—the single source of truth for that area—and to back it with rules that fail the build when the spec falls behind. The spec is not a byproduct of the code. The code is the implementation of the spec. When the spec was lost, we reverse it. Once we have it, we enforce it.
You do not need to reverse the whole product at once. Start with the area that causes the most confusion: the flow everyone is afraid to change, the module that only one person understands, or the surface that customers rely on and that has no written contract. Draft the reverse PRD for that slice. Validate it with the people who care. Then add the rule: changes here require an updated spec. Once that works, repeat for the next area. The goal is not a perfect document on day one. It is a habit where the spec is the source and the pipeline keeps it true.
What would change on your team if every area had a clear artifact and the pipeline refused to merge when that artifact was out of date?
]]>