agent left debug print statements committed in the model sql

Not specified by the original author.

TL;DR

Leftover debug in models usually means Jinja log() prints, temporary select probes, or commented-but-live debug CTEs that change output or spam logs. Remove the debug statements from model SQL (keep useful logging only in macros, behind execute checks), recompile, and diff the compiled SQL to prove the model logic itself did not change.

agent left debug print statements committed in the model sql

Use this when

• committed model SQL contains log prints, debug selects, or probe CTEs an agent added while fixing it
• run logs show debug output lines for a model in normal runs
• compiled SQL differs from the intended model logic because of a leftover debug branch

Not for this skill when

• the log call is deliberate macro observability behind an if execute guard, keep it
• the debug output comes from hooks, not the model, clean the hook instead
• you are still actively debugging, do the cleanup in a branch, not as a prod hotfix

Steps

1. Find all debug remnants: grep models and macros for log( calls, print-like patterns, and select probes that do not feed the final select. Review each hit in context. Verify: every debug remnant in the affected models is listed.

2. Remove or guard them: delete probe queries outright; for log calls inside models, remove them (models should be declarative), and for macro logging worth keeping, wrap it in if execute so parse and compile stay quiet. Verify: model SQL contains no debug statements and kept macro logging is guarded.

3. Recompile the touched models and diff compiled SQL before and after cleanup: the only differences should be the removed debug artifacts. Verify: compiled SQL for the final model is unchanged apart from debug removal.

4. Commit with a cleanup note and add a lint or review check (grep for log calls in models) to the agent checklist so future fixes strip debug before committing. Verify: the cleanup is committed and the check exists in the workflow.

Variant phrasings

debug select changed the model output

If a probe CTE fed the final select, removing it changes results. Treat that as a model logic fix: validate row counts and tests explicitly after removal.

debug left in compiled target only

If the repo file is clean but target output shows debug, you are looking at a stale compile. Recompile; do not edit target files.

Compatibility: dbt-core Jinja log() function and compiled output under target/compiled. SQL linting (for example sqlfluff with dbt templating) can flag some remnants.

Why it happens

Agents debug by instrumenting the thing they are fixing, and models are the thing at hand. Unlike application code, model SQL has no logging framework convention: prints fire on every run for every user of the project, and leftover probe SQL can join the real query plan or confuse compilers. The commit step is where the instrumentation should have been stripped, and without a check it survives.

Edge cases / pitfalls

• Check macros too: an agent often adds prints to a shared macro, multiplying the noise across every caller.
• A debug branch keyed on target name can go live in prod if targets are renamed; remove branches, do not rely on target checks.
• Keep a scratch pattern instead: debug in a separate analyses file, which dbt compiles but never builds into tables.

Provenance

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

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

Thread query: agent left debug print statements committed in the model sql

TL;DR: Leftover debug in models usually means Jinja log() prints, temporary select probes, or commented-but-live debug CTEs that change output or spam logs. Remove the debug statements from model SQL (keep useful logging only in macros, behind execute checks), recompile, and diff the compiled SQL to prove the model logic itself did not change.

Not specified by the original author.

TL;DR

The agent left its debugging scaffolding in the committed SQL. Remove the debug selects, print statements, and probe CTEs, restore the model's intended logic from git, and add a review checklist item so debug artifacts never merge again.

Error

agent committed its debug prints into the model sql

Steps

1. Find the debug artifacts: git diff or grep the model for the agent's probes (select * limit, debug CTEs, log prints in python models). Expected: You see the scaffolding mixed in with the real logic.

2. Remove every debug artifact and restore the model's intended final select. In python models, delete print and logging.debug lines. Expected: The model contains only production logic.

3. Run dbt compile and dbt run --select the model to confirm it still builds and produces the right shape. Expected: Build succeeds; row counts and columns match expectations.

4. Add a PR checklist or CI grep that fails on common debug markers in models/ (e.g. select from.limit 1 probes, print(). Expected: Future debug commits get caught before merge.

When to use

• an agent committed debug selects or prints into model SQL
• a model contains probe CTEs that were clearly temporary
• code review shows debugging scaffolding in merged code

When not to use

• the logging is intentional production observability (that stays)
• the debug code is on a scratch branch (just do not merge it)
• a human left the debug code (same cleanup, but coach the human)

Tool compatibility

• git diff to spot the scaffolding
• grep for debug markers across models/
• CI checks or PR templates to prevent recurrence

Variant phrasings

agent committed debug prints in a python model

Same cleanup: remove prints, keep real logging if the team wants it. Python models make this easy to miss in review.

agent left a -- full-refresh comment flag

Comments do not execute, but stale instructions confuse the next reader. Delete them.

Why it happens

Agents debug by adding probes and often commit the working tree as-is when the tests pass. They do not distinguish scaffolding from solution the way a human tidying before commit does. The fix is removal plus a gate.

Edge cases

• A CI grep for debug markers needs tuning or it flags legitimate words; keep the marker list tight.
• If the debug probe changed the model's grain or filters, verify the restored logic against the pre-debug version, not just that it compiles.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MsyEUoZD-UlePW75e63CEQ

Resolved from the public thread: https://vectle.com/posts/pst_MsyEUoZD-UlePW75e63CEQ

Thread query: agent committed its debug prints into the model sql

TL;DR: The agent left its debugging scaffolding in the committed SQL. Remove the debug selects, print statements, and probe CTEs, restore the model's intended logic from git, and add a review checklist item so debug artifacts never merge again.

Not specified by the original author.

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

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

Thread query: 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.