Suppose everyone on a product team can produce a working prototype by Friday. On Monday, the same three people still have to decide which idea matters, which version is correct, and which change the company is willing to support.
The prototypes got cheaper. The decisions did not.
My view is that this is where much of the organizational work around AI begins. Making an individual task faster changes the pressure on the people and processes around it. A company has to decide what to do with that change.
The constraint moves
If drafting becomes cheap, review can become the scarce resource. If building a feature becomes cheap, deciding whether to build it becomes more important. If more people can change a system, understanding its behavior and recovering from mistakes become shared problems.
This is not a claim that AI always makes delivery worse. It is a reason to measure the whole path. More output can be useful, wasteful, or actively distracting depending on what happens next.
In earlier product work, another PM and I shared engineers between a product that supported the business and a new initiative. We had to decide which urgent problems took priority and when the new product needed extra capacity to launch. The useful work was reaching a shared understanding of the business, then making the tradeoff.
Generating more tickets or code would not have made that decision for us.
Changing the tools is easier than changing the bargain
Consider a designer who can now implement a small interface change. That creates a possibility. It also raises questions: what can they change, who reviews it, who handles an incident, and what design work do they stop doing to make time?
If the company leaves those questions unanswered, it can end up with a new obligation attached to the old job. The person gets another tool and another expectation, but no clearer authority or additional time.
I would start with a small change to the way work moves. Give a team a bounded class of changes, a working test environment, an agreed review path, and an owner after release. Then observe what becomes easier and where the waiting moves. Let the evidence shape the role before rewriting the title.
Capability has to survive the handoff
A good demonstration shows what a skilled builder can do. A useful organizational capability survives when that person is unavailable.
That makes maintenance part of learning. Can another person inspect the system, understand a failure, change it, and tell whether the change helped? Can the team explain why it permits one action and refuses another?
In my company-brain implementation, local review found that a permission-blocked alert could still be marked delivered. The access decision and the operating record disagreed. Fixing it meant understanding both. A tutorial that ended at a plausible answer would have missed the problem entirely.
This is the kind of detail I want a team to be able to work through. Knowing the name of the framework is less useful than knowing how to investigate the system in front of you.
Ask what the saved time is for
Suppose a team really does free up capacity. Leadership still has a choice: improve quality, serve more customers, test more ideas, reduce workload, or reduce cost. Those choices create different jobs and different incentives.
If employees are asked to report time savings without knowing how the information will be used, reluctance should not automatically be diagnosed as a skills problem. Management has a conversation to have. Training cannot do that work on its behalf.
There is also a product question. At Airo, users initially found the measurements interesting, then found them less useful. Interviews helped us see that the numbers needed to lead to something they could act on. More output alone was not the answer.
I would apply that same scrutiny inside a company. What decision gets better? What customer problem gets solved? What responsibility can the team now take on?
Cheaper execution gives a company more options. The advantage comes from choosing well and organizing people so those choices become finished work.
For the practical side, see the guides to AI adoption and team design.