AI Made Implementation Blazing Fast—and Filled My Backlog with Tasks Waiting for Decisions

Lately, I have noticed something strange at work.

More and more tasks are sitting in a “waiting for requirements” state.

Of course, this is nothing new. You send a question to a client, then the task remains blocked for several days while you wait for an answer. It is a familiar sight in the IT industry.

But recently, they have come to account for a noticeably larger share of my backlog.

When I thought about why, I realized the cause was AI.

Since I began using AI seriously in development, implementation has become extraordinarily fast. A change that once took half a day can now be finished in a short time. AI can write the tests, run them, investigate failures, and fix the cause.

As an engineer, I am grateful for that.

But making implementation faster does not make the entire project faster by the same proportion.

Once AI had cleared tasks at tremendous speed, the last problem left was a human one:

“So, what exactly should the system do?”

Code Can Be Written Quickly, but Requirements Cannot Decide Themselves

Suppose there are two possible ways to implement a feature.

Technically, either one will work.

In the past, building even one option took time. We had to design it, write the code, test it, and fix the bugs. While that work was underway, discussions with the client could continue. The slowness of implementation and the slowness of decision-making were mixed together.

AI disrupts that balance.

“We can build option A.”

“We can also build option B.”

“Which one do you want?”

We reach that point astonishingly quickly. Then both the AI and the engineer come to a stop.

There is nothing more to do until the client decides.

You can put a powerful engine in a car, but it still cannot move if no one has decided whether to turn left or right.

AI has made the accelerator incredibly powerful. Humans are still holding the steering wheel.

In-House Products Can Still Move Faster

This is where in-house product development and client work differ considerably.

With an in-house product, the decision-maker is usually close by.

“Wouldn’t this screen work better this way?”

“Let’s try it.”

That may be all it takes to move forward.

You can have AI implement the idea and test it the same day. If it does not work, you revert it and build another version.

As implementation costs fall, “let’s build it and see” becomes a realistic option.

Client work is where the real problem appears.

The Moment the Ball Is in the Client’s Court, AI Becomes Powerless

In client projects, the development team cannot decide the requirements on its own.

We ask, “In this situation, should the system behave like A or B?”

Then the long process begins.

The person in charge cannot decide alone. They ask their manager. They consult other departments. Sometimes they must also speak with another department that will actually use the system, or with the end users themselves.

A meeting is scheduled. Some people prefer A. Others prefer B. Someone may even say, “Shouldn’t we reconsider the premise itself?”

Several days later, the answer is: “We will continue discussing it internally.”

No matter how intelligent AI becomes, it cannot do anything during that time. A next-generation Claude or a smarter ChatGPT cannot end the client’s meeting on its own and make the decision for them.

The speed of writing code has multiplied. The speed at which people reach agreement has not changed.

In Truth, Nothing Has Changed

When you think about it, development has been stopping because of undecided requirements for decades.

It happened in the waterfall era. It continued with agile development. It remained after the move to the cloud. And it is still here in the age of generative AI.

Software development has never been difficult only because of programming. People still have to decide:

• What are we building?
• How should it behave in this situation?
• Whose needs take priority?
• Who is responsible when something goes wrong?

AI has accelerated only the code-writing part so dramatically that an old problem has become much easier to see.

When an entire highway is congested, it is hard to tell where the true bottleneck lies.

Now imagine that AI suddenly turns the implementation section into a ten-lane highway. Traffic races forward, only to pile up at the single tollbooth that has always been waiting farther down the road.

That tollbooth is the process of deciding requirements.

It has not become slower. We simply reach it so quickly that the old bottleneck is now impossible to miss.

Then Use AI to Help People Decide

Still, it would be disappointing to stop at “We cannot do anything until the client decides.”

If AI has made implementation cheaper, we can use that advantage to support decision-making itself.

A written explanation might say:

“With option A, pressing this button takes the user to a confirmation screen.”

“With option B, it performs the action immediately.”

That kind of abstract discussion often goes nowhere. So why not build both?

In the past, someone would have said that implementing two versions merely for comparison was a waste of time. Today, AI can create them.

Prepare simple mockups of options A and B, then ask the stakeholders to try them and choose.

People are not good at discussing something that does not yet exist. It is difficult for everyone to read a written description, imagine the same interface and behavior, and then debate it productively.

Put a working example in front of them, however, and the conversation changes.

“This one is easier to understand.”

“No, this workflow would cause problems for our team.”

“Then let’s change just this part.”

Suddenly, the discussion becomes concrete.

Fast implementation with AI is not merely a way to make engineers’ lives easier. It can also be a tool that helps people make decisions.

Which Skills Lose Value—and Which Gain It—in the AI Era

Seen this way, we can also see where the value of engineers may be shifting.

The ability to turn a clearly written specification directly into code is becoming less valuable. AI is catching up in that area at tremendous speed.

Meanwhile, the value of being able to say the following is increasing:

“This requirement leaves an important question unanswered.”

“These two requirements contradict each other.”

“A written discussion was not getting us anywhere, so I built mockups of both options.”

“Let’s try them and decide.”

In other words, the emphasis is shifting from the ability to write code toward the ability to turn ambiguity into something concrete and help people reach a decision.

There is some irony in this.

I once thought that as AI advanced, IT development would become more mechanical and the messy human elements would fade away. The opposite happened.

AI dealt with the mechanical part—writing code—first.

What remained was the deeply human work: talking with clients, organizing stakeholders’ opinions, making vague requirements concrete, and moving decisions forward by showing people something that actually works.

It only seemed as though my backlog had suddenly filled with tasks waiting for requirements. Decision-making had not become slower. AI had simply cleared everything in front of the old traffic jam at blazing speed, leaving the bottleneck fully exposed.

Then I Realized Something

After writing all of this, I noticed something.

Isn’t this exactly what people in the AI industry have recently been calling an FDE—a Forward Deployed Engineer?

An FDE works closely with customers, uncovers ambiguous needs, uses AI to turn them into something tangible at speed, and refines the requirements together with the customer by putting a real working product in front of them.

I had spent all this time describing what I thought engineers might become next.

It already had a name.

I set out to write about how quickly AI was advancing, only to discover that the world had already moved faster than I had.