When a team can turn an idea into a working interface in a few hours, it is tempting to start building straight away. In companies that describe themselves as AI-first, analysing the problem and exploring the design can feel like a delay, especially when there is already something on screen that looks close to finished.
That becomes a problem when the team treats the speed of implementation as evidence that it is making good product decisions. A feature can be built quickly and still be difficult to use, duplicate something that already exists or introduce complexity that could have been avoided with a different approach.
I think this deserves more attention in how we talk about AI and product development. There is a lot of value in being able to build faster, but we still need to understand what we are asking people to use and whether we have found a sensible way for it to work.
Building before the solution is understood
Without enough analysis and design, a team can end up solving each requirement separately. Someone asks for another capability, so the team adds a control. A different situation needs to be supported, so it adds an exception. As the requirements grow, the interface becomes a collection of decisions that nobody has considered together.
Take a product where people need to compare several items. The team might build a separate page for each one, then add tabs to make switching easier, followed by a summary panel to help people remember what they saw. That could work, but a comparison view might have supported the original task with fewer steps. The team needs to understand the task well enough to consider that option before investing in the other approach.
The difficulty is that each addition can look reasonable when reviewed on its own. It may even work as requested. The complexity becomes clearer when someone tries to complete the whole task and has to move between screens, remember information or work around inconsistent behaviour.
This is where I want design and analysis to happen. We need to understand what someone is trying to do, how the proposed change fits into the existing product and whether we can simplify the journey before adding more to it.
The pressure to keep producing
If speed of execution becomes the overriding priority, taking time to question a solution can look like a lack of progress. Building another feature produces something visible. Working out that the same need could be met by simplifying an existing flow can take discussion and exploration before there is anything new to show.
AI makes the first option easier to pursue. A team can keep adding to an implementation as new requirements appear, without revisiting the decisions that made those additions necessary. Over time, it may have more code to maintain and more interactions to check, while the person using the product has more to understand.
There are also consequences for reliability. A change may affect behaviour elsewhere in the product, and a shortcut can become something later work depends on. If analysis and testing are repeatedly squeezed out to keep the next release moving, the team risks carrying bugs and technical debt into the work that follows.
Releasing frequently can still be a good way to learn. The question is whether the team can understand and verify the changes it is making, then act on the feedback. Smaller, coherent changes help with that; DORA’s research on working in small batches supports their role in effective delivery, including when teams use AI.
Making room for the decisions that matter
I would not solve this by adding approval meetings around every change. A long process can leave the team waiting for decisions and then rushing the implementation anyway. The useful work is resolving the questions that affect the solution while there is still room to change it.
For a new feature, I would want the designer and developer to work through the journey together, with whoever understands the underlying requirements. They should be able to explain how it fits with what already exists and identify the parts they still need to investigate. A quick prototype can help that discussion, provided the team is willing to revise the approach it demonstrates.
I want to use AI to explore those alternatives as well as implement them. If it makes one version cheap to produce, we can afford to question it, try a simpler approach and compare how each one supports the task. Some of the time saved can then go towards checking the whole experience, including the paths that are less obvious in the first demo.