What the model cannot see, and how to give it eyes

The blind spots are specific

It is easy to talk about what a model does not know in a vague way. It is more useful to list it, because each item has a fix.

Your running app. The model sees source code, not behaviour. It does not know that the page renders blank for a second, that the button is 3 pixels off, or that clicking twice creates two bookings.

Your data. It has never seen a row in your database. It does not know that 200 of your 3,000 customers have no phone number, which is exactly the fact that would have prevented the crash you are about to hit.

Your environment. It does not know which environment variables are set, which version of Node you have, or that your host runs Linux while you are on a Mac.

Production. The error a user hit twenty minutes ago exists only in your host’s logs. Nothing reaches the model unless you carry it there.

Your users. It does not know they are mostly on Android phones with 3 GB of RAM, or that half of them will type a name with an apostrophe in it.

What you meant. It has the words you wrote, not the picture in your head.

Giving it eyes, one blind spot at a time

Each of those is fixable, and the fix is always the same shape: put the observation into the context.

Paste the real error, not your summary of it. “It’s broken” is nothing. The first three lines of the stack trace, plus what you clicked, is a diagnosis. Include the file and line number from your own code.

Show it the data. You do not need to hand over your customer list. A shape is enough:

SELECT * FROM bookings ORDER BY created_at DESC LIMIT 3;

Paste those three rows with the names changed. The model instantly learns that phone is sometimes empty and that duration is stored in minutes, not hours, and both facts will change the code it writes.

Show it the schema. \d bookings in psql, or the contents of your schema file, is a hundred words that prevent a hundred wrong guesses.

Screenshot the screen. Every major tool takes images now. A screenshot with an arrow drawn on it, in any free image editor (GIMP, Krita, or the annotation tool already on your phone) beats three paragraphs describing a layout problem.

Paste the terminal output whole. Including the command you ran and the lines above the error. People trim the output to the part that looks relevant, and the useful line is nearly always in the part they trimmed.

Let it run things. An agent that can execute npm run build and read the output has closed the biggest gap on this list by itself. This is the real reason agent modes outperform chat: not intelligence, observation.

The habit worth forming

Before you send a message about something being wrong, ask: what am I looking at that the model is not?

Usually the answer is a screen, an error, or a row of data, and pasting it takes fifteen seconds. Most of the frustrating exchanges people have with these tools are exchanges where the human could see the problem and the model was being asked to guess at it.

What still will not transfer

Some things resist all of this, and it is worth knowing which so you stop expecting help with them.

Taste. Whether the flow feels right, whether the wording is patronising, whether a stranger will understand the empty state. You can ask for opinions and they are sometimes useful, but you are the only one who has met your users.

Intent under conflict. When two of your rules collide (the discount says 20 percent, the loyalty tier says 15, and a customer qualifies for both) no amount of context tells the model which one you want to win. That is a decision, and you have to make it.

Whether it matters. A model will fix a spacing issue with the same energy it brings to a data-loss bug. Prioritisation is yours, permanently.

These are not gaps that a bigger context window closes. They are the part of the work that stays yours, and recognising them early is what stops people feeling vaguely cheated when the tool cannot do them.