Data Engineering Doesn't Need a Smarter AI Copilot

Ask an AI copilot for a CSV reader and you get one in four seconds. It is competent. Then you start typing.

• Pin the encoding, do not rely on the locale.
• The malformed input test should assert the behaviour, not just that it did not crash.
• Externalise the file path and the thresholds.
• Keep the original value when the conversion fails.
• Add a schema, and validate against it in CI.
• Failures per record, not one status for the run.

Six corrections, all reasonable but all you knew before you asked. A few hours later, you have a good pipeline.

Tomorrow there is another source, and you start again.

The specification exists in your chat history

That list is not feedback, it is your definition of done, expressed one prompt at a time, in a conversation that gets thrown away when the tab closes.

This is the part that goes unnoticed, because each individual correction is cheap. A few hours is nothing. But you pay it per source, per project, and per person, and the sixth engineer on your team pays it without knowing the other five already did, because there is nowhere for that knowledge to live.

Driving a copilot well means becoming very good at re-expressing your own standards. That is a real skill and it is a strange thing to get good at, because the value it produces evaporates every time.

Here is a cheap measurement. Over your next week, keep a note of every instruction you give a generation tool that you have given it before. Not the ones about this specific source, the ones about how your team builds things. Then read the list.

That list is a specification. It is not written down anywhere, and you are paying rent on it.

A more capable model does not fix this

The intuitive answer is that this is a transitional problem. Models get better, first drafts get closer, corrections shrink toward zero.

Half of that is true. Capability reduces the corrections about correctness: the logic errors, the misunderstood requirement, the function that does not compile. Those genuinely go away as models improve, and they have been going away.

It does nothing for the other half, and the other half is most of your list.

Pinning the encoding is not a matter of intelligence. Neither is asserting behaviour in the malformed case, or externalising configuration, or preserving the original value. These are conventions. They are decisions your team made, or should have made, and they are not deducible from the request because they are not properties of the world. They are properties of you.

A model cannot infer your bar. It can only be told, and if the telling happens in a conversation, it has to happen again in the next conversation. No amount of capability closes that loop, because the loop is not about capability. It is about where the specification lives.

You are part of the harness

There is a shift worth borrowing in how people talk about these tools. The interesting part is no longer the model, it is the harness around it: the loop that calls tools, manages context, retries what failed, and decides when the work is done. Two products built on the same weights behave completely differently, and the harness is the difference.

That framing is right, and it is worth pushing one step further. Ask what a general-purpose harness is able to verify.

It can check the things that are true of all code. It compiles. The tests it wrote pass. The linter agrees. The types check. That is a genuinely useful set, and it is also the complete set, because a harness built to produce anything cannot assume anything about what finished looks like.

Your conventions are not in that set. Which means a general harness has a hole exactly where the definition of done should be, and something has to fill it.

You fill it. Every correction you type is the specification component of a harness that has no other source for it, and no memory of it once the conversation ends. That is not a complaint about copilots, it is what a general harness is: it borrows its standards from whoever happens to be driving.

An Engineering AI is the same architecture with that hole closed. The domain is fixed, so the harness knows which artifacts a finished pipeline has and can check for them without being asked. The model inside is replaceable and getting cheaper every quarter. The harness is the product.

The other shape

Concretely, when a system generates a class of artifact from only one domain, the conventions stop being instructions and become part of what the thing is. The encoding is pinned because that is what a pipeline is. The tests cover the malformed case because a deliverable without that is not finished. There is nothing to ask for, because asking is only necessary when the tool could reasonably do otherwise.

That constraint is the whole mechanism, and it is why the honest name for this is not "better AI". It is narrowness. A tool that produces one artifact can be held to a definition of done for that artifact. A tool that produces anything cannot be held to a definition of anything, which is exactly why a copilot hands you a starting point and leaves the remaining work with you.

The work does not disappear either way, it moves. With a copilot, your work is directing. With a specialised generator, your work is deciding whether the result is acceptable, which is a smaller job and a more interesting one.

When the treadmill is the right thing to be on

None of this is an argument against copilots, and the case for them is not weak.

Work that is different every time has no conventions to encode. Exploratory work, where the point is to find out what you are building, cannot be generated against a definition of done because the definition arrives last. A one-off script has no second instance to amortise anything over. In all of those, a general tool driven by a person who knows what they want is the correct arrangement, and building a generator for it would be an expensive mistake.

The treadmill is only a problem when the work repeats. And it is worth being precise about the test, because "repetitive" is used loosely.

The work repeats when a new instance shares the same skeleton and differs only in details, when you can write down what a finished instance contains, and when the ways instances differ from each other form a list you could finish. Ingestion passes all three, which is why generating it works. Business logic fails the first, which is why it does not.

The question that separates them

Not which tool is smarter. This one:

Am I giving instructions I have given before?

If the answer is no, you are exploring, and a copilot is the right tool. If the answer is yes, and it is yes for most of the code most teams write, then you have a specification you have never written down, and you are re-typing it for the rest of your career.

The future everyone describes is AI that writes more code. The one that matters is AI you stop having to instruct.

PrettyWhale.ai is an Engineering AI that generates ingestion and integration code. The conventions are not prompts, they are what the output is: executable code, tests that assert behaviour, quality checks per record, an output schema, configuration and documentation.