AI is increasingly part of everyday work, and it really does make things faster. But I have noticed something uncomfortable: as work gets quicker, people seem to pay less attention to priorities.

It is particularly noticeable when assigning work and proposing requirements. New features keep getting added, and existing ones keep changing. AI is fast, so we might as well build it and see. Everyone stays busy and output keeps coming, yet it becomes difficult to sit down and think about where we should actually be heading.

We used to worry about moving too slowly. Now I am starting to worry that we are too busy walking to look ahead.

A cyclist carrying a stack of task papers pauses at a fork in the road to consult a map

AI-generated conceptual illustration.

Faster gradually becomes “we can do all of it”

Previously, proposing a requirement meant considering development time. Choosing one thing pushed others back. Some ideas were discussed and then set aside.

Now AI can quickly produce code, screens and demonstrations. Ideas once shelved because they took too long have another chance. That is a good thing.

But another thought can easily follow: if it takes so little effort, why not do it too?

Managers and developers alike can think this way. Seeing how quickly something can be built makes it tempting to skip “is this worth doing now?” and move straight to “when can I have it?”

Some things deserve a quick experiment. Others have simply just occurred to someone. Being the latest idea, or having the loudest advocate, does not necessarily make something the priority.

Less coding time does not remove the rest of the work

I think one thing is easily overlooked: making something cheaper to write does not make its total cost small.

For example, AI might quickly add an entry point to an application. But someone still needs to confirm the rules, test it, consider whether users will find it confusing, check for conflicts with existing features and account for it in future changes.

Likewise, code for a repeatedly revised feature may be quick to change each time. Product, development and testing still need to understand the revision, and documentation and user instructions need updating too.

AI can handle many tasks at once. People cannot necessarily understand that many changes at once. The faster code arrives, the more material may accumulate for people to understand and make decisions about.

Estimating work only by code-generation time makes it easy to underestimate all of this.

Output keeps coming while direction gets harder to see

A finished feature can be demonstrated, delivered and included in a progress report. Sitting down to consider whether it should be built, then deciding to leave it alone for now, looks less productive.

Faster execution may make this difference more pronounced. Add several features today, change a few screens tomorrow, and everyone feels that progress is brisk.

Whether those changes have actually improved the product may not yet be clear. One feature has barely shipped and its feedback is still coming in when work starts in another direction.

After a while, the system contains more and more, yet it becomes harder to say which problem matters most right now.

That is what concerns me: an endless supply of new tasks taking the place of thinking about direction. As long as there is something else to build, we can avoid the uncomfortable question of whether what we are doing is useful.

Faster experiments still need a question

Of course, I do not think every task needs long meetings or a flawless plan before work begins. Many questions can only be answered by building something and letting people use it.

AI lowers the cost of trying things, and we should use that benefit. But before an experiment, we should at least know what we want to find out.

If nobody uses a feature, is its entry point hard to find, or do users simply not need it? Those situations call for different next steps.

If we keep changing the entry point just because that is easy to do, we could stay busy for a long time without addressing the actual problem.

After trying something, we also need time to examine the result: what helped, what did not, and what can be stopped. Continually starting new work makes it hard to say what we have learned.

Keep some of the saved time for thinking

I think wider AI adoption changes the challenge of organizing work. We used to consider how to get things done faster. Now we also need to decide which things should wait even when they would be quick to do.

People leading teams especially should not turn every new idea into an immediate assignment simply because implementation is convenient. When something new interrupts, what happens to the existing priority? There has to be a choice.

The same applies to developers. A change being quick for AI does not make it worth accepting. Asking why it is needed and how it relates to the current goal remains part of the job.

If every minute saved by higher efficiency is filled with more requirements, time to think about direction still does not appear. The tools have changed, but people may simply be staying busy in another way.

I would rather keep some of the time AI saves for understanding problems, observing results and allowing myself not to start immediately.

Moving quickly is good. But after traveling a while, we still need to look up and check whether we are on the road we intended to take.


blog comments powered by Disqus
Fork me on GitHub