Devin’s 37% rewrite
the old system was the test

A logistics company had its order intake logic sitting in Microsoft Access forms and VBA macros. The budget was fixed, the delivery window was tight, and not one business rule could be lost in the move. A seven-person Cognizant team used Devin for the conversion, rebuilding the forms as cloud-native applications while generating tests, deployment pipelines and documentation alongside the code. Every change was signed off by a Cognizant technical lead or architect before it merged. When the work went live, the client reported a net cost saving of 37% against a conventional rewrite.

Where the 37% comes from

The number comes from a release Cognizant and Cognition published on 23 September, in which Odyssey Logistics’ CIO put his name to the result and said the company kept people in control of the decisions that mattered. So the figure comes from the two parties involved, with no third-party audit. The baseline named in the release is a conventional rewrite. Swap in a different partner’s quote and a different scope, and 37% moves immediately. The first thing a buyer should do at the table is get that baseline and scope written into the contract, because without it the percentage cannot be checked.

One sentence in the release deserves more attention than the headline. Delivery throughput rose by roughly a third. Cost fell 37% while throughput rose a third, and the gap between those two numbers says the saving did not come from hands typing less code. What it did come from sits in the nature of the work.

Why conversion work can be squeezed: the old system is the answer key

Most AI projects stall at acceptance: what counts as done, and who decides. Conversion projects do not have that problem, because the target behaviour is already fixed by a running system. How the old form calculated, in what order it validated, what it did with an exception — all of it can be read off behaviour that has been in production for years. Write a rule in the new system, run the same inputs through both versions, and a mismatch shows up on the spot. Nobody has to define acceptance criteria from scratch.

In other words, the output can be filtered automatically. When verification is cheap at the margin, generated volume can be consumed. When verification lags, faster writing only builds a queue. The same property is what let this project commit to a fixed budget: the scope was drawn by the old system rather than by how complete the requirements document happened to be.

Only when all three hold does automation translate into cost. Lose one and the verification work falls back on people, at which point the arithmetic reverses: every difference needs an explanation, and the ones that cannot be explained need redesign.

The other numbers in the same release are a different kind of number

Cognizant also published its own internal engineering figures: time to release-ready code cut by more than half, greenfield development accelerated five to six times. These are not the same class of number as the 37%. They are internal engineering metrics with no comparison baseline and no outside check, which makes them useful as direction and nothing more.

What matters more is the kind of work they point at. Greenfield development has no legacy system to serve as an answer key. The requirements are new, acceptance depends on human judgement, and it resists automatic checking. In one document, the work with an answer key produced a cost difference against a named alternative, while the work without one produced only a speed multiple. That pairing draws a usable boundary by itself.

Where the money moves

Traditional rewrites are billed by the person-day or person-month, with the budget tracking headcount for a year or more. What happened here is that seven people delivered a scope that would normally have been staffed on an annual plan, and the client settled on a fixed budget. The thing that disappeared was not capability; it was the contingency headcount and the waiting built into the plan.

There is a direction of interest here worth watching. Under person-day billing, the benefit of automated verification accrues to the client, not to the supplier, so the two sides do not want the same thing. If the efficiency is going to land on your own books, the contract structure has to change first. Fixed budget with explicit acceptance criteria keeps the saving on the buyer’s side far more reliably than open-ended day rates.

The bottleneck is review, not generation

Seven people, and a sign-off from a technical lead or architect before every merge. Those two facts together say what sets the ceiling: how many people can read a change and how many changes they can clear in a round. How much code Devin produces does not move that ceiling. It only moves the waiting from writing to reviewing.

For anyone scoping this kind of programme, the first question is not how strong the model is but how much review capacity exists: who signs, against what standard, and how many items a day. That number decides how large the programme can be and how much a single change should contain — one form at a time, or one module.

When this method does not hold

• The rules are not in the code. If business rules live only in people’s heads and in verbal process, the legacy system cannot supply an answer key, conversion degrades into redesign, and requirement clarification eats the speed advantage.
• Review capacity is too thin. Output piles up in the sign-off queue, throughput is set by the reviewers, and the cost saving never shows up.
• Legacy defects are part of the answer key too. Copying a defect faithfully into the new system is a real risk, so the project has to separate rules from defects first. Nothing automates that line-drawing today.
• The measures differ. The 37% is net cost against a conventional rewrite. It is not a per-task cost, and it does not include the operating and change costs that follow go-live.

What this case does not answer

