Over the last two years, commit histories in modern data platforms have reflected a notable shift: the friction of writing syntax has largely disappeared. Tools and agentic workflows such as Cursor, Claude Code, and agent-based processes now run inside developers’ Docker containers and IDEs, making the first pass at a distributed streaming pipeline or a complex API integration no longer the primary bottleneck.
Agents can navigate repositories, create test coverage, inspect stack traces, and propose refactors. Describe a Kafka-to-Iceberg sink mapping in plain English and an agent can produce a credible starting point before an engineer opens every relevant file.
That changes what we ask of software engineers. If an agent becomes the main author of local system logic, what remains for humans to do? Will engineers become reviewers who rubber-stamp a stream of plausible pull requests, or has the work shifted from constructing logic to a more abstract task of designing the system conditions under which generated logic is correct?
The agent as a heat engine
Removing anthropomorphic metaphors, an AI agent is a computational engine: it accepts direction and turns it into action. A large language model in a data center has great capacity but performs useful work only after receiving intent — a prompt, business requirement, system instruction, or failing test. The agent converts that intent into code, tool calls, queries, tests, and changes to a running system.
All engines incur losses, and agent loops are no different. Anyone who has let an agent work on a tricky repository has seen the pattern: a clear task begins, the agent follows stale assumptions, fixes symptoms rather than root causes, treats an old migration as current behavior, and accumulates its own operational history. A few tool calls later, the context contains plausible but conflicting details, and the next step becomes less certain than the first.
Call this operational entropy: the buildup of stale assumptions, branching context, and unresolved dependencies inside a loop that still tries to move forward. Human interruption helps because it injects new information; so do failing tests, precise data contracts, deterministic tools, or evaluations that tell the agent exactly what it got wrong. Without those signals, an agent can keep producing output while drifting from a correct outcome.
The infinite monkey and the expanding search space
The infinite monkey theorem gives a helpful picture: repeated attempts, finite constraints, and feedback. Modern agents are much smarter monkeys: they have compilers, tools, repositories, test suites, and feedback loops. Their work is not random — feedback steers the next attempt — but the dynamic is familiar: propose, execute, observe, correct, and try again.
In a bounded task, that loop is highly effective. Give an agent a known input schema, a known target schema, a small codebase, and tests that catch relevant failures, and it can inspect the code, make a change, run the tests, absorb the result, and converge. The definition of done is visible and the search space is narrow.
Enterprise systems are rarely that still. A real‑time pricing engine may depend on mutable operational state, third‑party APIs, late‑arriving events, regional policy, and business rules split between code and people’s heads. A data lakehouse can be physically consistent and semantically wrong. A pipeline can pass its tests yet produce numbers Finance does not recognize. The environment changes while the agent types.
The three‑body problem of enterprise logic
The three‑body problem is a useful image for enterprise software. With two bodies, motion can be predicted with a neat mathematical description. Add a third body and the system becomes much harder to solve; some configurations behave chaotically and small changes can yield very different outcomes elsewhere.
Modern data platforms share this shape: clickstream evolves with product behavior; operational databases mutate under customer activity; APIs change versions and rate limits; schemas evolve; security policies shift; legacy systems contain undocumented rules. Each system exerts pressure on the others. A local feature request can pull on the whole system.
For example, an agent asked to add a customer_tier field to a revenue model might find a status column in the operational database, map it into the transformation, and pass existing type and nullability tests. The code looks clean, the pipeline is green, but the answer can still be wrong. A semantic data contract might state that customer_tier is derived from trailing twelve‑month spend, has an assigned business owner, and cannot be populated from account status. The contract rejects the change before it reaches the dashboard. The engineer’s value in that case was not the transformation itself but the boundary that made the agent’s mistake visible, specific, and recoverable.
The new mandate: designing equilibrium
The software engineer’s job is not disappearing as code generation becomes cheaper and faster — it is becoming more visible. The new mandate is designing equilibrium: creating conditions in which generated logic can be trusted.
When business requirements change faster than an agent can absorb feedback, engineers need to build containment fields. Strict semantic layers, immutable event logs, data contracts, idempotent APIs, and deterministic state machines are not only good platform hygiene; they reduce the number of assumptions an agent must make at once.
Those constructs turn a tightly coupled problem into a bounded domain with clear inputs, explicit rules, and reliable feedback. Within such a domain an agent can truly shine: write the transformation, run tests, repair failures, and ship changes without inferring every bit of unwritten history about tables and services.
Autonomous systems will increasingly generate software. But the contracts, feedback loops, and boundaries that determine whether that software succeeds or spirals into chaos will still be designed and overseen by software engineers.
Ananth Packkildurai is a data engineering leader, writer, and author of Data Engineering Weekly, sharing perspectives on modern data platforms, large‑scale pipelines, and AI‑driven architectures.
