Every system slowly becomes smaller in our minds. A codebase turns into the few files we usually touch. An agent becomes the handful of tasks we trust it with. A tool becomes the one feature we originally adopted it for. The rest is still there. We have simply stopped asking for it.
That is why, once in a while, I think it is important to squeeze the lemon.
Shaking the tree tells you what is loose.
There is an old instinct in engineering to shake the tree: change the conditions and see what breaks, complains, or turns out to be unnecessary. A stricter test reveals a weak assumption. Removing a package reveals where it is still used. Asking how a feature works reveals that nobody is quite sure.
Squeezing the lemon is related, but slightly different. It asks: what useful work can we get from the things we already have?
Before adding another dependency, can the codebase already support the idea? Before paying for another tool, are we using the useful features of the one we have? Before creating another agent, can the current one handle the task with clearer instructions or better context?
Sometimes you do not need another tool. You need to use the one you already have more fully.
A harder task shows you what is useful and what is stale.
This does not mean stressing a system at random. Give it one specific task beyond the way you normally use it. Ask an agent to trace a decision across the whole repository. Run the workflow with a real deadline or permission limit. Inspect the files nobody has opened in months.
You may find a feature or workflow worth using more often. You may also find duplicated logic, abandoned experiments, obsolete configuration, and instructions that remain long after their original purpose has disappeared.
Use the first group. Review and clean up the second.
Agent files can affect security.
This matters more now that repositories collect files written for agents: AGENTS.md, CLAUDE.md, rule folders, copied prompts, tool configurations, and temporary instructions from old experiments. They may look like documentation, but some tools read them as instructions and act on them.
An old instruction can quietly influence how an agent reads the repository, which commands it runs, what it ignores, or where it sends information. Contradictory files can make its behavior unpredictable. A forgotten integration may also retain access that nobody remembers granting.
Not every unused file is a vulnerability. But someone should be able to explain every file that directs an agent, every hook it can run, every tool it can call, and every credential or external service it references.
Keep what proves useful.
Try a specific task you do not normally assign to the codebase, agent, or tool. If it works, document the workflow so the team can repeat it.
Delete what has no purpose.
Review old instructions and integrations. Delete the ones with no owner or current use, and revoke access that is no longer required.
Deletion can be a security practice.
My rule is simple: if an agent file is no longer used, nobody owns it, and nobody can explain why an agent should still read it, it probably should not be there.
That does not mean deleting blindly. First list the agent files and read them. Check whether tools or automation refer to them. Look for secrets, external services, broad permissions, install commands, and instructions that conflict with the current project. Move any useful explanation into the project's current documentation. Then delete the stale file and revoke any access connected to it.
Version control already keeps the old file in the project's history. The current repository does not need to keep giving those old instructions to new agents.
Do it periodically, not constantly.
A lemon can be squeezed too hard. Constant optimization and cleanup can prevent real work from happening. You do not need to review every tool every day.
Instead, choose useful moments: after finishing a project, before adding a new agent, or during a security review. Try a harder task. List the old files and integrations. Keep and document what still helps. Delete what no longer has a purpose.
Then get back to building, with fewer conflicting instructions and a clearer idea of what your systems can actually do.