Why Implementing AI Is Like Throwing Pasta
There is an old way of testing whether pasta is cooked: take a strand, throw it against the wall, and see if it sticks.
A surprising amount of corporate AI adoption works the same way. Buy a copilot, deploy a chatbot, give employees an AI assistant, run an agent pilot, add AI search, or put generative AI into an existing product, then wait to see whether anybody uses it.
If they do, the AI “stuck.”
The problem is that sticking is a very low standard for success. An AI tool sticking inside an organization tells you that people found a reason to use it, but it does not yet tell you whether the organization became better at anything.
That distinction matters because the pressure to do something with AI is real. Competitors are talking about it, vendors are adding it to existing products, employees are already experimenting, boards want an AI strategy, and executives do not want to discover too late that an important technological shift happened around them.
So organizations buy AI first and work out what it is for afterward.
The sequence is understandable:
AI is important
↓
We should have AI
↓
Buy some AI
↓
Put it into the business
↓
See if it sticksSometimes it does. The more important question is what sticking actually proves.
When the Technology Comes Before the Problem
Once an organization decides that it needs AI, almost every workflow starts looking like an AI opportunity.
Customer questions can have a chatbot. Meetings can have summaries, developers can have copilots, sales teams can generate emails, support tickets can be classified, documents can be analyzed, and internal knowledge can be searched conversationally.
Some of those applications may be excellent. The problem is not the technology itself; it is that the category of solution has already been selected before anyone has established what needs improving.
Nobody begins a serious strategy meeting by declaring that the company needs to use more databases. Organizations do not normally set objectives to increase API adoption or maximize the number of cloud services employees interact with.
Those are capabilities used when they help solve a problem. AI should be treated the same way.
Suppose customer-support costs are increasing because agents spend too much time searching several systems for the information needed to answer routine questions. That gives an AI search or retrieval system a specific job: reduce search time without reducing answer quality.
Compare that with buying an AI support platform and then looking around for somewhere to deploy it. The same technology may eventually appear in both cases, but only the first path gives the organization a reason to know whether it worked.
The difference seems small at the beginning. It becomes much larger when someone eventually asks what value the AI created.
Sometimes AI Sticks Because the Bad Process Is Still There
Generative AI is unusually good at working with messy processes. It can interpret emails, summarize documents, extract information from inconsistent formats, rewrite text, classify requests, and transfer information between systems.
That makes it useful. It also makes AI remarkably good at preserving work that should perhaps have disappeared.
Imagine a company receiving thousands of customer requests by email. Employees read each message, identify what the customer wants, copy the relevant information into another system, and route the request to the correct team.
AI appears to be an obvious solution. A model can extract the information and classify the request, while another component can determine where it should go.
But perhaps customers send unstructured emails only because the company’s website never asks them for the information required to process the request. A better form with validated fields could remove most of the classification problem entirely.
The AI implementation could work perfectly and still be the worse solution.
The same problem appears with internal work. If employees spend five hours every week producing a report that almost nobody uses, reducing its production time to thirty minutes is technically an improvement. Removing the report saves even more time.
Starting with “where can we use AI?” makes both examples look like AI opportunities. Starting with “what are we trying to improve?” leaves open the possibility that the best AI implementation is no AI at all.
Sticking Proves Adoption, Not Value
Suppose a company gives an AI assistant to 2,000 employees. Six months later, 1,200 have tried it, 600 use it every week, satisfaction is high, and employees have generated tens of thousands of prompts.
The pasta stuck.
Those numbers are useful because adoption is one thing an organization needs to understand. A system nobody uses is unlikely to create much value.
But usage does not complete the argument.
Perhaps employees are completing work faster. Perhaps the quality of that work has improved, customers are getting quicker responses, or scarce specialists can now handle more cases.
Or perhaps employees are using the assistant extensively without any meaningful change in the outcome the business cares about.
A sales team can enthusiastically adopt an AI email generator and produce twice as many messages. If response rates fall and qualified meetings remain unchanged, the system successfully increased email production while doing little for sales.
A customer-service chatbot can report a high containment rate because most conversations never reach a human agent. If customers repeatedly return because their original problems were not resolved, containment is measuring where conversations ended rather than whether service improved.
AI products naturally make their own activity visible. They can count active users, prompts, generated documents, conversations, tasks, and tokens.
Those metrics describe the AI system.
The business needs to know what changed because the AI system exists.
A Task Can Improve While the Workflow Does Not
This becomes harder because AI can be genuinely impressive at the task assigned to it.
A coding assistant may generate code much faster than a developer can type it. If software delivery is actually constrained by slow reviews, unstable test environments, cross-team dependencies, or manual deployment approvals, faster code generation simply moves more work toward the same bottleneck.
The AI worked. The delivery system did not become meaningfully faster.
Verification creates a similar problem.
Suppose an AI system generates a customer response in five seconds instead of an employee taking five minutes to write it. That sounds like an enormous productivity improvement until the employee has to verify the facts, check customer history, remove an unsupported claim, correct the tone, and make sure the response complies with policy.
The new process can still be better. The important point is that the work did not simply disappear; some of it moved from creation into verification.
That movement becomes increasingly important as the consequences of error increase. A slightly inaccurate meeting summary and an inaccurate legal, financial, medical, or security decision do not have the same cost.
This is why measuring only the AI-controlled step can create spectacular productivity numbers without spectacular productivity.
The useful chain is longer:
AI capability
↓
Task changes
↓
Workflow changes
↓
Operational result changes
↓
Business outcome changesEvidence at one level does not automatically prove the next. A good model can support a poor workflow, and a faster workflow can optimize an outcome the business did not particularly need.
Throwing Pasta Is Sometimes Exactly the Right Approach
None of this means organizations should stop experimenting with AI.
In fact, there are circumstances where “see what sticks” is a perfectly rational strategy. New capabilities often reveal uses that nobody could have specified confidently in advance, and employees working directly with a tool may discover opportunities that an executive AI committee would never have found on a whiteboard.
Suppose a company gives a small group of employees access to a low-cost AI assistant. Sensitive data is appropriately controlled, the tool cannot take consequential actions, the cost is modest, and the decision can easily be reversed.
There may be no need for a detailed business case before anyone touches it. Let people experiment and see what they discover.
That is cheap exploration.
The problem begins when the same logic is applied to decisions that are expensive, deeply integrated, difficult to reverse, or capable of causing significant harm. Buying a low-cost assistant for a small team and deploying an autonomous agent that can change customer accounts are both AI experiments, but they should not require the same evidence.
The more consequential the implementation becomes, the less useful “it seems to stick” becomes as a decision rule.
This gives the pasta metaphor an important boundary. Throwing something at the wall is a reasonable experiment when throwing it costs almost nothing and cleaning it up is easy.
It is a much stranger strategy when the pasta requires a three-year vendor contract, six integrations, a governance program, months of employee training, and permission to issue refunds.
A Pilot Should Reduce Uncertainty, Not Just Survive
AI pilots can make the sticking problem worse because pilots are often treated as miniature implementations whose purpose is to succeed.
They should be experiments whose purpose is to teach.
A pilot operates under unusual conditions. Participants may be particularly motivated, leadership is paying attention, the vendor may provide additional support, scope is narrow, awkward cases can be handled manually, and the team that designed the experiment is nearby when something goes wrong.
Those conditions can disappear at scale.
So “people liked the pilot” is useful evidence, but it does not answer whether the capability will produce enough value under normal operating conditions to justify becoming permanent.
A useful pilot begins with something the organization does not know.
Can AI reduce contract-review time without increasing missed high-risk clauses? Can an assistant help support agents find answers faster without increasing repeat contacts? Can a coding tool reduce delivery time rather than merely increasing code output?
Those questions make failure informative.
Perhaps employees like the tool but verification consumes almost all of the time saved. Perhaps the model performs well but integration costs destroy the economics, or perhaps the original problem turns out not to be important enough to justify changing the workflow.
Stopping after discovering any of those things is not a failed experiment. The organization spent a limited amount to avoid spending much more.
This is also why a successful pilot should not automatically become a production commitment. An experiment may prove that better knowledge retrieval creates substantial value without proving that the vendor or prototype used in the experiment is the right way to provide that capability at scale.
The pilot should create evidence. Scaling is a separate decision made with that evidence.
Start With What Needs to Change
The simplest way out of pasta-wall AI strategy is not a complicated implementation framework. It is changing the first question.
Instead of asking departments where they could use AI, ask where important work is currently too slow, expensive, unreliable, difficult to scale, or dependent on scarce expertise.
That produces a portfolio of problems rather than a shopping list of AI products.
Once a worthwhile problem is visible, the organization can establish how the current process performs and what improvement would actually mean. Only then does it make sense to compare possible interventions.
Sometimes the answer will be AI. Sometimes conventional software, workflow redesign, training, better data, or simply removing unnecessary work will be cheaper and more reliable.
If AI looks promising, the next step is not to prove that AI is the future. It is to run the cheapest experiment capable of reducing the uncertainty that matters.
A useful progression is:
problem → desired outcome → current baseline → possible intervention → AI experiment → evidence → stop, change, or scale.
AI is still central where it deserves to be. It simply no longer gets to occupy the first position by default.
That change also makes success easier to discuss. If the original problem was support cost, measure whether the relevant support economics improved without unacceptable damage elsewhere. If the constraint was review time, measure the complete review process rather than generation speed. If the objective was additional capacity, determine what the released capacity actually enabled.
There is no universal AI ROI metric because AI is not a universal business objective.
An AI Collection Is Not an AI Strategy
Without this discipline, AI portfolios accumulate quickly.
Customer service gets a chatbot, engineering gets a copilot, marketing buys generation tools, finance experiments with document extraction, HR introduces an assistant, and operations starts testing agents.
Each implementation can be individually defensible. Together they can still produce an organization that cannot explain what its AI investment is supposed to accomplish.
That is not necessarily an AI strategy.
It may simply be a collection of things that stuck.
A coherent strategy connects capabilities to outcomes. It explains which important constraints the organization is trying to change, why AI is suitable for those constraints, what evidence would justify greater investment, and what evidence would cause an experiment to stop.
That still leaves room for exploration. In a fast-moving field, some experimentation should be deliberately broad because nobody knows all the useful applications in advance.
The difference is that discovery and commitment are not treated as the same decision.
Cheap, reversible experiments can be exploratory. Expensive, consequential implementations should have a much stronger reason to exist.
After six months, the most important question is therefore not how many employees used AI, how many prompts they generated, or how many pilots survived.
It is much simpler:
What became better because we implemented it?
If nobody can answer that question, the pasta may have stuck beautifully to the wall.
That does not mean it was ever worth throwing.
