The Demand That Created Noise

The Demand

I needed a data pipeline. It had to read CSV files, clean the data, check it, and put it into a PostgreSQL database. I typed: "Build me an ETL pipeline for CSV to PostgreSQL." Fourteen words. Zero specification.

The model gave me an ETL pipeline. It worked in a technical sense. But it was useless for my project. The column mappings were wrong. The validation rules were wrong. The transformation logic was wrong. The error handling was wrong. Everything was wrong, except the basic idea of moving data from CSV to PostgreSQL.

Tracing the Noise

I read the output and marked every part that was wrong. Then I looked back at my prompt. For each wrong part, I asked: did I say what I wanted here? The answer was always no. I never said what the column mappings should be. I never said what the validation rules should be. I never said what the transformation logic should be. I never said how to handle errors.

Every wrong part in the output matched a gap in my prompt. The match was perfect. Not close. Perfect. Each gap made the model guess. Each guess was wrong for my project.

The Clean Version

I rewrote the prompt. I gave it a role: senior data engineer with PostgreSQL expertise. I gave it context: an existing Django application, the exact database schema, a production environment. I described the data: CSV format with the exact column names, types, and example values. I listed the constraints: it must handle nulls, must validate email format, must log every transformation, must be idempotent. I set the format: Python, with type hints, matching the existing project's coding style. I named the task: build the pipeline as a management command.

The output was correct. First try. Every part matched my needs because every need was written in the prompt.

The demand made noise. The specification made signal. Same model. Same day. Same task. Different input. Different output.