Throwing Out the Rule Book

We’ve been told for decades that building software is slow, expensive, and requires a village. AI has changed the game. Every step in how we build for the web was designed around a set of constraints that no longer exist. We assumed building was slow. We assumed specialists were necessary. We assumed coordination overhead was the cost of doing business. None of that is true anymore.

The Idea

The traditional model says ideas come from market research and business cases. The new reality is that ideas can be validated in hours. I’ve gone from "I think this workflow is broken" to a working prototype before lunch. The cost of testing an idea has dropped so close to zero that the old gatekeeping process is now pure friction. The question isn't "is this idea worth building?" anymore. It's "is this idea worth the twenty minutes it takes to find out?"

The Product Owner

Product ownership emerged because we needed a translation layer between human problems and structured requirements. User stories, acceptance criteria, prioritized backlogs—it was all overhead for a world where building was hard.

That layer is collapsing. When you can describe a problem in natural language and get working software back, the role shifts from managing tickets to extreme clarity of intent. The product owner of 2026 isn't writing stories; they're sitting next to the user, iterating on a live prototype, and shipping when it works. The skill is still judgment. Prompting is just thinking clearly.

UX and Design

Here's where it gets uncomfortable. The UX process we've built over the past fifteen years, research, wireframes, design systems, pixel-perfect handoffs, was a response to how expensive it was to change things once they were built. You front-loaded the design work because rework was painful. Discovery sprints existed because building the wrong thing wasted months.

When building the wrong thing wastes an afternoon instead of a quarter, the entire upstream design process needs rethinking. I'm not arguing against understanding users. I'm arguing against the six-week discovery phase that produces a deck nobody reads before anything gets built. When you can put a working prototype in front of a user on day one and iterate from their actual reactions, the research-then-design-then-build waterfall, even when we called it agile, stops making sense.

Design systems still matter. Consistency still matters. But the static mockup as an intermediate artifact, the Figma file that gets "handed off" to a developer who then rebuilds it from scratch, that's a workflow designed around the limitation that building was slower than drawing. That limitation is gone. Build the real thing. Put it in front of people. Iterate on what exists, not what's imagined.

Development

The act of writing code is no longer the bottleneck. Human code reviews, sprint planning, and velocity tracking are now measurement rituals for a resource allocation model that has evaporated. When a single developer with an agent can ship what used to take a team, the unit of planning isn't the sprint—it’s the problem.

The "tech stack" is also irrelevant. The AI doesn't care about the stack, but we must care about the architecture. Our role shifts from typing code to guiding the "dark matter" it generates. Architectural oversight is the new mentorship; the goal is ensuring speed doesn't become a spaghetti mess that works.

QA and Testing

Traditional QA sits at the end of the pipeline. In the new world, the AI writes tests as it writes code—not because of discipline, but because it doesn't know how to be lazy. This shifts the human role from "finding bugs" to "auditing intent."

Testing is no longer a dedicated phase; it's continuous and woven into generation. The real verification happens in the wild. Observability and real-time user feedback are the new pre-release testing. If it breaks, we observe and fix it in minutes.

The New Rule Book

Everything we added on top—the handoffs, the specialised roles, the tooling bureaucracy—was scaffolding for a slower era. The default should no longer be the heavy process. It should be the simplest thing that works.

  1. If it takes longer to design than to build, build it.
  2. Validation beats verification.
  3. Architecture is strategy; code is just an implementation detail.

The rule book served us well when the constraints were real. Now that they're gone, the only thing slowing us down is the habit of following it.