Stay connected with KayaToday, follow us on Instagram and Facebook for the latest news and reviews delivered straight to you.
For decades, the central skill of software engineering was the ability to translate human intent into working syntax. That translation is no longer the bottleneck. Tools like Cursor and Claude Code, embedded directly into developer environments, can now generate a credible first implementation of a distributed streaming pipeline or a complex API integration before an engineer has even opened every relevant file. Agents navigate repositories, write test coverage, inspect stack traces, and propose refactors. The friction of writing code has effectively collapsed.
That collapse forces an uncomfortable question: if the agent is becoming the primary author of local system logic, what exactly remains for the software engineer to do? The answer, argued by data engineering leader Ananth Packkildurai in a widely shared analysis, is that the job has not disappeared. It has moved to a higher level of abstraction, and the shift is more demanding than it might first appear.
Why Agents Drift and Why That Is a Structural Problem, Not a Bug
To understand what engineers are now responsible for, it helps to understand where agents fail. Packkildurai borrows a frame from thermodynamics: every engine has losses, and every agent loop does too. An agent given a clear task will begin confidently, but as it follows stale assumptions, fixes symptoms rather than causes, and accumulates conflicting context across tool calls, its next step becomes less certain than its first. He calls this operational entropy, the buildup of unresolved dependencies and branching context inside a loop that is still trying to move forward.
This is not a flaw that better models will simply eliminate. It is a structural feature of how agents interact with complex, changing environments. A human interruption helps because it introduces new information. So does a failing test, a precise data contract, or a deterministic tool that tells the agent exactly what it got wrong. Without that external signal, an agent can keep generating output while drifting further from a correct outcome, producing code that is syntactically clean, passes existing tests, and is still semantically wrong.
Packkildurai illustrates this with a concrete hypothetical. An agent is asked to add a customer_tier field to a revenue model. It finds a field called status in the operational database, maps it into the transformation, and passes the existing type and nullability tests. The code looks fine. The pipeline is green. But the answer is wrong, because customer_tier is supposed to be derived from trailing twelve-month spend, not account status. A semantic data contract that specifies the derivation logic, assigns a business owner, and explicitly prohibits population from account status would have caught that mistake before it reached any dashboard. The agent did not need to be smarter. It needed a boundary.
Enterprise Systems Are Not Bounded Problems
The reason boundaries matter so much is that real enterprise environments are nothing like the tidy, bounded tasks where agent loops converge reliably. Give an agent a known input schema, a known target schema, a small codebase, and tests that catch relevant failures, and the propose-execute-observe-correct loop works remarkably well. The definition of done is visible and the search space is narrow.
But a real-time pricing engine may depend on mutable operational state, third-party APIs with shifting rate limits, late-arriving events, regional policy, and business rules that exist partly in code and partly in institutional memory. A data lakehouse can be physically consistent and semantically wrong. A pipeline can pass all its tests and still produce numbers that the finance team does not recognise as valid.
Packkildurai reaches for the three-body problem as an image for this complexity. With two bodies, a planet and a star, orbital motion is predictable. Add a third body and the system can exhibit chaotic behaviour, where small changes in one place produce dramatically different trajectories elsewhere. Modern data platforms have exactly this shape. Clickstream data changes with product behaviour. Operational databases mutate under customer activity. Schemas evolve. Security policies shift. Each system exerts pressure on the others, and a local feature request can start pulling on the entire architecture.
Designing Equilibrium Is the New Engineering Mandate
This is where the engineer’s role crystallises. The new mandate, as Packkildurai frames it, is designing equilibrium: creating the conditions under which generated logic can actually be trusted. Strict semantic layers, immutable event logs, data contracts, idempotent APIs, and deterministic state machines are not merely good platform hygiene. They reduce the number of assumptions an agent has to make at once. They convert a coupled, chaotic problem into a bounded domain with clear inputs, explicit rules, and reliable feedback signals.
Once that domain exists, the agent becomes genuinely powerful. It can write the transformation, execute the tests, repair the failures, and ship the change without needing to infer the unwritten history behind every table and service. The engineer’s contribution is not the transformation itself. It is the boundary that made the agent’s mistake visible, specific, and recoverable before it caused damage.
For technology businesses in Malaysia and Singapore, where engineering teams are often lean and the pressure to ship quickly is intense, this reframing carries practical weight. Agentic coding tools are already in use across the region’s startup and enterprise sectors, and the temptation is to measure their value purely in lines of code produced per day. Packkildurai’s analysis suggests that metric is the wrong one. The real leverage lies in how well the engineering team has structured the environment the agent operates in, because a poorly bounded system will amplify agent errors just as readily as it amplifies agent output.
The value of software engineering does not shrink as code generation gets cheaper. It becomes more visible, which is precisely the shift that matters. Autonomous systems will increasingly generate the software that runs businesses and infrastructure. But the contracts, feedback loops, and boundaries that determine whether that software succeeds or spirals into chaos will still be designed by human engineers. That is not a consolation prize for a profession under pressure. It is a harder and more consequential job than the one it replaces.
