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.

For two years, tools like Cursor and Claude Code have been getting quietly better at a task engineers once spent most of their day on: turning a requirement into working code. 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. The friction of writing the first version has nearly collapsed.

So what is left for the engineer?

Ananth Packkildurai, a data engineering leader and author of the Data Engineering Weekly newsletter, writing in VentureBeat, argues the job has not shrunk. It has moved.

Why doesn't the agent just figure it out?

Agents are powerful inside a bounded task. Give one a known input, a known target, a small codebase, 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, are not 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 cannot 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 passes all the existing tests. The code is clean. The pipeline is green. 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 cannot be quietly rewritten, idempotent APIs 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 are not new ideas. What is new is that they are 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, branching context, 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 practical takeaway is that 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 are the contributions that make AI-generated code safe to ship.

Engineers who focus only on being faster at writing code are competing with tools that are already faster. Engineers who focus on the rules those tools have to follow are building something agents cannot replace.

Watch for: data pipelines that pass automated tests but produce figures your finance or operations teams do not 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.