{
  "id": 737667,
  "title": "Build Wide, Ship Narrow: How AI Changed the Economics of Code Review",
  "url": "https://urgent.news/2026/08/13/build-wide-ship-narrow-how-ai-changed-the-economics-of-code-review",
  "topic": "ai",
  "section": "AI",
  "published": "2026-08-13T06:15:43.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/trismegistus/build-wide-ship-narrow-how-ai-changed-the-economics-of-code-review-11p2"
  },
  "original_language": "en",
  "account": "The old approach to software development required engineers to decide boundaries before they started building. Developers would write an RFC describing the feature, split it into smaller issues, and build them sequentially. This structured workflow kept code reviews manageable and avoided big-bang merges, but it also asked engineers to make critical structural decisions without knowing much about the problem at hand. Sometimes these assumptions turned out to be wrong, leading to wasted effort and the need to discard previous work.\n\nHowever, the economics of code review have shifted dramatically in recent years. Three major factors have become dramatically cheaper: building code using AI assistants, designing plans that can be reshaped at conversation speed, and splitting finished branches into small PRs. These advances have made it possible to build wide and ship narrow, a workflow that combines building functional code with early product validation.\n\nIn this new approach, the design process still comes first. Before touching the editor, a plan is created through adversarial rounds that challenge the idea. Once the plan is solidified, the design is committed as a spec, even before any code is written. This spec serves as a foundation for building wide, committing save points as you go, and demoing the feature before anyone reads a line of code.\n\nThe key change is that after the design is settled, engineers build the feature end-to-end without stopping to open PRs and wait for review. Commits serve as save points, proving concepts or indicating risky experimental changes. This wide-building approach allows for rapid iteration and real-time feedback. Once the feature works end-to-end, it is demoed to stakeholders, avoiding lengthy review cycles on a flawed direction.\n\nFinally, the AI-powered splitting of the finished branch into a sequence of small, independent PRs enables narrow shipping. These PRs are cut fresh from the main branch, each representing a clean, reviewable change. The natural seams in the code reveal the appropriate boundaries, eliminating the need for pre-decided boundaries. The result is a review process that focuses on narrow, understandable changes, maximizing the value of human code review while minimizing the time spent on narrow PRs.",
  "summary": "The Old Way: Decide Boundaries Before You Build Good engineers plan before they build. The traditional workflow goes: write an RFC describing the feature, split it into smaller issues, then build them sequentially — each issue often blocking the next. The structure of the work was locked in before a single line of code existed. This approach is reasonable. It keeps code reviews manageable and…",
  "key_points": [
    "AI assistants now make building code dramatically cheaper.",
    "Design process involves adversarial rounds and solidified specs before coding."
  ],
  "editors_take": "The shift in code review economics, driven by cheaper AI-assisted building, planning, and splitting, lets engineers validate products early and build iteratively, reducing wasted effort and lengthy review cycles.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}