Take Life on your Feet

One of the things I have been thinking about lately is how AI-assisted development is changing where engineering effort needs to be applied.

Historically, a large portion of software engineering effort centered around implementation:

• writing code,
• reviewing code,
• fixing code,
• and refining implementation details after development had already started.

AI changes that equation.

The speed at which code can now be generated means that ambiguity in requirements becomes dramatically more expensive. A human developer can often fill in missing context or infer intent from incomplete requirements. AI generally cannot — it will implement exactly what was specified, including the gaps.

That shifts engineering rigor upstream.

The organizations that succeed with AI-assisted development will likely not be the ones generating the most code. They will be the ones producing:

• clearer requirements,
• stronger architectural guidance,
• more explicit constraints,
• better acceptance criteria,
• and more complete test strategies.

I also think this changes how we should think about code reviews.

You cannot “review quality into” a product after implementation. Code reviews have always been most effective as:

• mentorship opportunities,
• architectural alignment,
• knowledge sharing,
• and maintainability checks.

I do not see that changing.

What may change is where the review effort is focused.

If AI can generate large volumes of implementation quickly, then the highest-value review activity may increasingly become:

• reviewing requirements before implementation,
• reviewing assumptions,
• reviewing specifications for ambiguity,
• validating acceptance criteria,
• and ensuring architectural intent is clearly defined before code generation begins.

In other words:
Poor requirements amplified through AI become poor software at scale.

Good requirements amplified through AI may allow teams to move dramatically faster while maintaining consistency and quality.

One area where I think we still have room to improve organizationally is in how we write and review requirements. We often invest significant effort reviewing implementation details after code exists, but comparatively little effort validating whether the original requirements were:

• complete,
• testable,
• unambiguous,
• operationally safe,
• and architecturally aligned.

As AI tooling becomes more integrated into development workflows, I suspect that imbalance becomes increasingly costly.

I do not think this reduces the importance of engineering judgment or senior technical leadership. If anything, it increases it. The value shifts from simply producing code toward:

• defining systems clearly,
• constraining behavior correctly,
• validating intent,
• designing meaningful tests,
• and ensuring long-term maintainability and operational understanding.

That feels like an important shift worth recognizing early rather than reacting to later.