Ten hours, by the startup’s count
A startup barely a year old says its AI agents have rebuilt, for a rival chipmaker, the equivalent of CUDA, the software layer that has kept developers loyal to NVIDIA for two decades, and that the job took about ten hours. The company, Infinity, says its agent produced the compilers, debuggers, profilers and tuned kernels that make an accelerator usable, reaching 92 percent of the chip’s theoretical peak in that time. It separately claims a 34 percent throughput gain over the standard vLLM software on one model after a day of tuning.
Those figures come from the company’s own benchmarks. No independent measurement is yet public, and the company sells exactly the service the numbers promote. The reporting also carried its own caution: checking generated code is still where the time goes, and producing code is only a small share of getting software into production.
That caution is the part worth carrying into your own estate, because the chip story is a vivid version of something much closer to home.
Your version of the same bet
For most established organizations, the first place agents will do serious engineering work is not a new product. It is migration and modernization: converting stored procedures from one database dialect to another, rewriting ETL jobs for a new platform, translating a batch program nobody has touched in a decade. This is exactly the work agents look good at (high volume, a known source, a known target) and exactly the work where “it compiles” tells you very little.
A converted stored procedure can run cleanly and still be wrong. The old platform rounded differently. It treated an empty string and a null as the same thing. A date boundary fell somewhere else, an outer join became an inner one and dropped unmatched rows, an error path wrote to an audit table the new version never heard of. None of this surfaces in a review of the generated code. All of it surfaces eventually, usually in a finance report or a regulator’s question.
Decide what “the same” means before the agent starts
The most useful single discipline is to write the acceptance criteria before any code is generated. If the target is defined after the output exists, the output will define the target. For each workload, name:
- The outputs that matter. Tables, files, extracts, downstream feeds and side effects, not just the procedure’s return value.
- The data it is tested on. Real production data, or a governed copy of it, covering month-ends, year-ends, late-arriving records and the awkward cases synthetic samples never contain.
- The tolerance. Exact match, row for row, for most financial and regulatory data. Where a difference is acceptable, state how much and why, in writing.
Then test for equivalence rather than correctness in the abstract. Run old and new side by side on the same inputs and reconcile: row counts, checksums, aggregates by the dimensions the business actually reports on, and a sample of individual records traced end to end. Every difference is one of three things: a defect in the new code, a defect in the old code that someone must now decide whether to preserve, or a tolerance the criteria already allowed. Nothing else is an acceptable explanation.
This is where the ten-hour headline and enterprise reality part company. Generation is quick. A parallel run through a quarter-end is not, and should not be.
Measure what shipped, and name who signs
Agent-assisted migrations invite a particular kind of progress report: objects converted, percentage of code translated, engineering hours saved. These measure what was generated. The number that matters is how many workloads have passed reconciliation and are running in production with the old version switched off. Report both, and the gap between them is the honest measure of the work remaining.
Sign-off follows the same logic. The engineering team can attest that the code runs. The agent’s vendor can attest to how quickly it was written. Neither can attest that the monthly revenue figure is still right. That belongs to the business owner of each output, the finance lead for the ledger feeds or the risk owner for the regulatory extracts, who should see the reconciliation evidence and sign against the criteria agreed at the start.
For a data leader weighing an agent-assisted program, the practical questions are short:
- Are acceptance criteria written per workload, before generation begins?
- Is there a governed path to real data for the parallel runs?
- Is progress reported as reconciled and live, not converted?
- Which role signs for each output, and have they agreed to?
Agents will make the code cheap. In our work, the migrations that land are the ones that treated the evidence as the deliverable.
