agent macro fix broke 40 other models using the same macro

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

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