Are technical design reviews disappearing?

Estimated reading time: 8 minutes

Key takeaways

• Agents shorten the path from requirements to code, not the need for sound technical design.
• Better architectural context helps agents make more informed decisions, but does not guarantee they will choose the right technical approach.
• A lightweight, risk-based review can preserve the useful design discussion without bringing back a heavyweight process.

---

There was a team working on a mid-sized feature that touched several services and required changes to multiple data models. The product requirements were clear enough for a coding agent, or a few of them working together, to make changes across multiple repos and produce a series of plausible pull requests (PRs).

As the changes moved into code review, a couple of reviewers shared concerns in a group chat. Some assumptions embedded in the code seemed to reflect patterns from individual codebases rather than the organization’s broader practices. The implementation also neglected precautions normally taken on critical paths in this system.

The org was experimenting with agentic workflows, and this feature had gone straight from a product requirements document (PRD) into code. The usual technical design review through a request for comments (RFC) had been skipped. The requirements explained what the feature needed to achieve, but something was missing in translation.

There was general agreement that the code would deliver the requested behavior. The concern was how it would affect reliability and operations.

To keep things moving, the reviewers asked the author for a two-pager describing the intent and approach. That gave them something they could discuss together, rather than trying to reconstruct the design from separate PRs. The discussion slowed the feature down, but it allowed them to revisit the assumptions and bring the approach closer to the org’s architectural principles.

This is a clear reason to evolve technical design reviews, not abandon them. 

Code that delivers the requested behavior is not necessarily the right technical solution to the problem. We still need opportunities to challenge the approach before implementation becomes the only place to discuss it.

Code now arrives before we’ve challenged the design

A technical design review gives an engineer an opportunity to investigate the requirements, consider alternatives, and challenge the proposed approach with people who understand the affected systems. It is a chance to change course before spending much time on implementation.

It may feel at times like coding agents have made that step unnecessary. They can inspect repositories, plan changes, edit files, run tests, and produce PRs. Given requirements and enough context, and with any luck a few architecture decision records (ADRs), they can implement an approach before anyone has had a chance to examine whether it makes sense.

Tools like GitHub’s Spec Kit still separate technical planning from implementation and ask developers to review the output before moving on. That gives the engineer a point to question the approach before generating code.

A plan may thoroughly describe which files to change, which interfaces to introduce, and how to test the resulting implementation. It may be technically consistent and executable. Yet none of that establishes whether the selected approach is the best fit for the problem, whether simpler alternatives exist, or whether important system constraints have been overlooked.

What design reviews were really buying us

For significant changes, a design doc provides a way to examine the proposed approach before implementation. It makes the assumptions, alternatives, and technical reasoning visible, giving reviewers an opportunity to challenge them.

Back in 2020, Malte Ubl described the reasons for doing this early in design docs at Google: finding problems while changes are still cheap, reaching agreement, and considering concerns that cut across the system.

That last point matters particularly for changes spanning multiple services. An approach that makes sense within one codebase may introduce undesirable dependencies, operational risks, or inconsistencies elsewhere. Someone familiar with another part of the system may recognize a constraint that the original author missed.

Of course, design reviews can become overhead. A document that tries to predict every implementation detail will soon be out of date, and collecting approvals does not mean anyone has meaningfully challenged the approach. Ubl also acknowledged that an obvious implementation may not need a design document at all.

More context doesn’t guarantee the right design

There is a reasonable counterargument here. As coding agents gain access to more architectural and operational context, shouldn’t they become capable of producing sound technical designs without requiring human review?

Maybe. A lot of the work around coding agents is focused on giving them better context. We add repository instructions, connect them to ADRs, and make operational guidance available so they can work within the org’s existing practices. Yet access to context does not guarantee that the agent will interpret it correctly or recognize when an existing pattern is inappropriate for a new problem.

There is also the question of how to review that reasoning. Birgitta Böckeler encountered related challenges in her 2025 exploration of Kiro, Spec Kit, and Tessl. Some generated documents were repetitive and tedious to review, and agents didn’t always follow the instructions they contained. She found value in preparing specifications but questioned whether the additional documentation actually improved control over the work.

If reviewers have to work through hundreds of lines of generated implementation steps to identify the decisions that matter, we’ve made their job harder.

