The first version is ready. Much sooner than it would have been without AI. If you work with these tools, you know the moment: you see the result and immediately think about everything else you could now do.
That is a good moment to pause. Something on screen already looks finished, while you still need to understand it. What assumptions does it contain? What has been simplified? Does the solution still work when someone does something other than what was expected?
AI makes us faster. We experience that in our work. At the same time, review and corrections take more effort. Some of the time we gain goes back into that work. Turning a first draft that is ten times faster into an assumption of ten times more capacity leaves a substantial part of the work out of the calculation.
The fast part is easy to see
You can click through a prototype. Research produces a finding. A feature runs. All of that is visible and feels like progress. The checking behind it has fewer moments to show off. You read, question, test and sometimes discard a solution that looked convincing a moment ago.
Take a data entry flow in a web app. AI builds a form, saves the input and shows a confirmation. The standard flow works. That tells us little about permissions, interrupted connections or a request submitted twice. Those questions belong to the product, even when the demo looks good without them.
Code written by people needs these checks too, of course. With AI, though, much more code can appear before anyone has followed its decisions in detail. When you develop something yourself, you build that understanding along the way. With a generated solution, some of it has to come afterwards. That takes concentration.
The same prompt is no guarantee
Ask the same question twice and you may get two different answers. That can be useful when exploring ideas. During implementation, it can mean AI makes different assumptions, introduces another library or handles the same edge case differently. The prompt alone does not reliably determine the result.
This is where determinism matters: the same conditions produce the same result. With generative language models, that repeatability is limited depending on the model and its settings. Even options for reproducible output do not always provide a guarantee. OpenAI’s API documentation explicitly acknowledges this limit.
For us, that means recording requirements and verification criteria outside the prompt. AI can run a fixed script, write tests or propose a proof that can be checked. The result needs to stand up against those foundations. Another convincing answer is not enough. And an output that is identical every time can contain the same error every time.
There is room for one more small thing
An extra filter would be handy. An export feature too. And while we are here, AI could build a second view. Each addition seems small because the first implementation takes so little effort.
Together, those additions change the project. The filter needs clear rules. The export must respect permissions. The second view needs the same states as the first. A quick idea creates relationships that someone has to understand and maintain. The problem we originally set out to solve can easily slip into the background.
Then there are the unfinished tasks in your head: one result waiting for review while the next task is already running. You switch between solutions, each with its own context. A productive day can end up feeling surprisingly demanding. The very fact that more is possible creates pressure to make use of it.
An eight-month study by UC Berkeley Haas at a technology company describes a similar pattern: more parallel tasks, a broader scope of work and work reaching into what used to be breaks. This is an observation from one company, not a universal verdict on AI. For us, it brings an important question into focus: how much extra work can the increase in speed actually support?
Review starts with the first change
“We will look through it all again at the end” sounds reasonable while you can still picture what will exist by then. But when changes keep piling up, the final review becomes a reconstruction. Why is this dependency here? Which feature uses it? Was this exception intentional or something AI proposed?
Catching up on that understanding is difficult. The next change already builds on decisions nobody has properly assessed. A correction in one place can affect another part of the system whose connections still need to be discovered.
That is why review needs to happen from the start. For us, this means understanding manageable changes, checking important assumptions and recording why a decision was made. An explanation from AI can provide a starting point. We have to compare it with the actual code, the requirements and the behaviour we observe.
The effort depends on the possible consequences. A discarded layout option needs a different level of scrutiny from a change to access permissions. What matters is that the next task builds on a state we understand. Review is part of development and needs time allocated to it.
It runs. Are we allowed to use it this way?
Even when a feature works well technically, another question remains: what have we actually incorporated? A new library comes with licence terms. A generated passage of code may match existing public code. If we do not know these components, we lack the basis for assessing their use.
AI-generated code is not automatically free of third-party rights. Equally, a similarity does not automatically amount to infringement. The specific passage, any applicable rights and the relevant terms all matter. For included libraries, for example, we need to know which notices must be retained and what obligations our use creates.
This is a practical issue, as GitHub’s code referencing feature illustrates: it can flag matches with public repositories and provide available licence information. Tools like these help with checking. The absence of a flag does not establish that every question about origin and licensing has been resolved. That needs its own review, with legal support where legal questions remain open.
The model does not take our place in court if a dispute arises. Responsibility and potential liability concern people and organisations; who is liable depends on the case. The consequence for our work is clear: we need to explain what we use. Pointing to AI does not replace that. We explore the broader questions of authorship and usage rights in our Insight on rights to AI-generated design.
Speed needs an honest calculation
We are excited about these possibilities. In our article on how we work with AI, we describe what it can contribute to ideas, early tests and different perspectives. That makes it all the more important to use it in a way that works over time.
That means staying focused on the actual goal, limiting parallel tasks and planning for review. A team also needs to be able to say: this is enough to answer the question. The next variation or extra feature can wait. Time gained can go into refinement and focused work without immediately justifying a higher workload.
Anyone expecting ten times more output needs to explain who will understand and review it. That question also belongs with the people who plan projects and lead teams. Keeping responsibility with people while removing the time they need to exercise it does not add up.
Ultimately, we want to hand over a solution we can explain, develop further and stand behind. How quickly the first draft appeared is only one part of its story.
