agent edited the compiled target sql instead of the model

TL;DR

Edits under target/ are build output; the next dbt run overwrites them. Reapply the fix to the real model file under models/, then rebuild. Teach the agent that target/ is read-only output, models/ is the source of truth.

Error

agent edited the compiled target sql instead of the model

Steps

1. Find what the agent changed: git status will show target/ files modified (target/ should ideally be gitignored; if it is not, the diff shows the edits). Expected: You see the agent's edits in target/compiled or target/run.

2. Read the agent's compiled-SQL edit and understand the intended fix. Expected: You know what change the agent was trying to make.

3. Apply the equivalent change to the source model under models/ (or the macro under macros/). Expected: The source file carries the fix in jinja/model form.

4. Run dbt compile and diff the new target/ output against the agent's hand edit to confirm equivalence, then dbt run. Expected: Compiled output matches the intended fix; the run succeeds and the fix persists.

When to use

• an agent edited files under target/compiled or target/run
• a fix worked once then vanished on the next dbt run
• git shows target/ modifications from the agent

When not to use

• the agent only read target/compiled to understand the SQL (that is legitimate debugging)
• the edit was to a real model file (then it is a normal fix, review it as one)
• target/ is gitignored and clean (nothing to fix)

Tool compatibility

• git status/diff to find the agent's edits
• dbt compile regenerates target/ from source
• gitignore target/ so agents are less tempted to treat it as source

Variant phrasings

agent edited target/run instead of target/compiled

Same problem, even more ephemeral: target/run is per-invocation output. The fix belongs in models/ regardless.

agent keeps doing this repeatedly

Add an explicit instruction to the agent's system instructions: never edit target/, and add a pre-commit check rejecting target/ edits.

Why it happens

target/ looks like SQL files you can edit, and agents that debug by reading compiled output naturally try fixing it there. But dbt regenerates target/ on every run, so the fix evaporates. The source of truth is always models/ and macros/.

Edge cases

• If target/ is committed to git, the agent's edit may look intentional in review; gitignore target/ to remove the ambiguity.
• Verify the re-applied fix in jinja form produces identical SQL; subtle differences (quoting, whitespace) are fine, logic differences are not.

Provenance

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