When a task touches several files, I first ask the assistant to draw up a map of changes. Not to write code — just to name the entry points, dependencies, risks and order of work.
It’s like a renovation: before drilling into a wall, it helps to know where the wiring runs.
Study the task and the codebase. Don’t write code yet. Return: 1. Which files need to change and why 2. What might break 3. A step-by-step plan of changes 4. Which tests are needed 5. Questions and assumptions
After that I review the plan and ask it to implement one step. This way AI “makes up” less of the architecture, and I notice a wrong direction earlier.
The technique is especially useful for legacy code, integrations and tasks with side effects: payments, access, migrations, queues.
It isn’t needed for a local edit like renaming a field or a simple function without external dependencies. There the planning would cost more than the change itself.
