The classic AI tool executes perfectly, once everything has been pre-chewed for it. The preparation it demands is precisely the thinking it was meant to take over: gathering, framing and explaining. In the end the human has worked so that the machine can work.
The delegation back
You recognise it by the follow-up questions. Every request for more context is a task the tool hands back to its user. It shows up in no metric and in every working day. The price is larger than it looks: a follow-up question costs not only the seconds until the answer, but the context switch in the head of a person who was thinking about something else.
A good tool takes over work. A very good one takes over the preparation.
Three design rules
Three rules survived the first LeanCTX year. First, context is fetched before the question is asked, so the tool knows the repository before the first prompt lands. Second, it says what it is missing instead of guessing. Third, it shows what it has read, because otherwise the delegation starts over, only later and more expensively.
The second rule carries a qualification we had to learn. A tool that never asks is a tool that guesses, and guessing is worse than a question when the stakes are real. Stated properly the rule reads: it should not ask for material it can fetch itself, and it very much should ask when a decision belongs to the human.
Showing without drowning
The third rule sounds like more transparency and easily tips into the opposite. A tool that spreads out everything it read on every answer produces a second wall of text nobody reads. The rule becomes usable with a distinction: what was read must be inspectable at any time, not visible at all times. By default a note about what a statement rests on is enough. Anyone who wants to check gets to the passage in one click.
That difference decides whether trust forms. Someone who can never look inside has to believe. Someone who has to look inside every time is doing the work twice. Between the two sits the point where a tool stays checkable and still takes work off your hands.
Why interfaces help here
For a tool to fetch its own context it needs orderly access to the sources. Standards such as the Model Context Protocol exist for exactly that, unifying how data sources and tools are connected. The gain is organisational more than technical: once access is standardised, every project stops inventing its own integration.
None of the three rules is technology. They are courtesies toward human attention, and they are the reason a tool feels like a colleague instead of a form.