There is an odd pressure around product development at the moment.
You can start with a perfectly ordinary business problem and, somewhere along the way, the conversation becomes about where the AI should go.
Could the search be conversational? Could the dashboard have an assistant? Could the workflow become agentic? Could the application generate something? Could the button perhaps sparkle a little more?
Sometimes those are exactly the right questions. Artificial intelligence has opened up product experiences that would have been extraordinarily difficult to build only a few years ago, particularly where language, ambiguity, research or large amounts of unstructured information are involved.
But the presence of a capable model does not make every problem an AI problem.
We have been thinking about this quite a lot because our own products happen to sit at three very different points on that spectrum. Emily, our virtual assistant, could not really exist in its current form without generative AI. Clean Rabbit, our free disk cleaner, deliberately contains none. Our crossword sits somewhere in between: Gemini is useful for creating clues and variation, but our own code decides whether the output can become a valid puzzle.
On the White Rabbit Foundry site we summarise that philosophy as “AI where it earns its place.” Emily is AI to the core. Clean Rabbit has none. The crossword uses it for the part of the problem where unpredictability is actually useful.
That simple distinction has become one of the more valuable product lessons we have learned this year.
The interesting question is no longer whether AI is available.
It is whether adding it makes the product better.
When AI becomes the requirement rather than the solution
Technology goes through periods when the tool starts arriving before the problem.
A few years ago, every business seemed to need an app. Then everything needed to move to the cloud. More recently, almost every product roadmap seems to contain some form of AI.
There is usually a good reason behind the enthusiasm. New capabilities create new possibilities, and organisations quite reasonably do not want to miss a shift that might change how customers behave or how work gets done.
The difficulty comes when the presence of the technology becomes the measure of innovation.
A rules based process can start to feel unsophisticated simply because it is rules based. A search bar can appear dated because it is not conversational. An automation that has worked reliably for years suddenly looks less impressive beside something described as an agent.
Yet products are not judged by the novelty of the architecture once people begin using them.
They are judged by whether they work.
This is one area where the current engineering guidance from the companies building foundation models is surprisingly restrained. Anthropic, for example, recommends starting with the simplest possible solution and increasing complexity only when it creates enough value to justify it. Its guidance specifically notes that agentic systems tend to exchange additional latency and cost for greater flexibility, while predefined workflows remain more predictable for well understood tasks.
We think that principle extends well beyond agents.
If a database query solves the problem, use the database query.
If a deterministic rule can make the decision safely, write the rule.
If a conventional search index finds exactly what somebody needs, giving it a personality may not improve it.
AI becomes interesting when those approaches begin to break down.
Emily: when ambiguity is part of the problem
Emily sits at one end of our spectrum.
She is an AI assistant that people work with primarily through ordinary language. You can email her and ask her to arrange a meeting, respond to a thread, research a company, write something, remind you later or follow up when someone goes quiet. She increasingly works across other channels too, including SMS, ChatGPT and Claude.
That product genuinely needs intelligence because much of the work begins with ambiguity.
“Find me some time with Priya next week” is not an API request.
Neither is “reply politely but make it clear we cannot do Friday”, or “keep an eye on this conversation and chase them if I haven’t heard back”.
A traditional application could support those tasks, but it would require somebody to translate what they mean into menus, fields, filters and rules before the software could act.
A language model changes that relationship.
The person can describe the outcome in roughly the same way they would describe it to another person. Emily can interpret the intent, use relevant context, identify what information is missing and decide which underlying tools are required.
This is exactly where we want a model involved.
But interestingly, the more Emily has developed, the more deterministic software we have built around the model.
The AI can interpret what somebody means. It does not decide which account the person owns.
It can draft an email. Permissions determine whether that draft can be sent.
It can identify possible meeting times. Calendar APIs establish whether those times are actually free.
It can understand a request to buy, delete or change something, but there are actions we deliberately do not expose through connected assistants at all.
This distinction becomes more important as AI systems gain agency. OWASP describes “excessive agency” as a risk created when language models are given more functionality, permissions or autonomy than the task genuinely requires. The problem is not only malicious behaviour. An ambiguous instruction, an incorrect model output or an ordinary implementation mistake can become much more consequential when the model is allowed to act freely on external systems.
Our answer has not been to remove the AI.
It has been to decide very carefully where the AI stops.
The language is probabilistic.
Identity, authority and execution do not need to be.
Clean Rabbit: when predictability is the feature
Clean Rabbit sits almost at the opposite end.
It is a desktop utility for macOS, Windows and Linux that finds caches, duplicate files, old downloads, leftover application data and other things taking up space. Everything is scanned locally on the machine, and nothing about the user’s files needs to leave it.
There is no AI inside it.
We never seriously found a reason to add any.
That choice becomes clearer if you think about what somebody wants from a disk cleaner. They want it to identify files according to understandable criteria, tell them accurately what it found, respect the boundaries of the filesystem and remove only the things they have chosen to remove.
They do not particularly need interpretation.
If two files have identical contents, we can determine that computationally. If an application has support files in known locations, software can find them. If something has not been accessed for a defined period, the operating system can tell us when.
None of those decisions improves because a language model is invited to guess.
In fact, AI would introduce qualities we actively do not want in that part of the product.
There would be additional latency. Potential network dependency. Inference cost. A larger privacy surface. Another service that could be unavailable. More complicated testing. Most importantly, there would be uncertainty in a product whose entire purpose depends on behaving predictably around people’s files.
You could imagine features where AI might eventually be useful. Perhaps a natural language explanation of what an unfamiliar file appears to be, or a conversational way of exploring storage usage.
But the core job of deciding whether two files are duplicates does not become better because it is intelligent.
Sometimes trust comes from software doing exactly what you expect, every time.
For Clean Rabbit, that predictability is not a limitation.
It is part of the product proposition.
The crossword: when uncertainty is actually useful
Our crossword ended up somewhere between Emily and Clean Rabbit.
Every puzzle has WHITERABBITFOUNDRY running through the centre. Gemini generates themed words, clues and simpler hints around topics such as data, products, automation, consulting and the occasional rabbit. Everyone begins with the current puzzle, and completing one causes another to be generated for the growing pool.
This is an excellent use of generative AI because we actively want variation.
If we had written a deterministic function for clue creation, the result would either be painfully repetitive or require us to create a large editorial library by hand.
Language models are very good at the bit we find expensive: producing many plausible variations within a brief.
But Gemini does not decide how the crossword is laid out.
Our own engine does that.
The model supplies candidate words. The layout algorithm places the fixed central phrase, scores possible intersections and attempts to create a valid grid. If the generated words do not work together, the engine tries again with different seeded layouts. If that still fails, there is a handwritten fallback bank.
The model is allowed to be creative where creativity makes the product better.
The application remains deterministic where a rule needs to hold.
We also require the model output to follow a defined structure. Vertex AI supports response schemas specifically so applications can constrain generated responses to predictable JSON structures rather than trying to parse arbitrary prose afterwards.
This is a small example, but it captures something we think is quite important about practical AI development.
You do not have to choose between “AI product” and “normal software”.
Often the best product contains both.
AI has a cost even when the API call looks cheap
When people discuss whether a feature should use AI, the conversation often gets reduced to model quality.
Can the model do it?
Increasingly, the answer is yes.
That does not necessarily mean it should.
Every model call introduces another part of the system that needs to be understood and operated. There is inference cost, even when individual requests appear inexpensive. There is latency. There are service quotas and regional capacity considerations. There is dependency on a provider whose models, pricing and behaviour can change over time.
There is also testing.
Traditional software can be difficult to test, but the expected output of a deterministic function is usually relatively clear. Given the same valid inputs, we can generally expect the same result.
Generative systems are different.
Google’s Vertex AI documentation allows developers to provide a seed to make generations mostly deterministic, but explicitly notes that absolute deterministic behaviour is not guaranteed.
Then there is the more fundamental problem of correctness.
NIST uses the term “confabulation” for cases where generative systems confidently produce false or erroneous information, noting that this behaviour arises naturally from the way generative models produce outputs. The risk becomes more significant when those outputs influence consequential decisions or external actions.
None of this is an argument against generative AI.
It is an argument for remembering that AI is an architectural dependency, not a decorative feature.
If the upside is meaningful, those trade offs can be entirely worthwhile.
If the model is only there because an AI button looked good in the roadmap, they become much harder to justify.
Automation and intelligence are not the same thing
One confusion we encounter surprisingly often is the assumption that sophisticated automation now requires AI.
It does not.
A large amount of valuable automation is still better represented as ordinary logic.
If an invoice arrives from a known supplier, save it to a defined location and alert finance.
If stock falls below a threshold, create a replenishment task.
If a file is older than a defined date and matches an allowed category, show it in a clean up list.
If a customer has not responded after seven days, send the predefined follow up.
These can all be useful workflows without a language model anywhere near them.
AI becomes relevant when the thing that needs automating cannot be expressed cleanly as a predictable rule.
Perhaps invoices arrive in wildly different formats and somebody needs to understand what each document contains.
Perhaps the follow up needs to reflect the tone and content of the conversation.
Perhaps the user describes the workflow in natural language rather than configuring it manually.
The distinction we find useful is not “manual versus AI”.
It is known rules versus interpretation.
When the rules are stable and explicit, code is usually very good at following them.
When the input is messy, ambiguous or linguistic, models become much more interesting.
The more consequential the action, the less intelligence should be left unsupervised
There is another pattern across our products.
The closer something gets to an irreversible action, the more deliberately we try to narrow the role of AI.
Emily can interpret a request to arrange a meeting, but the calendar system remains the source of truth for availability. A connected assistant can prepare consequential work, while permission and confirmation mechanisms control whether it happens. Emily
The crossword can invent a clue because the cost of a strange clue is very low.
Clean Rabbit does not use a model to decide what is safe to delete.
Those are not arbitrary implementation choices.
The acceptable level of uncertainty depends on the consequence of being wrong.
A generated headline that is slightly disappointing can be regenerated.
An assistant misunderstanding the recipient of an email is more serious.
Software removing the wrong files is more serious again.
This is why the idea of simply making systems “more autonomous” is not particularly useful on its own.
Autonomy is not automatically progress.
Sometimes the better product is the one that knows when to ask.
A simple test we now use
We have ended up informally asking the same questions whenever AI comes up in a product discussion:
Does the problem contain meaningful ambiguity? If natural language, messy information or contextual judgement is central to the task, AI may have something useful to contribute.
Would several different outputs all be acceptable? Writing, summarisation, research and ideation naturally allow variation. Authentication and arithmetic generally do not.
What happens when the model is wrong? A funny crossword clue and an incorrectly sent payment do not belong in the same risk category.
Can ordinary software solve this more cheaply and reliably? If a rule, query or calculation produces the answer, complexity needs to earn its way in.
Can the uncertain part be contained? Some of our most useful systems put AI inside deterministic boundaries rather than handing the whole workflow to the model.
This is not a formal framework, and there will always be edge cases. It does, however, force the conversation back towards the problem. That is usually a healthier place to start.
Sometimes the best AI architecture contains surprisingly little AI
There is an interesting consequence to all of this.
As models become more capable, good AI product engineering may involve writing more conventional software around them, not less.
Structured schemas constrain what comes back.
Retrieval systems provide information the model should rely upon.
Permission systems decide which tools can be used.
Validation checks outputs before they become actions.
Fallback paths make sure the experience continues when generation fails.
Monitoring tells us when model behaviour changes.
This is already reflected in the guidance from model providers. Google’s documentation recommends grounding model output against current or private data when factual reliability matters, while structured responses allow downstream systems to depend on a known format. Anthropic similarly distinguishes between flexible agents and workflows where predefined code paths offer greater consistency.
The model may be the most interesting piece of the diagram.
It should not necessarily be the biggest.
Why this matters beyond our own products
Emily, Clean Rabbit and a crossword are obviously very different things.
That is exactly why we find the comparison useful.
If every product we built ended up with the same architecture, we would probably be optimising around our preferred tools rather than the problem in front of us.
Clean Rabbit needs local execution, predictable behaviour and very little network dependency.
Emily needs language understanding, contextual reasoning, external tools and carefully controlled authority.
The crossword needs creativity in one place and rigid rules in another.
Different problems deserve different amounts of intelligence.
That sounds obvious when written down, but software teams have always had a tendency to overuse whatever happens to be exciting at the time. The tool becomes familiar, the organisation invests in it, and suddenly every problem begins to resemble the use case the tool is good at solving.
Part of product judgement is resisting that.
Sometimes innovation means using a new capability.
Sometimes it means deciding not to.
A final thought
We are extremely optimistic about artificial intelligence.
We are building a business around some of what it makes possible. Emily would not exist without it. The crossword became more interesting because of it. We use AI throughout our own development work, and we increasingly help clients work out where it can remove friction from their organisations.
But enthusiasm for a technology should not require pretending it improves everything it touches.
Some problems benefit from interpretation.
Some benefit from automation.
Some just need a reliable function that returns the same answer every time.
The interesting skill is knowing which one you are looking at.
As AI becomes easier to access, adding it will become less impressive in itself. Almost any team can call a model. Almost any product can acquire a conversational interface. The differentiator will increasingly be the judgement around it: what context the model receives, what it is allowed to decide, how its output is checked, where deterministic systems take over and whether the customer is genuinely better off because intelligence was introduced.
That is what we mean by AI where it earns its place. Not avoiding AI. Not adding it everywhere. Using enough intelligence to make the product better, then having the discipline to stop.