The release does not say whether rework is inside the 37%. In conversion programmes the largest single time sink is usually discovering a behaviour difference after launch and going back to fix it; if that cost lands in a later phase, the net figure changes. Nor does it say who maintains the generated code, or how later changes keep using the same comparison. Both are diligence questions. If nobody answers them, treat them as unverified.

Making the answer key runnable is work in itself

The answer key does not arrive on its own. Turning legacy behaviour into something comparable means getting the old system running in an isolated environment first: an unmaintained runtime, stubbed dependencies, and a set of historical inputs that can be replayed on demand. Form-driven workflow logic helps here, because its dependencies usually sit inside a database and a file share, which makes the rebuild far cheaper than it would be for a core transaction system.

So the answer key carries a price, and it is paid up front. Plenty of conversion projects stall not on code generation but on a legacy system nobody can start any more: the runtime is gone, a downstream interface was retired years ago, the batch window belongs to another business. Whoever checks that before committing is the one who can credibly promise a fixed budget. None of this work shows up in a case-study narrative, yet every number downstream depends on it.

Which line of the supplier’s income statement this touches

For the efficiency to stay with the supplier, delivery has to move from day rates to fixed price plus reusable assets. When revenue tracks headcount, fewer people means less revenue. Only by turning the process into assets — legacy parsers, generated tests, a behaviour comparison toolchain — can the next project of the same shape be delivered by fewer people for the same scope, and only then does the saving stay on the supplier’s own books. It is also why partnerships like this one grow from a single client project into a standard service line.

A buyer can follow that logic with two questions: who owns the conversion templates and the comparison toolchain, and can they stay with us after the programme ends? If those assets stay with the supplier, how much of the next quote is paying for them twice? Asking precisely tends to make renewals cheaper.

Our read

The replicable part of this case is not Devin and not the 37%. Before handing over its core platform, Odyssey ran the same method on a standalone legacy application, closed that work 21 days after kickoff, and used the result to decide whether to continue. That is an evidence gate. It does not prove the agent is strong; it proves the method closes on their data, their rules and their review capacity.

The second half is harder. Treating the old system as the acceptance standard puts the uncertainty of AI inside a cage that scores itself. What a buyer actually buys is not automatic coding but proof that each change is equivalent to the old behaviour. That sentence can go straight into contract language and straight into an acceptance checklist.

Greenfield work sits outside that cage. No answer key means the best-looking speed multiple still cannot be turned into a signed acceptance result. Two sets of numbers from one supplier, in one release, mark that boundary neatly.

Four things a buyer can do now

• Run the method on a standalone legacy application first and use that result to justify the programme, not the supplier’s case study.
• Put the comparison baseline and scope in the contract so the cost difference can be checked later.
• Write the reviewers and their standard into the delivery process: who signs, whether they sign for behavioural equivalence or code style, and how many items a day.
• Track the share of legacy behaviour that can be compared automatically, and let that number decide whether the scope grows.

Taking the method to another industry: three conditions first

Conversion work exists in every sector: policy rules in insurance, work-order routing in manufacturing, pre-computed reports in banking, customised ERP modules. Whether the method applies depends on three conditions holding together — the legacy behaviour is enumerable, the inputs can be replayed, and differences are machine-checkable. Where one of them fails, the project stops being a conversion and becomes a redesign, with a different cost and schedule model.

• Enumerable behaviour: the rules live in code or configuration rather than in someone’s memory.
• Replayable inputs: historical inputs can be extracted in bulk without depending on retired external systems.
• Machine-checkable differences: a mismatch is something a machine flags, not a judgement about whether two results are close enough.

Where the so-called rules are really carried by human judgement — collections scripts, pricing exceptions, what a long-serving employee knows — the legacy system has no matching behaviour to compare against. Those projects need the process made explicit first, which takes far longer, and a conversion benchmark should not be promised for them.

After the migration, who keeps the comparison harness

Finishing the conversion does not retire the comparison work. Legacy behaviour remains a regression baseline long afterwards: the next form change, added field or reordered validation can be replayed against the same historical inputs to see whether something else broke. Keeping that harness inside the change process is what turns a migration from a one-off delivery into a durable asset.

For a buyer that matters more than the 37%. It converts a project-period discipline — every change signed off — into a default. If the harness stays with the supplier and gets billed per engagement, the same money is paid again at every change of scope.

References

• Cognizant newsroom: Cognizant and Cognition put autonomous AI engineering into production at Odyssey Logistics (23 September 2026)
• Analytics India Magazine: Cognizant, Cognition Claim AI Engineering at Odyssey Logistics Saved 37% Costs
• Third-party market note urging caution: one controlled deployment with mandatory human review does not establish the economics of autonomous code (AllMind, not an audit)