## TL;DR

The agent fixed the macro for one caller and changed behavior for all forty. Revert the macro, then re-apply the fix so it only affects the intended caller (a new parameter with a default, or a separate macro). Test every caller with dbt compile before merging.

## Error

```text
agent macro fix broke 40 other models using the same macro
```

## Steps

1. Revert the macro to its pre-agent state with git, and confirm the 40 models compile and run again.
   Expected: Blast radius contained; the fleet is green on the old macro.

2. Find all callers: grep for the macro name across models/ and macros/ to list every usage and its arguments.
   Expected: A complete caller list, e.g. 40 call sites with their argument patterns.

3. Re-apply the fix in a backward-compatible way: add an optional parameter defaulting to the old behavior, and have the one caller pass the new value. Or create a second macro for the new behavior.
   Expected: The original caller gets the fix; the other 39 see byte-identical behavior.

4. Run dbt compile on the full project and diff compiled output for the 39 untouched callers to prove no change.
   Expected: Full project compiles; untouched callers' SQL unchanged.

## When to use

- a macro edit broke many models at once
- an agent edited a shared macro to fix one model
- you need the blast-radius-safe way to change shared macros

## When not to use

- the macro has only one caller (then it is a simple fix, no blast radius)
- the breakage is in one model despite many callers (check that model's arguments)
- the macro is from a package you should not edit (override it in your macros/ dir instead)

## Tool compatibility

- git revert/checkout to restore the macro
- grep or dbt ls to enumerate macro callers
- dbt compile plus compiled-SQL diff to prove no behavior change for others

## Variant phrasings

### agent edited a dbt-utils macro in place
Never edit package code. Override the macro by defining the same name in your own macros/ directory; dbt prefers project macros over package ones.

### macro fix needed by all callers eventually
Then it is a migration, not a hotfix: update callers one by one with tests, not a flag-day macro change.

## Why it happens

Shared macros are implicit APIs with dozens of callers. Agents see one failing call site and edit the shared implementation, not realizing the change propagates everywhere. Backward-compatible parameters are how you evolve shared code safely.

## Edge cases

- Compiled-SQL diffing is the ground truth for no behavior change; compile success alone does not prove the SQL is identical.
- If the macro is called with different argument shapes per caller, test each shape, not just the count of callers.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nGkl0kuNugpegHqswdgPZg