The bottleneck is not building anymore; I think we can all agree on that by now. Writing code by hand, and even reading AI-generated code, is not economically scalable (as DHH himself said recently).

This means creating software has become much easier. However, it does not mean that creating software that solves complex problems or is delightful to use, is that much easier than before. Yes, one part of the process is faster, but the really hard part is not. Understanding customers’ challenges and users’ needs, separating signal from noise, and making a chain of good decisions that produces something worth using: that’s still the real challenge.

But how do we adapt our product workflows to this era? Well, I don’t know, and I think nobody has the definitive answer just yet. But I do have an idea. I’ll start from the point where we already know what we want to build; how we get there is a topic for another day.

There are three major steps in the building process: shape it, build it, release it.

Step 1: Shape the thing

This is your old-school PRD. And I don’t think it’s going anywhere soon. But it is changing.

Normally, the person responsible for this step is a PM. This person needs to understand the user’s real problem and the business opportunity, how other areas or features would be affected, what the impact could/should be, and finally decide what the functional solution is.

This person goes to a bunch of meetings, creates a prototype or two, discusses it with users and stakeholders, uses AI to understand how the current product works, etc. All of this to produce a document that should describe what we need to achieve, not how to build it.

Prototypes are accepted (and sometimes even expected), detailed Figma designs are welcome, and references to the codebase are OK, but only as references to things that exist right now.

Step 2: Implement the thing

This is where the engineer comes in.

The engineer reads the PRD and understands the business objective. Then she works in a loop:

  1. Discuss possible solutions with AI, weigh pros and cons, and make the high-level architecture decisions.
  2. Have AI draft an implementation plan, then read it carefully and adjust it.
  3. Delegate the writing to an agent.
  4. Compare what was built with the plan, and adjust.
  5. Run a code review with another agent, and tweak again.

Finally, the engineer tests the thing she just built. And when I say test it, I mean fully test it. Use it. Experience it. The job is to find all the small stuff the agent didn’t do properly and fix it until the output is excellent. Then, and only then, she hands the feature back to the PM, designer, or whoever needs to check it.

Engineers don’t need to understand the code line by line. That’s in the past. But they do need to understand how the system works and how each moving part relates to the others, and they should be able to clearly explain it to someone else.

Step 3: Release the thing

This isn’t new at all. But since code is being written much faster and isn’t even being reviewed by a human, this step matters more than ever.

Ideally, you don’t release what you just built to all your users at once. Launch first to some beta testers or a limited segment: gather feedback, see how the product behaves, and then start releasing in batches.

Don’t skimp on monitoring and user analytics tools. Use them, and set up automations to watch for errors and changes. Since your engineers are writing less code, demand that they stay on top of these tools and continuously improve your codebase.

So… Where this leaves us (us humans)?

Code got cheap. Judgment didn’t. We humans aren’t disappearing from the process; we’re moving to where it matters. We decide what’s worth building, we decide how it should fit together, and we decide whether the result is actually good. AI does the heavy lifting.

This is my current thinking, not my final answer. At the speed this technology is moving, nobody knows what will still hold six months from now.