Is “Blocked Waiting for Design” Becoming Obsolete? Provisional Implementation in the AI Era

The other day, I was watching a YouTube video about problems engineers encounter at work.

The design lead was behind schedule and rarely responded to questions. As a result, the programmer could not proceed with the implementation.

Later, however, the design lead reportedly said, “You should have gone ahead with the parts you could reasonably anticipate,” which infuriated the programmer.

“I was waiting because the design wasn’t finished. Why am I the one being blamed?”

The programmer’s anger is certainly understandable. It looks as though the design lead is ignoring their own delay and shifting the responsibility onto someone else.

As I watched the video, however, a different thought occurred to me.

Now that we can use AI, was there any need to wait for the design in the first place?

In the Past, Waiting Was the Rational Choice

In traditional software development, proceeding with implementation before the specifications were settled was risky.

Code that took hours to write could be rendered entirely useless by a design change.

Worse, if you made your own assumptions and turned out to be wrong, you could be held responsible.

In that case, waiting until the design was finalized was the safer choice.

Minimizing rework was a basic principle of efficient development.

AI Has Changed the Cost of Rework

The arrival of AI coding agents, however, has begun to change the situation.

Even if the specifications are vague, when you can make a reasonable assumption, you can simply build a provisional version.

If the formal design arrives later and differs from your assumptions, you can ask the AI to revise the implementation.

Changes that once took hours can now often be completed in a short time.

Of course, AI-generated code still needs to be verified, and some elements—such as database design and external interfaces—cannot be changed casually.

Even so, there is no doubt that the cost of provisional implementation has fallen dramatically.

In the past, preventing rework was the rational approach. Today, there are more situations in which it is rational to accept rework and move ahead.

Do Not Proceed Silently—State What You Are Doing

If I were in that position, I would send the design lead a message like this:

“Because the design has not yet been finalized, I will proceed with a provisional implementation based on my current assumptions. I will make any necessary changes once the official specifications are decided.”

That message alone changes the situation considerably.

You are not sitting idle. At the same time, you have not unilaterally declared the specifications final.

You make it clear that the implementation is provisional and use the time before the design is finalized productively.

If the specifications change later, you can ask the AI to modify the relevant differences.

At the very least, it leaves the design lead far less room to blame you by asking, “Why haven’t you made any progress?”

Move the Work Forward Instead of Arguing About Who Is Right

What is interesting about this story is that the question of who is at fault—the design lead or the programmer—and the question of what action is rational do not necessarily have the same answer.

The design lead is at fault. Therefore, the programmer waits for a response.

That reasoning is perfectly consistent.

But being logically justified is not the same as acting in your own best interest.

If AI has reduced the burden of provisional implementation, moving ahead may ultimately make your own work easier as well.

Keep the work moving and revise it later.

In the past, we feared specification changes. Today, we have the option of developing on the assumption that the specifications will change.

Having AI produce a provisional implementation is far more constructive than waiting for the design lead’s response while insisting, “This isn’t my fault.”

Of course, none of this solves the underlying problem of the delayed design.

AI merely allows the programmer to move ahead; it does not make the design lead work any faster.

Technological progress is gradually freeing us from having to wait for slow workers. Unfortunately, it does not make the slow workers themselves disappear.