Prompting, Vague and Precise

Source: Dev.to

I was in a session with Shiry, our sharp product manager, demoing Claude Code Web’s capabilities. We chose a nice‑to‑have feature to work on: reflecting the active filter state in our data table.

The product has a table with dozens of columns. Users can filter rows by values in one or more columns, and they can show or hide columns as they like.

The problem: a user can end up with active filters and have no idea which columns they’re filtering on. To find the filter indicator in a column header, they’d have to scroll the table horizontally, and maybe unhide columns that are currently hidden. A real game of hide and seek.

First Attempt: Vague about the Problem, Precise About the Solution

I asked Claude Code to add a list of filtered fields above the table:

Add next to the text of "Showing 21 items", the fields we are filter 
the items by (if any). e.g. "Showing 21 items, filtered by Name and Country".

It wrote the code, committed, pushed. We waited for the build, checked the preview environment, and got exactly what I asked for: an ugly list of field names.

Second Attempt: Precise About the Problem, Vague About the Solution

We started fresh.

Shiry, who’s a master at building prototypes using LLMs, suggested I try again. This time she dictated the prompt:

On the items table, I want to help the user understand that there is an active filter and what it is.
(without having to look for it on the columns' headers, to scroll, or find hidden column with filter, etc.)

This time we were much vaguer about the solution, but we described the problem precisely, the same way I described it at the top of this post.

The result impressed me.

Instead of a plain text list, Claude Code rendered a row of chips. Each chip showed the field name and the selected filter values. If more than two values were selected, it showed the count instead. Each chip had a small X to remove that field’s filter. When multiple filters were active, a “clear all” button appeared.

Night‑and‑day difference. The second implementation was better by an order of magnitude. It looked familiar, professional, and far more useful—something a designer would create.

The Lesson

• When I described the solution, the model built the solution I described.
• When I described the problem, the model solved the problem and often found a better solution than I had imagined.

Be precise about the problem. Be vague about the solution.