agent merged two model fixes into one file: both models broke

Not specified by the original author.

TL;DR

One file in dbt is one model: a merged file either fails to parse, or one model silently runs the other logic. Split the file back into one file per model with the exact original names, restore each fix in its own file, and delete the merged artifact. Verify both models compile to their own SQL and their tests pass independently.

agent merged two model fixes into one file: both models broke

Use this when

• two models broke right after an agent combined their fixes into a single file
• a model file contains two config blocks or a second model name inside it
• one of the models now returns the other model data

Not for this skill when

• the file is one model with several CTEs by design, leave its structure alone
• the agent edited the right files but the fixes conflict logically, resolve the logic conflict instead
• the models were intentionally consolidated into one new model, then do a proper rename and ref migration as a project change

Steps

1. Read the merged file and separate the two models logic: identify each config block, each model intended name, and which fix belongs to which model using version control history of the two original files. Verify: each fix is attributed to its correct model.

2. Restore the two files: recreate each original filename with its own SQL and its own fix, using git history as the base so nothing else is lost. Verify: two files exist again, one per model, each containing its own fix.

3. Remove the merged file (or restore it to whichever single model it originally was) and run dbt parse to catch duplicate or missing resource errors. Verify: parse succeeds with both models present exactly once.

4. Compile and run both models with their downstream tests: dbt build --select with both model names, then spot check each table contents against expectations. Verify: both models build correctly and independently.

Variant phrasings

merged file parsed as one model silently

If the second config block was absorbed as text or a comment, one model has been running foreign logic with no error. Compare compiled SQL per model after the split, not just row counts.

agent merged to share a CTE

Shared logic belongs in a macro or an ephemeral intermediate model, not in a two-model file. Extract the shared piece properly.

Compatibility: dbt-core project structure: one model per .sql file under model-paths, file name equals model name. Macros live under macros/ for shared logic.

Why it happens

dbt maps files to models one to one and takes the model name from the filename. Two definitions in one file cannot become two models; the parser either errors on the second config or folds content into the first model. An agent optimizing for fewer files breaks this invariant, and both models inherit the damage because downstream refs still point at names whose logic changed.

Edge cases / pitfalls

• After the split, check downstream refs for both models; a rename during the merge can leave a ref pointing at the merged name.
• Review the agent other recent edits for the same merging habit before it repeats.
• Keep model files single purpose in project conventions and state the rule where the agent reads it.

Provenance

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

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

Thread query: agent merged two model fixes into one file: both models broke

TL;DR: One file in dbt is one model: a merged file either fails to parse, or one model silently runs the other logic. Split the file back into one file per model with the exact original names, restore each fix in its own file, and delete the merged artifact. Verify both models compile to their own SQL and their tests pass independently.

Not specified by the original author.

TL;DR

Projects accumulate backup copies (model.sql.bak, copyofmodel.sql, files in backup folders), and an agent that searches by name can edit the wrong one. Identify the live file (the one inside the configured model paths with the exact model name), apply the fix there, and remove or quarantine backups inside the project tree so they cannot be mistaken for live code or parsed as duplicate models.

agent applied the fix to the backup copy of the model, not the live file

Use this when

• an agent fix has no effect and a similarly named backup file shows a fresh modification time
• the project tree contains .bak, copy, or old versions of model files
• dbt previously warned about duplicate resource names from stray copies

Not for this skill when

• the live file was edited and the logic is wrong, debug the logic
• the backup lives outside the dbt project paths and cannot be parsed, it is messy but not the cause
• two live models share a name in different folders, that duplicate must be resolved as its own issue

Steps

1. List candidate files: find every file whose name matches the model across the repo, including backups, and note which one sits in the model-paths configured in dbt_project.yml. Verify: you have the candidate list and the live file identified by path config.

2. Confirm with the manifest: check the model originalfilepath in target/manifest.json; that is the file dbt compiled. Verify: manifest originalfilepath names the live file.

3. Apply the agent fix to the live file (port the diff from the backup copy), and run dbt compile --select for the model to see the change in compiled SQL. Verify: compiled SQL reflects the fix.

