What Happened
Recent evidence points to a practical shift in AI engineering: coding agents are becoming part of production software delivery, not just developer experimentation. OpenAI has described 2026 as the year agentic engineering took off internally, with research teams extensively using coding agents and a visible rise in AI spend per researcher as more capable models became available [1].
A concrete production example comes from a Google Finance migration to Cloud Spanner. The team needed a zero-downtime, byte-for-byte migration across historical backfill, dual-write and dual-read operation, and automated API verification. Manually converting more than 30 DAOs would have required months because each DAO needed schema translation, dual-write and rollback logic, and test coverage [3].
The successful pattern was not an open-ended “ask the model to migrate the system” approach. The team first created a strict MutationConverter interface, then used headless Antigravity CLI runs with version-controlled prompt templates and build-test feedback from Bazel and Go tests. Engineers could queue batches overnight and review validated changelists in the morning [3].
This matters because it contrasts sharply with the common failure mode of large rewrites. Full replacements often underestimate hidden behavior in legacy systems, run in parallel for years, and leave the business operating two incomplete systems with higher cost and risk [2].
Why It Matters to Businesses
For enterprise AI and cloud teams, the core lesson is that coding agents are most valuable when they are used to accelerate constrained engineering workflows, not when they are asked to autonomously redesign critical systems.
- Migration velocity improves when the task is repeatable. DAO conversion, schema mapping, boilerplate test generation, API parity checks, and infrastructure-as-code refactors are strong candidates because success can be compiled, tested, and reviewed [3].
- Rewrite risk remains high. AI does not eliminate the organizational and behavioral risks of greenfield replacement. Legacy systems continue changing, undocumented edge cases remain, and dual-system operation can become permanent [2].
- AI spend becomes a real infrastructure line item. The reported rise in AI spend per researcher at OpenAI illustrates that agentic development consumes meaningful compute and model capacity at scale [1]. Businesses need chargeback, budgets, and usage telemetry before broad rollout.
- Governance must move into the delivery pipeline. The safest pattern is not chat-based code generation. It is automated generation behind contracts, tests, review gates, and controlled permissions [3].
The business decision is therefore not “Should we use coding agents?” It is “Where do we have repetitive, high-value engineering work that can be bounded by interfaces, test harnesses, and rollback plans?”
Kimbodo Engineering Perspective
At Kimbodo, we would treat this as an AI-assisted migration and orchestration problem, not a generic LLM deployment problem. The highest-return architecture is a controlled agent pipeline connected to source control, CI, observability, and cloud test environments.
Prefer migrations over rewrites
Most enterprises underestimate the amount of business logic embedded in old systems. A rewrite appears clean on a roadmap but usually creates a second production system, a second operational burden, and a long parity gap. The safer path is incremental migration: add tests, create compatibility layers, move bounded components, and maintain reversible cutovers [2].
Design contracts before involving agents
The Spanner migration succeeded because engineers created a deterministic contract first. The MutationConverter interface made the model’s task narrow: translate known DAO behavior into known Spanner mutations and pass specific tests [3]. That is the right abstraction for enterprise AI engineering. The model should work inside an architecture that senior engineers define.
Use models where verification is cheap
Coding agents are most effective when errors are caught quickly by compilers, unit tests, integration tests, static analysis, schema validators, and golden-file comparisons. They are much weaker when correctness depends on undocumented business judgment, distributed system timing, or production-only data behavior.
Treat model cost like cloud cost
As agentic engineering adoption increases, model usage can scale faster than expected [1]. Enterprises should forecast token consumption, tool-call volume, retry loops, and parallel batch execution. The cost model should include engineer review time, CI capacity, test environments, and failures, not only LLM API charges.
How We Would Implement It
1. Select the right migration slice
We would start with a bounded, repetitive migration domain: DAO conversion, API client replacement, message schema migration, Terraform module standardization, Kubernetes manifest cleanup, or data pipeline connector replacement. The target should have many similar files, clear success criteria, and existing or buildable tests.
2. Create a strict engineering contract
Before running any agent, we would define the target interface, expected file layout, naming rules, rollback behavior, telemetry requirements, and error-handling standards. For a database migration, this could mean a converter interface, dual-write wrapper, read parity checker, and standardized test fixture, similar to the MutationConverter pattern used in the Spanner migration [3].
3. Build a headless agent runner
We would avoid ad hoc developer chat for production-scale refactors. Instead, we would build a headless orchestration service or CLI that:
- Reads a version-controlled prompt template.
- Checks out an isolated branch or worktree.
- Runs the coding agent with minimal repository permissions.
- Executes formatting, static analysis, compilation, unit tests, and targeted integration tests.
- Feeds failures back into a bounded retry loop.
- Opens a pull request only when the required checks pass.
4. Connect to CI, test data, and ephemeral environments
The agent pipeline should run inside controlled CI infrastructure with reproducible dependencies. For cloud migrations, we would use ephemeral test environments, database test doubles where appropriate, and contract tests against real managed services where behavior matters. The Spanner case demonstrates the value of generated code passing unit tests against Spanner test doubles before review [3].
5. Add migration controls
For production rollout, we would implement feature flags, per-tenant or per-traffic-slice activation, dual-write metrics, read parity checks, lag dashboards, and automated rollback. For data systems, the critical metrics are mismatch rate, write failure rate, read divergence, replication lag, idempotency errors, and backfill completion.
6. Govern model access and cost
We would route agent traffic through a model gateway that enforces approved models, data handling policy, budgets, logging, and rate limits. This is especially important when teams start running many parallel jobs overnight. The same practice used for cloud spend management should apply to LLM deployment and agentic engineering usage [1].
Risks, Costs and Security
Incorrect generated code is the primary risk. Agents can produce plausible code that compiles but mishandles edge cases. Mitigation requires narrow contracts, test coverage, golden data sets, code review, and staged rollout. The agent should not be trusted because it is fluent; it should be trusted only where verification is strong.
Dual-system operation can become permanent. Any migration involving dual-write and dual-read logic needs an explicit exit plan. Otherwise, the business may inherit the same failure pattern seen in unsuccessful rewrites: two systems, duplicated operations, and growing long-term cost [2].
Costs can grow through retries and parallelism. Agent pipelines consume model tokens, CI minutes, build cache capacity, developer review time, and test infrastructure. Strong cost controls include per-repository budgets, maximum retry counts, batch scheduling, model tiering, and reporting by team and project.
Security exposure increases when agents receive tool access. Coding agents may touch source code, credentials, logs, schemas, and internal documentation. Production-grade deployments need least-privilege credentials, network egress controls, secret scanning, isolated sandboxes, audit logs, and restrictions on which files or commands the agent can access.
Data leakage and compliance must be designed out. Sensitive code, customer data, and regulated records should not be sent to external models without policy approval and contractual controls. Where necessary, use private model deployments, redaction, synthetic fixtures, or on-premises inference for restricted workloads.
The practical conclusion: AI coding agents can materially reduce migration effort when paired with deterministic interfaces, automated tests, and controlled cloud orchestration. They are not a substitute for architecture. The winning pattern is senior-engineered constraints first, agentic execution second, and production rollout discipline throughout.
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our AI Infrastructure & MLOps practice, or Estimate My Infrastructure.
