AI Is Making It Easier to Build the Wrong Thing

Agentic delivery will make execution faster and more abundant. Unless we apply the same intelligence to understanding intent, it will also help us travel much further in the wrong direction.

I have a name for a pattern I have noticed in my own use of AI: the AI rabbit hole.

It normally begins with an idea that is not yet completely clear in my mind. AI produces a plausible suggestion. I think, “Yes, that will do,” and continue building from it. The next output builds on the first, then another builds on that.

Nothing looks obviously wrong in isolation. The work may be well structured, professionally written and technically credible. But several iterations later, I realise there is now a substantial gap between what I originally wanted and what I have actually created.

The AI has not necessarily failed. It has followed the direction I gave it. I simply allowed a provisional suggestion to become an accepted decision without thinking hard enough about whether it reflected my intent.

AI makes that surprisingly easy. It can give an uncertain thought enough structure and polish to make it feel resolved.

Faster execution can compound a weak decision

I see a similar problem in my ServiceNow advisory work.

The difficult part of transformation is not always getting a build project into operation. It is understanding what the organisation should or could be doing in the first place, given its business, industry, systems, people and operational context.

That work is regularly compressed or skipped. Organisations settle for a good-enough interpretation, move into delivery and discover much later that what has been implemented is some distance from what they actually needed.

The old project-management cartoon about the tree swing captured this perfectly. The customer describes one thing, the project leader understands another, the analyst designs something different, and the eventual implementation bears little resemblance to the original need.

AI does not automatically solve that problem. Used carelessly, it accelerates every frame of the cartoon.

It becomes easier to turn assumptions into requirements, requirements into designs and designs into working software before anyone has properly tested the thinking underneath them. The output arrives so quickly that activity can be mistaken for progress.

This is not an argument against agentic delivery

I am strongly in favour of agentic development and delivery.

We should use AI to shorten development cycles, generate code, analyse systems, create tests, produce documentation and carry out increasingly complex sequences of work. Refusing those advantages would make little sense.

But applying AI only to execution leaves half of the opportunity untouched.

We should be applying the same capabilities to context preservation, situational analysis, scenario planning, discovery and outcome definition. AI can help us compare competing interpretations, expose contradictions, trace decisions, test assumptions and explore possibilities that would previously have been impractical.

The purpose is not to make consultants spend longer analysing everything. It is to help them go deeper and become more specific without returning to slow, labour-intensive delivery.

This article is itself an example.

Rather than asking AI to write something from a thin prompt, I used it to interview me. It asked questions, reflected my answers back to me and challenged areas where my position was unclear. I did not need to know every answer, and I was still willing to use its recommendations. But the process forced me to think, form an opinion and decide what I actually believed.

AI was contributing knowledge without being allowed to manufacture my point of view.

Best practice is situational

A recent customer interaction brought this distinction into focus.

The customer repeatedly told us they wanted to go faster. Our initial response was to look at the familiar delivery sequence of workshops, build, user acceptance testing and enablement, then identify where we could compress it.

That was not what the customer was asking for.

They wanted to begin as close to out-of-the-box as possible. Once that became clear, the more appropriate approach was almost the reverse: begin with the out-of-box build, then use testing and enablement to identify the relatively small number of changes required.

The customer had communicated its need. We had interpreted that need through the shape of our existing method.

That does not mean a structured approach is wrong. In another situation, the responsible recommendation might be to push back on a customer who wants to move too quickly and defend a proven sequence.

Best practice is whatever is best for this customer, with these people, in this situation. Sometimes that means following the established method. Sometimes it means tearing it up.

AI is exceptionally good at reproducing established patterns. That is one of its strengths, but it also makes polished, standardised output incredibly easy to produce. If practitioners stop critically reviewing it, we will generate the same best-practice answers repeatedly, regardless of whether they fit the situation.

Genuinely bespoke work does not require rejecting established practice for the sake of originality. It means retaining the parts that apply and departing from them in the right places, for reasons that can be explained and defended.

Some of the most important context is human

The context that changes a recommendation is not always captured in a process document or data model.

It may be tension between two departments, the way a particular leader makes decisions, a history of failed changes or the moment in a meeting when an apparently sensible suggestion does not land.

AI can analyse what was recorded. It cannot yet be relied upon to recognise and responsibly navigate every human dynamic surrounding it.

A technically sound recommendation may still be wrong for a customer whose leadership team is not aligned. A standard transformation sequence may be wrong for an organisation that wants to minimise change. A best-practice design may fail because it ignores how the people expected to use it actually behave.

This is why soft skills do not become less important as delivery becomes more automated. They become part of how AI is steered.

