When code can be replaced: what preserves the system

AI tools are widespread, but using an assistant differs from delegating work to an autonomous agent. Polomodov compares research in which more changes coexist with weaker reliability. Different populations, tools, and methods do not establish a universal productivity multiplier. When an agent generates code faster than people can validate it, reading and acceptance become the constraint. Upstream, teams also need a supply of well-prepared tasks that are actually worth doing.

At his former company, the platform comprised a model gateway, a tool gateway, and a capability registry that was much harder to develop. Wrapping internal APIs in MCP was insufficient. Answering what happened to someone’s services over the past hour requires team ownership, service discovery, telemetry, commitments, and on-call information. Without a complete capability, the agent reconstructs that workflow across disconnected systems. Measurement has three layers too: tool adoption; flow and hours saved on engineering jobs; economic impact. The company had not reached that final layer at the stage described.

The central idea comes from Chad Fowler’s Regenerative Software: when code becomes cheap and replaceable, it no longer provides a sufficient repository of system knowledge. Intent becomes specifications and evaluations, an agent produces an implementation, and production reveals whether it fulfils the promise. A practical test is whether a component can be deleted and rebuilt while preserving the system’s required behavior. This requires a bounded replacement with explicit acceptance criteria.

Polomodov examines seven primitives: intent, compilation, evaluation, provenance, pace, deletion, and compaction. He interprets compilation through architecture: the rules governing how an agent turns intent into a system. The other primitives likewise connect to established engineering practices. Together, they move system identity into explicit promises, constraints, and evidence that survives replacement of the source code.

Intent states an expected outcome, its scope, and the reason it matters. For example, payment must follow confirmation of available inventory: customers must not be charged for missing goods. An instruction to call a particular method hides that promise behind a mechanism. During one cloud migration, the demand for connections that never break turned out to involve financial operations without idempotency. A disconnected request could not safely be retried. Until that dependency was explicit, arguments about load balancers missed the underlying problem.

Architecture defines responsibilities and allowed connections so that implementations can change predictably. Naming a framework does not settle those questions. Polomodov recalls a system split into microservices by domain entity: ordinary changes became distributed transactions, and the system soon failed under load. Code generation does not remove that failure mode. Bounded contexts, recorded architectural decisions, and enforceable constraints make subsequent component replacement manageable.

A migration of an A/B experimentation platform replaced both traffic splitting and result calculations. The team spent considerable effort matching the new system’s outputs to the old ones. After identifying numerical precision differences, they discovered that rebuilding data marts also changed the old results. The reference itself was moving, making exact reproduction an impossible acceptance target.

The team had to agree on sufficient accuracy while checking contracts, invariants, known regressions, performance, failures, and security, followed by a canary rollout. Unit tests remain useful for algorithms and data structures, but cannot describe every promise the system makes. Replaceable implementations need evaluations that remain meaningful after internal details change. Otherwise, accidental properties of the predecessor become the definition of correctness.

RFCs, ADRs, design documents, and incident reviews preserve choices, alternatives, and context. They allow engineers to reconstruct how the system evolved and identify constraints that no longer apply. Generated components also benefit from a provenance chain recording the model, prompt, specification, and evaluation results. This evidence gives later changes an explicit basis in the team’s decisions.

An agent-written document still needs substantive review. Polomodov describes instructions that generated architectural diagrams without requiring anyone to validate them. If the author cannot interpret their arrows and relationships, polished diagrams turn an ADR into a formality. Agents can accelerate recording a decision that someone understands; engineers remain responsible for its meaning.

Interface experiments and infrastructure should not change at the same pace. Polomodov connects pace to dependencies and reversibility. Cheap rollback supports rapid experiments; changing a foundational component with many consumers demands more careful preparation.

An Aerospike upgrade in an authentication and authorization system illustrates the risk. Compatibility was tested, but changed index behavior during a network partition caused a serious failure. The incident review later helped justify an architectural change. Cheap code generation does not automatically make failure-mode testing or consequences for dependent systems cheap.

A migration finishes when the old solution is retired. Running a new service beside its predecessor leaves obligations, data, and dependencies in two places. In one example, a CRM built to replace Siebel was itself replaced while Siebel remained operational. Dependencies also include people: only after someone leaves might a company discover that they alone knew a required month-end procedure.

Compaction, the seventh primitive, keeps the system understandable across successive replacements. Teams must remove obsolete interfaces, configuration, flags, and dependencies while maintaining useful evaluations and coherent domain concepts. A proposed Oracle-to-Cassandra migration illustrates the missing work: choosing another database is insufficient without knowing consumer commitments and actual query patterns. Otherwise, layers accumulate until the team can no longer explain its own system.

Successful teams converted requirements into agent contracts, prepared context, and used validation tools. Simply handing an agent a ticket number without changing the process produced much less convincing results. Daily work increasingly involves stating intent, defining acceptance criteria, coordinating concurrent agents, and validating outcomes. People remain accountable for delivering the change and keeping the system maintainable.

Regeneration requires stable boundaries, independent behavioral evaluations, and identifiable owners. Regenerating an entire application, or asking for the same code “but better” without extracting its promises, are antipatterns. In the closing question, Polomodov anticipates further specialization: some engineers will build sophisticated platform machinery while many work closer to products. This is a forecast, not a claim that technical depth will become unnecessary.