Better context may improve the quality of agent-generated designs, but more detailed plans don’t necessarily make those designs easier to evaluate. What reviewers need is a clear explanation of the proposed approach, its alternatives, assumptions, and tradeoffs.

Make the review smaller, not optional

For changes that warrant a technical design review, start with one or two pages explaining the problem, the proposed solution, and why it was chosen over the alternatives.

Agents can help investigate options, evaluate tradeoffs, and prepare the document. What reaches reviewers should make the technical reasoning clear, rather than describe every step needed to implement the solution.

This does not need to happen for every change. Reserve it for work that crosses service or team boundaries, changes persistent data or public contracts, introduces meaningful security or reliability risk, or would be expensive to reverse. Local, low-risk changes that are easy to undo should stay outside the process. Using an agent is not, by itself, a reason to require a review.

A typical design brief would include:

• Problem and constraints: what are we trying to solve, and which technical or operational constraints matter?
• Proposed approach: what solution do we recommend, and why is it appropriate for this problem?
• Alternatives considered: what other approaches were examined, and why were they rejected?
• Key decisions and tradeoffs: what complexity, limitations, or risks are we accepting?
• Failure modes and reversibility: what could go wrong, how would we detect it, and what would recovery or rollback involve?
• Assumptions and open questions: what are we taking for granted, and what still needs validation?

Keep implementation details elsewhere, linking to supporting material when needed. Two pages should encourage focus, not become a reason to omit important risks.

Consider a hypothetical example: a customer-status field used by three services, with a data migration and downstream API consumers.

An agent can make the changes across those repos, but there are several possible technical approaches. Each service could interpret and maintain the status independently, one service could become the source of truth, or the status could be derived from existing data rather than stored separately.

Those alternatives have different implications for consistency, coupling, migration complexity, and failure recovery.

The proposal might recommend keeping one service as the source of truth and preserving the old contract during migration. It should explain why that is preferable to the alternatives, what happens during a partially completed rollout, and how the system would recover if the migration fails.

Another system may need a different approach. Those are the choices the review should examine before they become assumptions repeated across the code.

Keep the discussion lightweight

Start asynchronously, with reviewers who understand the relevant architecture and operational constraints. If an important technical disagreement remains, bring the right people together to examine it.

Not every review requires formal approval. Depending on the org, a meaningful technical discussion may be enough. Stronger controls may be appropriate for regulatory obligations, security-sensitive changes, or decisions that are particularly difficult to reverse.

The design author remains responsible for explaining the approach and addressing unresolved concerns. Generating a document and collecting approvals will not help much if nobody challenges the technical reasoning.

Keep the document afterward as a record of what was decided and why. When implementation changes a major decision, update or supersede it. It does not need to track every task or become another project plan.

Know when your process needs to change

Look at where design discussions happen in your org today. 

If engineers are already evaluating alternatives and identifying important constraints before implementation, there may be little to change. If code reviews repeatedly uncover architectural problems that require significant rework, it is worth examining what was missed earlier.

In practice:

• Look at changes that required late redesign: were reviewers finding implementation defects, or questioning the technical approach itself?
• Examine the alternatives: was the chosen approach evaluated against other viable solutions, or was it simply the first plausible implementation the agent produced?
• Ask the author to explain the tradeoffs: they should be able to explain why they recommend the approach, including where they are uncertain, without relying on the agent to supply the reasoning.
• Check what incidents are telling you: an incident traced to a constraint nobody considered during design is a clear reason to act. Repeated reliability concerns caught during code review are earlier signals; you do not need to wait for a production failure.

If you recognize those patterns, try the shorter review on the next change that meets your risk criteria. Ask for the technical proposal before substantial implementation and focus the discussion on assumptions, alternatives, and failure modes.

Afterward, examine what the review actually changed. Did it identify a missing constraint? Did it lead to a simpler approach? Did it reveal an operational risk? Did it prevent rework that would otherwise have surfaced during code review?

Include the cost of the review itself. If engineers spend time filling out templates but the same architectural problems continue to surface late, the process needs another look.

The opposite signal matters too. If agents consistently propose sound approaches for a particular class of changes, and human reviewers rarely find anything consequential to challenge, consider reducing the review requirement. Continue tracking the quality of those decisions, including problems discovered during implementation or in production.

Technical design reviews will keep evolving. The question isn’t whether they’ll survive the agentic era but rather how we keep challenging the technical decisions that matter.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.