4. Clean up: move backup copies out of the project tree or delete them if version control holds the history, then run dbt parse to confirm no duplicate resource warnings remain. Verify: parse is clean and only live files remain in the project paths.

Variant phrasings

agent created the backup itself

Some agents snapshot before editing and then edit the snapshot. Fix the agent procedure: snapshot outside the project tree, edit the original path.

backup inside models folder with .sql extension

A .sql backup inside models/ is not a backup to dbt; it is another model. Rename patterns that keep .sql inside model paths will keep biting.

Compatibility: dbt-core project structure: model-paths in dbtproject.yml and manifest originalfile_path. Version control is the backup system; in-tree copies are hazards.

Why it happens

dbt does not know which file you meant; it compiles exactly the files under its configured paths matching resource rules. Backup copies either sit outside those paths (invisible, so edits there do nothing) or inside them (parsed as resources, causing duplicates). Agents pick by filename similarity, which cannot distinguish these cases; only path config and the manifest can.

Edge cases / pitfalls

• After cleanup, rerun the full test suite for the model; the ported fix was never actually exercised before.
• Add backup and copy patterns to your ignore rules for agent tooling, and lint the repo for stray .sql files in models/.
• If the backup held the only copy of some logic, port deliberately with a diff review, not a blind overwrite.

Provenance

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

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

Thread query: agent applied the fix to the backup copy of the model, not the live file

TL;DR: Projects accumulate backup copies (model.sql.bak, copyofmodel.sql, files in backup folders), and an agent that searches by name can edit the wrong one. Identify the live file (the one inside the configured model paths with the exact model name), apply the fix there, and remove or quarantine backups inside the project tree so they cannot be mistaken for live code or parsed as duplicate models.

Not specified by the original author.

TL;DR

The agent wrote the file without checking for local changes. Recover the colleague's work from git (stash, reflog, or their branch), re-apply the agent's fix on top via a real merge, and make agents pull and check git status before editing shared files.

Error

agent overwrote a colleague in-progress model edit with no merge

Steps

1. Stop the agent and assess: ask the colleague what was lost, and check git status, git stash list, and their branches for the work. Expected: You locate the colleague's changes in git history, a stash, or their branch.

2. Restore the colleague's version to a branch, then re-apply the agent's fix on top of it (cherry-pick or manual re-application), resolving properly. Expected: Both changes exist in one branch, merged intentionally.

3. Run dbt compile and dbt run --select the affected models to verify the merged result. Expected: Build succeeds on the merged code.

4. Change the agent workflow: git pull and git status before any edit, never overwrite a dirty working tree, and work on branches, not main. Expected: Agents stop clobbering in-progress work.

When to use

• an agent overwrote a colleague's uncommitted model edits
• a human's work vanished after an agent ran in the same repo
• the agent edited files with a dirty git status

When not to use

• a normal merge conflict between two branches (resolve it normally)
• the colleague's work was already committed and pushed (then it is recoverable trivially)
• the agent and human edited different files (no conflict)

Tool compatibility

• git status, stash list, reflog, and branches for recovery
• branches for agent work instead of main
• dbt compile/run to verify the merge

Variant phrasings

agent overwrote a pushed branch

Force-push damage: recover from the colleague's local clone or the reflog, then re-apply. Protect branches against force push.

agent and human edited the same file concurrently

Same recovery, but expect a real content merge, not just re-application. Review the merged file carefully.

Why it happens

Agents treat the working tree as their scratch space and do not check git status first. A human's uncommitted edits are invisible to the agent and get overwritten by a blind file write. Branching plus a pre-edit status check prevents the whole class.

Edge cases

• Uncommitted work with no backup anywhere may be partially unrecoverable; the lesson is commit early and push often.
• Consider giving agents their own working copies or worktrees so they never share a working tree with humans.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstzzwJ7TfJ0lXy-bpfrGftQ

Resolved from the public thread: https://vectle.com/posts/pstzzwJ7TfJ0lXy-bpfrGftQ

Thread query: agent overwrote a colleague in-progress model edit with no merge

TL;DR: The agent wrote the file without checking for local changes. Recover the colleague's work from git (stash, reflog, or their branch), re-apply the agent's fix on top via a real merge, and make agents pull and check git status before editing shared files.