The practitioner must combine what the system can infer with what a human can observe: tension, hesitation, incentives, personalities and the difference between what someone has said and what they are trying to achieve.

Execution is becoming more abundant

As agentic capabilities improve, many execution tasks will become faster and more widely available. That does not eliminate the need for expertise. It changes where expertise creates value.

Agentic coding makes the production of code less scarce, but it increases the importance of engineers who understand architecture, reliability, security, maintainability, data and operational trade-offs. An agent can generate an implementation, but someone must understand the system well enough to steer it and recognise when it has made the wrong compromise.

I think the same pattern will emerge in consulting.

AI will make standard analysis, documentation, design and delivery output more abundant. The practitioners who stand out will be those who understand the customer deeply enough to steer those capabilities towards the right outcome.

That points towards a broader AI-enabled practitioner: someone able to move further across understanding, analysis, design and execution without pretending that access to AI has made deep knowledge unnecessary.

I am still learning what that role requires

I can see part of this evolution in my own work.

AI now enables me to execute build tasks that I could not previously have completed myself. It allows me to apply systems thinking across a wider area and fill gaps in my knowledge while steering the work through the strengths I already possess.

I am far from being the finished version of that practitioner. I am moving in that direction.

I have also strayed too far at times. I have relied on AI’s knowledge and guidance without reviewing it critically enough. Fluency can feel like understanding, particularly when the output is convincing and the work is moving quickly.

The corrective discipline is not simply better prompting. I need to keep developing my own curiosity and knowledge. I need enough understanding to question a recommendation, recognise a weak trade-off and explain why I have accepted one path over another.

The interview approach helps because it forces me to participate in forming the answer. It reveals what I believe, where I am uncertain and where I am relying on a recommendation I cannot yet properly defend.

The objective is not to reject borrowed capability. It is to turn that capability into knowledge and judgement I increasingly own.

Transformation cannot keep resetting its understanding

There is a broader operating-model problem here.

Businesses, industries and operating environments do not change only during designated transformation projects. They evolve continuously. Customer understanding develops, organisational alignment shifts and the appropriate next change moves with it.

Yet consulting relationships are often structured as a series of discrete engagements. Each begins with another discovery exercise, another attempt to reconstruct context and another interpretation of what came before.

The customer pays repeatedly for understanding that should have accumulated.

A stronger model would preserve intent, evidence, decisions and operational learning across those boundaries. Each engagement would begin from a higher level of understanding rather than resetting the relationship to zero.

That does not mean allowing outcomes to change endlessly without accountability. Continuous evolution still needs clear commitments.

There is useful precedent across several disciplines. The Scrum Guide distinguishes a longer-term product direction from the bounded goal of the current cycle. The UK government’s agile-governance guidance combines iterative delivery with explicit decision ownership and measurable goals. Its Magenta Book treats the theory connecting activity to outcomes as something that should be tested and updated as evidence develops. Google’s Site Reliability Engineering guidance uses explicit objectives and measured feedback loops to govern evolving systems.

Although these methods address different problems, I draw the same practical discipline from them: maintain a stable direction while making the current outcome, assumptions, measures and decision owner explicit.

When evidence changes the intended outcome, preserve why it changed and who authorised the decision. Unrecorded drift is moving the goalposts. Evidence-led, authorised revision is learning.

The operating model has to protect critical thought

It is not enough to tell individual practitioners to be more careful with AI.

The system around them should make critical thinking easier to maintain. It should preserve the customer’s intent, retain the evidence behind decisions, surface contradictions and create deliberate opportunities to challenge the proposed direction before rapid execution compounds it.

AI should operate on both sides of delivery: helping us understand more deeply and helping us execute more efficiently.

Human judgement should not be applied only at the beginning as a discovery phase, or at the end as a final approval. It should remain present throughout the relationship, especially when new evidence suggests that the established method or current outcome is no longer appropriate.

I do not think future differentiation will come from having access to an agent that can produce code, analysis or documentation faster. Those capabilities will spread.

It will come from the complete system surrounding that execution: the quality of the intent being pursued, the context retained over time, the judgement applied to each situation, the evidence behind decisions and the ability to convert all of that into operation without losing it at the next project boundary.

The organisations that build that system will not need to choose between speed and thoughtfulness. They will use AI to improve both, while ensuring that faster execution remains connected to an outcome someone has consciously chosen and can still defend.

References

• Ken Schwaber and Jeff Sutherland, The Scrum Guide, 2020.

• UK Government Service Manual, “Governance principles for agile service delivery.”

• HM Treasury, The Magenta Book: Central Government guidance on evaluation.

• Google Site Reliability Engineering, “Service Level Objectives.”