Start a Spark by Finding What Already Exists── A request to search for existing programs turned into priority requirements by the next day

01The operator asked AI to find and set up a secretary bot

In March 2026, the operator asked an AI to search public repositories for a program that could manage schedules and tasks, look up weather forecasts and train timetables, and work through a messaging platform. The request was not to build one from scratch. It was to find something that already existed and make it run.

The next day, a second request on the same subject appeared. Its content had changed. Task management should combine urgency and importance to set priorities, and the system should confirm those priorities with the user. A reminder function should also ask the user before activating. In one day, a vague wish for a personal assistant had turned into concrete requirements for a specific mechanism.

This change was not accidental. A request to search for existing solutions has the power to grow requirements.

02Searching returns options and constraints at the same time

Ask an AI to build something and it starts building. Ask it to search and it returns a list of candidates, each with its capabilities and constraints. That list shows what can be done and what cannot be done, side by side.

This difference changes what happens inside the requester's head. Looking at candidates separates the features that are truly needed from those that are merely nice to have. In the operator's case, weather and timetable lookup were stated from the start, but a priority mechanism appeared only after the candidates had been reviewed. Either the existing candidates lacked adequate priority features, or seeing the candidates prompted the realisation that priorities were essential. Both explanations lead to the same result: searching surfaced a requirement that had been implicit.

03Building from scratch delays the discovery of missing features

When no search for existing solutions is done, the requester judges completeness only after the product is finished. The longer the build takes, the later the discovery. At that point, a rebuild or additional work is unavoidable.

Searching works differently. Reading a list of candidates takes little time. At the moment of reading, the realisation arises: a feature is wanted but absent. In the operator's record, one day after seeing the secretary bot candidates, a priority mechanism was stated in writing. The act of searching turned an unspoken expectation into an explicit requirement.

Anthropic's published guidance for Claude Code recommends exploring and planning before implementation, and referencing existing patterns when building new components. Building a new piece by looking at how existing ones work keeps the result consistent with the whole. This advice points in the same direction as searching first.

04Searching here means picking, from published solutions, the one closest to your goal

The word needs a boundary. In this article, searching means finding, among publicly available programs or services, the one closest to your goal, then judging whether it can be used as-is or what it lacks.

What does not count as searching: work whose method is already decided and only needs executing. In that case, asking AI to build directly is faster.

05In material review, searching past records reveals the gaps in the current process

The same pattern applies in pharmaceutical promotional material review. Before building a new review mechanism, ask AI to search for the review records, checklists or past findings that already exist. The list that comes back shows which types of findings are frequent, which items tend to be missed, and which areas the current process does not cover.

Suppose you are considering a mechanism to check whether expressions in a draft are appropriate. Ask AI to search for any existing procedures or records for that check, and it will return what is in place and what is not. The gap becomes the requirement for what to build next.

This sequence also connects to the priority framework the operator requested. The record shows that by the next day, the operator wanted tasks classified by urgency and importance. This way of classifying originated with Dwight D. Eisenhower, who noted in a 1954 address that problems come in two kinds, urgent and important. Management scholars later arranged the distinction into four quadrants, and it became a widely used tool for setting work priorities. The operator's move from searching for a bot to demanding this classification happened because the candidates made clear that a priority mechanism was missing.

06Searching grows requirements because candidates make the gap between expectation and reality visible

Why does searching grow requirements? A list of candidates works as a surface that reflects expectations the requester has not yet put into words. Candidate A has schedule management but no task priority. Candidate B has reminders but no weather lookup. Reading these differences clarifies which features truly matter.

The 2024 Stack Overflow Developer Survey found that 76% of developers are using or planning to use AI tools in their development process. Common uses include code generation, but searching for existing solutions and organising requirements are also part of the picture. Asking AI to search is a natural first stage of AI-assisted work.

The mechanism at work here is what psychology calls recognition. It is easier to identify what you want when options are presented than to recall it from a blank slate. Searching grows requirements because it triggers this recognition effect, turning latent expectations into stated needs.

07From tomorrow, add one word before "build": "search"

There are three steps.

1. State the goal and ask AI to search for what exists. Have it list publicly available programs or services that come close.
2. Read the candidate list and write down the missing features. Features absent from the candidates become your requirement candidates.
3. State the missing features explicitly in your next request. The request becomes "add this feature" or "build something that meets these requirements", not "build from nothing".

These three steps take less than an hour. Rework is far smaller than discovering missing features after a build is complete. Anthropic's documentation recommends defining success criteria before refining a prompt. The gaps that a search reveals serve as material for defining those criteria.