AI Writes Tasks; Engineers Protect Architecture

When you give AI a specific task, that task becomes the immediate definition of success. Ask it to make a feature work, and you may get an implementation that satisfies the request without fitting the needs of the whole application.

The engineer has to bring those wider requirements into the work. A feature working in a demonstration is only one part of the evidence.

A search box that passes the wrong test

Imagine asking AI to add a search box for customer records.

One possible implementation downloads every record into the page, then searches through that data as you type. With ten test records, it can feel instant. The matching names appear. The feature looks finished.

Now consider the same page with 10,000 records or more. Before someone can search for one customer, the application may transfer a whole customer list to their browser. That can make the page slow, use more memory, and move far more data than the person needs for the task.

The missing question was not whether the search box returned a matching name. It was how this search should work with the volume of data the product actually needs to handle.

Put the application’s context into the task

In that situation, a better approach may be to search where the data is stored and return only the relevant results. The browser does not need the complete customer database to display a short list of matches.

But “use server-side search” is still not a complete requirement. The engineer needs to establish what the user is trying to find, how much data exists, which records they are allowed to see, and how the new search fits the system already in place.

For example, if different teams have access to different customers, the search must respect those permissions before returning results. Hiding records on the screen after sending them to the browser would not protect them. That requirement belongs in the design of the search, even if the original request mentioned only a text field.

The task also needs a clear limit. If thousands of records match, returning all of them recreates part of the original problem. Decide how results will be limited or paginated and what the user sees while waiting, when nothing matches, or when the search fails.

These are decisions about the requested feature in its real environment. They do not require predicting every possible future use of the product.

AI can help with the design too

AI can compare approaches, inspect the existing code, suggest tests, and help implement the chosen design. Its usefulness does not end at writing a function.

The important part is making the wider requirements available and checking that the result meets them. Naming a requirement in a prompt is not the same as verifying it in the application.

For this search feature, a useful review would ask:

• With realistic data volumes, how much information reaches the browser and how long does the search take?
• Can each user retrieve only the records they are allowed to access?
• Are large result sets bounded, and can the user understand loading, empty, and failure states?
• Does the implementation use the application’s existing data and access rules consistently?

Those checks test the choices that ten sample records can hide.

Match the solution to the actual product

Downloading and filtering a small, bounded list can be perfectly reasonable. An internal selector containing a handful of non-sensitive options does not necessarily need the same design as a growing customer database.