AI agents write the code now. Engineers design the walls that keep it honest.

Key points

• AI coding agents can now draft complex data pipelines from a plain-English description, a task that would have taken an engineer hours.
• Every autonomous agent loop accumulates what the author calls "operational entropy": a slow build-up of stale assumptions that push the output further from a correct answer.
• A test suite can pass and a pipeline can run cleanly while still producing numbers that are semantically wrong.
• The new engineering mandate, according to data engineering leader Ananth Packkildurai, is designing the contracts and boundaries that make AI-generated code trustworthy, not writing the code itself.
• That shift makes the engineer's contribution more visible, not less valuable.

Describe a data pipeline in plain English, and an AI agent, software that can carry out multi-step tasks on its own, will produce a credible first draft before a human has finished reading the relevant files. Tools like Cursor and Claude Code have been getting quietly better at this for two years now. The friction of writing the first version has nearly collapsed.

Ananth Packkildurai, a data engineering leader and author of the Data Engineering Weekly newsletter, writing in VentureBeat, argues the job hasn't shrunk. It has moved. Our earlier story on what actually keeps engineers employable reached a similar conclusion from a different angle: the skill that ages well isn't writing code faster.

Why doesn't the agent just figure it out?

Agents are powerful inside a bounded task. Give one a known input, a known target schema, and tests that catch the important failures, and it will propose a change, run the tests, absorb the result, and try again. That loop works.

But real enterprise systems, the kind that run pricing engines or customer data platforms, aren't bounded. They depend on third-party APIs, business rules buried in someone's head, schemas that change without notice, and policy decisions no one has written down. The agent can't see any of that.

Packkildurai's example is sharp. An agent asked to add a "customer_tier" field to a revenue model finds a field called "status" in the operational database, maps it across, and all the existing tests pass. The code is clean, the pipeline is green, and the answer is wrong. "Customer_tier" is supposed to be calculated from a customer's trailing twelve-month spend, not their account status. Without a rule that says so explicitly, the agent has no way to know.

What stops the agent from drifting?

The answer is the same thing that stopped junior engineers from making the same mistake: a clear, enforced boundary.

Packkildurai calls these "containment fields": data contracts that define what a field means and who owns it, immutable event logs that can't be quietly rewritten, idempotent APIs (ones that produce the same result however many times you call them), and strict semantic layers that sit between raw data and the dashboard a finance team trusts.

These aren't new ideas. What's new is that they're now load-bearing. Without them, an agent generates motion. With them, that motion becomes useful work.

Every agent loop also accumulates what he calls operational entropy: stale assumptions and unresolved dependencies that build up inside a running loop. A failing test, a precise data contract, or a deterministic tool resets the signal. Without that feedback, the agent keeps producing output while drifting further from a correct answer.

What does this mean for working engineers?

The design work matters more than the typing. Writing a semantic data contract, owning a data model, deciding what a field means and under what conditions it changes: these contributions make AI-generated code safe to ship.

Engineers who focus only on writing code faster are competing with tools that are already faster. Those who focus on the rules those tools must follow are building something agents can't replace. We first covered the mechanics of data contracts on 3 September 2026, and Packkildurai's argument makes the stakes of that reporting concrete.

The honest verdict on this piece: it's a reframe, not a rescue plan. Packkildurai doesn't promise engineers will be fine regardless. He says the ones who survive will be the ones who stop thinking of themselves as code producers and start thinking like system designers. That's a harder shift than picking up a new framework.

Watch for: data pipelines that pass automated tests but produce figures your finance or operations teams don't recognise. A clean test result only means the code does what the tests check for. Whether the tests check for the right thing is still a human decision.