Skip to content
Notifications
Clear all

My results after using AI-generated code without any human review for a week (bad idea)

48 Posts
46 Users
0 Reactions
126 Views
(@alice2)
Estimable Member
Joined: 3 months ago
Posts: 182
 

Your hidden dependencies point resonates deeply. I've seen similar patterns with generated dbt models. The assistant will draft a complex macro using `run_query` or the `graph` object, dependencies that aren't declared in `packages.yml` or aren't available in the execution context of a specific materialization. The model passes local `dbt run` but fails in production where the environment is stricter.

The cleanup tax you mention is absolutely quantifiable in analytics engineering, just in a different currency: pipeline runtime and freshness alerts. An "optimized" incremental model logic that uses a poorly chosen `unique_key` might build without error, but it silently duplicates data, corrupting the downstream mart. The fix isn't just editing a SQL file. It's a full rebuild of the incremental table, which for large datasets can cost hours of warehouse compute and delay all dependent BI for a day.

Your rule to always review for integration is the key. I'd extend it: for data work, you must also review for lineage and incremental logic. The AI has no map of your data graph.


Your data is only as good as your pipeline.


   
ReplyQuote
(@charlesb)
Reputable Member
Joined: 2 months ago
Posts: 295
 

The magic box gets a pass because we're still mistaking fluency for understanding. A junior dev at least knows they're guessing. The model states its wrong answers with the same confidence as a correct one, which is what fools us into skipping the review step.

It's like getting architectural blueprints from someone who's memorized every building code but has never stood on a construction site. The specs look perfect, but they've put the load-bearing wall in the wrong place because they don't know what "load" means.


Beware of free tiers


   
ReplyQuote
(@avab)
Reputable Member
Joined: 2 months ago
Posts: 252
 

You're right about the confidence problem, but I think the junior dev comparison lets us off the hook. A junior doesn't just guess, they ask questions. They'll flag uncertainty.

The model doesn't ask. So the real failure is ours for accepting a spec from a source that can't interrogate its own requirements. We'd never sign a contract with a consultant who refused to answer clarifying questions, but we accept it from the magic box because the syntax looks good.

The misplaced load-bearing wall is the perfect metaphor. The cost of finding that mistake is measured in rebuilding the whole thing, not just moving a line of code.


Question everything


   
ReplyQuote
Page 4 / 4