Anthropic's COBOL modernization pitch moved markets before it shipped a product. On February 23, 2026, IBM shares fell 13.2%, their steepest single-day drop since October 2000, after Anthropic claimed that Claude Code could take over the exploration and analysis at the center of COBOL modernization and get teams through it in quarters instead of years. CrowdStrike and Datadog slid the same day.
The claim has since grown teeth: a plugin Anthropic calls code-modernization, documented as proof that the new code behaves like the old, and a webinar built around a live COBOL-to-Java demo. We ran the plugin against real COBOL and graded it and Codegiant on 62 requirements.
The plugin claims it understands the system, but makes basic mistakes. It reports the wrong amount of code, misses business rules, removes messages night operators rely on, and changes records the job didn't touch. Rerunning a failed job can charge a customer twice.
The plugin also tested itself with an exam it wrote and passed. When tested with questions it hadn't written, it couldn't prove its answers were correct.
That's the dangerous gap: a tool that fails loudly costs you a weekend, but a tool that quietly changes code or data, while still running and producing plausible-looking results, can cost you customers.
What follows is the summary of what we found, the baseline we tested against, a comparison chart you can scan in two minutes, and the full deep dive with the evidence behind every point.
Summary
- Coverage. 222 agents, not even 1 program converted correctly. Codegiant runs every program through the same pipeline and the same checks in one run.
- The data model. Each converted program gets its own code for reading records and its own copy of the tables. Codegiant compiles one shared definition per file.
- Discovery. The plugin's inventory is AI-written and wrong: 9 VSAM files where there are 11, and 13 rejected transactions where the run had 38. Codegiant counts from a parser, with every fact tied to the line it came from.
- Rules and the plan. Rule extraction stopped at its limit while it was still finding new rules, and two of its rules contradict the Java it wrote. Codegiant tests every rule against the code it describes.
- Data fidelity. Number handling, empty bytes, code pages, shared-space layouts and unused space all diverge from the mainframe. Codegiant reads them from your own compiler and run-time settings.
- Batch and JCL. No restart point, no file generations, no step conditions, no file locks, and 14 of the 26 operator messages gone. Codegiant compiles the JCL, so the job works the way it did on the mainframe.
- Hard programs. The plugin said the hardest program in the estate “can’t be translated” and planned to rewrite it from notes. Codegiant converts it.
- Proof. The plugin's check ran in the same session that wrote the code, and its own verdict became NOT PROVEN once it was given inputs it had not picked. Codegiant's proof is separate from the conversion.
- Architecture. One AI session holds the plan in its working memory and summarises itself over and over, and no program is tested against the program it hands off to. Codegiant stores every fact and re-reads it at every stage.
- Requirements met. Both products were graded against the same 62 requirements, from whether the code compiles without a vendor runtime to whether a rerun posts twice. The plugin meets 1. Codegiant meets 62.
What we tested
We ran Anthropic's code-modernization plugin for Claude Code, version 1.0.0, on the AWS CardDemo batch estate: 78 files, with CBTRN02C, the nightly posting step of job POSTTRAN, as its pilot. Every output it produced was checked against the COBOL, the JCL and the plugin's own files.
How Codegiant scores against Anthropic's plugin
Claude code-modernization |
Codegiant |
1 of 62 |
62 of 62 ✅ |
Anthropic's code-modernization vs Codegiant: the comparison at a glance
Both are pointed at the same COBOL. One works from its own notes about the system, then writes Java from those notes. The other compiles it. Click any point to jump to the full comparison.
Claude code-modernization |
Codegiant |
|
1. Coverage: how much converts |
0 of 2 |
2 of 2 |
after 222 AI agents, 1 of the 15 programs was converted. |
every program in the system goes through the same pipeline and the same checks in one run. |
|
the Java is rewritten from a description of the program, not from the program, so there’s no way to see what was left out. The program’s error-reporting routine and seven error checks disappeared, and nothing flagged it. |
readable Java, plus a ledger proving every line of COBOL ended up somewhere in the Java. |
|
2. The data model: records and tables |
0 of 2 |
2 of 2 |
the code that turns mainframe records into Java values is hand-written for this one program. Sharing it with the next program is left as a to-do. |
one compiler produces the Java record, the code that reads and writes it, and the database table, all from the same layout, for every program. They can’t disagree. |
|
each converted program creates its own version of the tables it uses. |
one table design per file, created once and versioned. |
|
3. Discovery: knowing what you have |
0 of 5 |
5 of 5 |
the AI wrote the inventory and got it wrong. It counted 9 VSAM files where there are 11 and 8 generation groups (GDGs) where there are 7, and it predicted 13 rejected transactions where the run had 38. |
the inventory comes from a parser, not an AI, and every fact points to the line of code it came from. Counted, not guessed. |
|
nothing it says about the program is stored in a form anyone can check. |
every statement, field and path in the program is recorded with its line number. For this one program that’s 339 statements and 128 fields. |
|
its map of the system leaves out copybooks (the shared record layouts) entirely. |
all 17 copybooks and the 44 places they’re used are on the map. Change a layout and you see every program it touches. |
|
its map of the system disagrees with itself. It draws file links for a program no job ever runs. It says five programs read the transaction file in one place and seven in another. And it says one program updates a file it never touches. |
every link on our map comes from a real line in the JCL or the program, and you can click it to see that line. |
|
the map loses which file generation each job reads and writes, and which steps only run if an earlier step succeeded. |
generations and step conditions are kept for every job step. |
|
4. Rules and the plan |
0 of 4 |
4 of 4 |
rule extraction stopped at its built-in limit while it was still finding new rules. |
rules are written from the proven facts of each program, with no limit to run out of. |
|
two of its rules say the transaction file is wiped at the start of every run. Its own Java does the opposite: it refuses to start unless the file is already empty. |
a separate checker tests every rule against the code it describes. A rule that disagrees doesn’t ship. |
|
it spotted that the COBOL carries on with the previous record when a read fails, wrote that down, then built Java that stops instead. |
business functions are traced backwards from what the program produces, so every path the COBOL takes is kept. |
|
the migration plan is written by the AI from its own memory of the session. |
the plan is calculated from the stored map of the system, so anyone can regenerate it and get the same answer. |
|
5. Data fidelity: numbers, bytes and layouts |
0 of 9 |
9 of 9 |
when it saves a record, it rewrites every field, including ones the program never touched, and changes how their signs are stored. Its own check proved this. |
only the fields the program actually changed are written back. Everything else stays the same, byte for byte. |
|
one fixed way of storing numbers, whatever your shop’s settings are. |
number handling follows your own compiler settings. |
|
mainframe LOW-VALUES are turned into a Unicode placeholder character, in the code and in the database. |
the real bytes are kept, and stored as raw bytes only in the columns where they actually appear. |
|
one hand-built character table for US EBCDIC. |
the character set comes from your settings, including the euro sign and Japanese double-byte text. |
|
the program reads the same two bytes in two ways to show the VSAM error code. That trick was dropped. |
every shared-space layout (REDEFINES) is kept as two views of the same bytes. |
|
it assumes unused space starts as blanks. Its laptop test setup makes the same assumption, so the test agreed with itself. |
taken from your run-time settings and checked against your real records. |
|
counters that wrap around on the mainframe never wrap in Java. |
every number field keeps the mainframe’s size limits and arithmetic rules. |
|
one bad byte in one record stops the whole data load, without saying which record. |
every record is checked first. Bad values are stored safely, nothing is skipped, and every problem is reported by field. |
|
the database sorts keys like a dictionary, not like the mainframe. |
keys sort exactly as they did on the mainframe, so programs that read in key order get the same order. |
|
6. Batch and JCL |
0 of 11 |
11 of 11 |
transactions are written one at a time, with no database transaction around them and no restart. A rerun posts again what was already posted. |
work is saved in batches together with a restart point, so a rerun never posts anything twice. |
|
the database has no idea of generations. |
every table keeps generations, so today’s and yesterday’s versions live side by side. |
|
only one kind (keyed files). |
all kinds: keyed, sequential (ESDS), numbered-slot (RRDS), variable-length, and alternate indexes. |
|
the JCL’s file assignments become one database and two file paths. Pointing a run at test or production data is one typo away. |
the JCL is compiled, so every file assignment works the way it did on the mainframe. |
|
the rejects file, which the mainframe numbers automatically and keeps five copies of, becomes a file name the operator types in. |
generations are numbered, kept and rolled off automatically, as on the mainframe. |
|
nothing stops the same posting job running twice at the same time. Its own reviewer said so. |
files are locked the way the mainframe locks them, and the same job can’t run twice. |
|
the job becomes one Java application, so rules like “skip this step if the last one failed” are gone. |
every step is kept, its return code decides what runs next, and utility steps (IDCAMS, SORT) run too. |
|
the program renames its own output file. |
files are kept, cataloged or deleted at the end of each step, by the job, as on the mainframe. |
|
when 3 of the files fail to open or 4 fail to close, there’s no handling at all, and one close is never checked. |
every file action returns the same IBM status code the COBOL checks. |
|
14 of the 26 messages are gone, including the ones that say which error happened and that the program is stopping. |
every message is kept with its exact text. A missing one stops the build. |
|
the mainframe’s abend code (U0999) becomes exit code 16, which the scheduler’s rules don’t recognise. |
the scheduler sees the same abend codes it always has. |
|
7. Hard programs, layouts and truthfulness |
0 of 7 |
7 of 7 |
it added a crash the COBOL can’t cause, a check the COBOL never makes, a warning the COBOL never prints, and new message texts. |
anything in the Java that has no source in the COBOL is flagged automatically. Claude doesn’t check for this at all. |
|
where the COBOL carries on after certain errors, the Java stops. |
the same behaviour, odd parts included, because that’s what “the same” means. |
|
it never asks how your programs were compiled. None of its 5 setup questions covers it, and it assumes IBM’s defaults. |
we read your compile listings and run-time settings (16 of them), because they change how the same code behaves. |
|
it noticed files that come from outside the system, then didn’t ask about them. |
we account for 125 things that change a program from outside its source: the file catalog, the data, the site setup, the scheduler and mainframe services. |
|
one program changes its own control flow while it runs (ALTER) and reads the mainframe’s job tables directly. Claude said it “can’t be translated” and planned to rewrite it from the rules instead. |
we convert it. The jumps are restructured, and the job information it reads is supplied from the actual run. |
|
variable-size tables (OCCURS DEPENDING ON) and aligned fields (SYNC) are never mentioned. |
every layout follows IBM’s rules, so every field sits where the mainframe puts it. |
|
4 of the 15 programs don’t compile on its laptop COBOL, so they can’t be compared at all. |
every program is handled, with mainframe behaviour taken from IBM’s rules, not from a laptop compiler. |
|
8. Proof: what is checked and against what |
0 of 7 |
7 of 7 |
the output files and 3 lines of the job log. The full log was saved and never compared. |
every output file, return code, file status and log line. |
|
an open-source COBOL on a laptop, with a stand-in for the mainframe’s abend routine. |
real recorded runs from your mainframe. |
|
sample data that couldn’t show its biggest bug, plus test cases it picked itself. Its bad-data test only hit records that were rejected before the bug could happen. |
test data built from every field’s limits and from your real data, plus missing and locked files. |
|
its own report says the check ran in the same session that wrote the code. |
the proof is completely separate from the conversion. |
|
it first reported “20 of 20 identical”. With new inputs, its own verdict became NOT PROVEN. |
one verdict over every input, and nothing ships unproven. |
|
it checks that two counts match but never checks the amounts, and it breaks the code on purpose only twice to see whether the tests notice. |
counts and money totals per file and per account, and every condition is tested by deliberately breaking it. |
|
changes from the original are marked “approved” with no name. One schema choice was made by the AI against its own plan. |
every change has a named approver, a date and the evidence. |
|
9. Scale, determinism and your data |
0 of 2 |
2 of 2 |
by its own numbers, a large bank would need about 155,000 to 215,000 AI agents across 150+ separate runs, merged by hand. |
no AI until the code is split into small pieces, and no limit on size. |
|
its own README says running the same command again can give different results. |
every run gives exactly the same result. |
|
10. Architecture: memory and handoffs |
0 of 5 |
5 of 5 |
the analysis was split across 97 helper agents, each reading a slice and reporting back a summary. A link between two slices survives only if a summary happened to mention it. That’s how the final map lost every copybook and miscounted who reads the transaction file. |
links between programs come from the parser and the JCL compiler, across the whole system at once. No summary sits in between. |
|
each program is converted on its own, with its own code for reading records and its own copy of the tables. What the next program needs to know is written as a to-do note in a text file. |
one shared definition per file, used by every program that touches it. A program can’t read a record differently from the program that wrote it. |
|
each program is proven against its own COBOL, using test data it made itself. Nobody tests that what the posting program writes is exactly what the interest program reads the next night, and seven programs read the transaction file. |
whole job chains run end to end in the proof (backup, then posting, then interest, then combine), with every hand-off compared. |
|
called programs and the data they pass are not converted together. In this run, the statement program and the program it calls weren’t converted at all. |
called programs, the data passed between them and their shared storage are compiled as one unit. |
|
one AI session runs the whole migration and holds the plan in its working memory. Even on this small system, the plan was written from that memory without re-reading the analysis files. A bank’s estate is thousands of times bigger, so the session has to summarise itself over and over, and later decisions are made from summaries of summaries. |
nothing important lives in an AI’s memory. Every fact, decision and link is stored, and every stage re-reads it. |
|
11. The platform |
1 of 8 |
8 of 8 |
doesn’t deploy one-click anywhere. The conversion stops at Java in a folder. |
deploys in one click to AWS, Google Cloud, Azure, Oracle Cloud, DigitalOcean, Cloudflare or Fly.io, or on-premises, or any Kubernetes infrastructure you run. |
|
your data lives in whatever database the conversion picked, and each converted program carries its own copy of the tables. |
your tables go to your own managed database, deployed with the app. |
|
the plugin hands you Java in a folder, and you assemble the rest yourself. |
the whole toolchain is included, nothing to assemble. |
|
the offering stops once the code is converted. |
an AI operations assistant watches the system around the clock, repairs incidents and tunes cost. |
|
MCP and connectors bring the tools you already use into the work: Google Drive, Gmail, Slack, Microsoft 365, Notion, Figma, HubSpot and more. |
Kronos Automate, Codegiant’s own LLM, connects to 3,000+ services so you can build automations and workflows on top of your modernized transformation. Each modernized app gets its own dedicated automation tenant. |
|
none. |
new apps, agents and workflows on the transformed code, with the app builder, workflow builder and automation engine included. |
|
none. |
role- and attribute-based access, audit trails and policy enforcement. |
|
only Claude can run it, and your source goes to the AI provider with usage reporting on by default. |
Kronos models purpose-built for mainframe modernization and automation, which can be self-hosted inside your perimeter for added safety. |
1. Coverage: how much converts
How much gets converted
Claude code-modernization: after 222 AI agents, 1 of the 15 programs was converted.
Codegiant: every program in the system goes through the same pipeline and the same checks in one run.
Nothing gets lost
Claude code-modernization: the Java is rewritten from a description of the program, not from the program, so there’s no way to see what was left out. The program’s error-reporting routine and seven error checks disappeared, and nothing flagged it.
Codegiant: readable Java, plus a ledger proving every line of COBOL ended up somewhere in the Java.
2. The data model: records and tables
Reading the records
Claude code-modernization: the code that turns mainframe records into Java values is hand-written for this one program. Sharing it with the next program is left as a to-do.
Codegiant: one compiler produces the Java record, the code that reads and writes it, and the database table, all from the same layout, for every program. They can’t disagree.
The database design
Claude code-modernization: each converted program creates its own version of the tables it uses.
Codegiant: one table design per file, created once and versioned.
3. Discovery: knowing what you have
Counting what you have
Claude code-modernization: the AI wrote the inventory and got it wrong. It counted 9 VSAM files where there are 11 and 8 generation groups (GDGs) where there are 7, and it predicted 13 rejected transactions where the run had 38.
Codegiant: the inventory comes from a parser, not an AI, and every fact points to the line of code it came from. Counted, not guessed.
Checkable facts
Claude code-modernization: nothing it says about the program is stored in a form anyone can check.
Codegiant: every statement, field and path in the program is recorded with its line number. For this one program that’s 339 statements and 128 fields.
Shared layouts
Claude code-modernization: its map of the system leaves out copybooks (the shared record layouts) entirely.
Codegiant: all 17 copybooks and the 44 places they’re used are on the map. Change a layout and you see every program it touches.
A map you can trust
Claude code-modernization: its map of the system disagrees with itself. It draws file links for a program no job ever runs. It says five programs read the transaction file in one place and seven in another. And it says one program updates a file it never touches.
Codegiant: every link on our map comes from a real line in the JCL or the program, and you can click it to see that line.
How jobs hand off to each other
Claude code-modernization: the map loses which file generation each job reads and writes, and which steps only run if an earlier step succeeded.
Codegiant: generations and step conditions are kept for every job step.
4. Rules and the plan
Finding all the rules
Claude code-modernization: rule extraction stopped at its built-in limit while it was still finding new rules.
Codegiant: rules are written from the proven facts of each program, with no limit to run out of.
Rules that agree with the code
Claude code-modernization: two of its rules say the transaction file is wiped at the start of every run. Its own Java does the opposite: it refuses to start unless the file is already empty.
Codegiant: a separate checker tests every rule against the code it describes. A rule that disagrees doesn’t ship.
Keeping the quirks
Claude code-modernization: it spotted that the COBOL carries on with the previous record when a read fails, wrote that down, then built Java that stops instead.
Codegiant: business functions are traced backwards from what the program produces, so every path the COBOL takes is kept.
The plan
Claude code-modernization: the migration plan is written by the AI from its own memory of the session.
Codegiant: the plan is calculated from the stored map of the system, so anyone can regenerate it and get the same answer.
5. Data fidelity: numbers, bytes and layouts
Records nobody changed stay unchanged
Claude code-modernization: when it saves a record, it rewrites every field, including ones the program never touched, and changes how their signs are stored. Its own check proved this.
Codegiant: only the fields the program actually changed are written back. Everything else stays the same, byte for byte.
Your mainframe’s number settings
Claude code-modernization: one fixed way of storing numbers, whatever your shop’s settings are.
Codegiant: number handling follows your own compiler settings.
Special “empty” bytes
Claude code-modernization: mainframe LOW-VALUES are turned into a Unicode placeholder character, in the code and in the database.
Codegiant: the real bytes are kept, and stored as raw bytes only in the columns where they actually appear.
Characters and languages
Claude code-modernization: one hand-built character table for US EBCDIC.
Codegiant: the character set comes from your settings, including the euro sign and Japanese double-byte text.
Fields that share space
Claude code-modernization: the program reads the same two bytes in two ways to show the VSAM error code. That trick was dropped.
Codegiant: every shared-space layout (REDEFINES) is kept as two views of the same bytes.
Unused space in records
Claude code-modernization: it assumes unused space starts as blanks. Its laptop test setup makes the same assumption, so the test agreed with itself.
Codegiant: taken from your run-time settings and checked against your real records.
Size limits on numbers
Claude code-modernization: counters that wrap around on the mainframe never wrap in Java.
Codegiant: every number field keeps the mainframe’s size limits and arithmetic rules.
Loading bad data
Claude code-modernization: one bad byte in one record stops the whole data load, without saying which record.
Codegiant: every record is checked first. Bad values are stored safely, nothing is skipped, and every problem is reported by field.
Sort order
Claude code-modernization: the database sorts keys like a dictionary, not like the mainframe.
Codegiant: keys sort exactly as they did on the mainframe, so programs that read in key order get the same order.
6. Batch and JCL
Restarting after a failure
Claude code-modernization: transactions are written one at a time, with no database transaction around them and no restart. A rerun posts again what was already posted.
Codegiant: work is saved in batches together with a restart point, so a rerun never posts anything twice.
File generations
Claude code-modernization: the database has no idea of generations.
Codegiant: every table keeps generations, so today’s and yesterday’s versions live side by side.
Every kind of VSAM file
Claude code-modernization: only one kind (keyed files).
Codegiant: all kinds: keyed, sequential (ESDS), numbered-slot (RRDS), variable-length, and alternate indexes.
Which file a program uses
Claude code-modernization: the JCL’s file assignments become one database and two file paths. Pointing a run at test or production data is one typo away.
Codegiant: the JCL is compiled, so every file assignment works the way it did on the mainframe.
Generations of output
Claude code-modernization: the rejects file, which the mainframe numbers automatically and keeps five copies of, becomes a file name the operator types in.
Codegiant: generations are numbered, kept and rolled off automatically, as on the mainframe.
Two runs at once
Claude code-modernization: nothing stops the same posting job running twice at the same time. Its own reviewer said so.
Codegiant: files are locked the way the mainframe locks them, and the same job can’t run twice.
Steps in a job
Claude code-modernization: the job becomes one Java application, so rules like “skip this step if the last one failed” are gone.
Codegiant: every step is kept, its return code decides what runs next, and utility steps (IDCAMS, SORT) run too.
What happens to files after a step
Claude code-modernization: the program renames its own output file.
Codegiant: files are kept, cataloged or deleted at the end of each step, by the job, as on the mainframe.
Errors on files
Claude code-modernization: when 3 of the files fail to open or 4 fail to close, there’s no handling at all, and one close is never checked.
Codegiant: every file action returns the same IBM status code the COBOL checks.
Messages for the night operator
Claude code-modernization: 14 of the 26 messages are gone, including the ones that say which error happened and that the program is stopping.
Codegiant: every message is kept with its exact text. A missing one stops the build.
How a failure looks to the scheduler
Claude code-modernization: the mainframe’s abend code (U0999) becomes exit code 16, which the scheduler’s rules don’t recognise.
Codegiant: the scheduler sees the same abend codes it always has.
7. Hard programs, layouts and truthfulness
Made-up behaviour
Claude code-modernization: it added a crash the COBOL can’t cause, a check the COBOL never makes, a warning the COBOL never prints, and new message texts.
Codegiant: anything in the Java that has no source in the COBOL is flagged automatically. Claude doesn’t check for this at all.
The odd behaviour, kept
Claude code-modernization: where the COBOL carries on after certain errors, the Java stops.
Codegiant: the same behaviour, odd parts included, because that’s what “the same” means.
Compiler settings
Claude code-modernization: it never asks how your programs were compiled. None of its 5 setup questions covers it, and it assumes IBM’s defaults.
Codegiant: we read your compile listings and run-time settings (16 of them), because they change how the same code behaves.
Everything outside the code
Claude code-modernization: it noticed files that come from outside the system, then didn’t ask about them.
Codegiant: we account for 125 things that change a program from outside its source: the file catalog, the data, the site setup, the scheduler and mainframe services.
The hardest program
Claude code-modernization: one program changes its own control flow while it runs (ALTER) and reads the mainframe’s job tables directly. Claude said it “can’t be translated” and planned to rewrite it from the rules instead.
Codegiant: we convert it. The jumps are restructured, and the job information it reads is supplied from the actual run.
Tricky record layouts
Claude code-modernization: variable-size tables (OCCURS DEPENDING ON) and aligned fields (SYNC) are never mentioned.
Codegiant: every layout follows IBM’s rules, so every field sits where the mainframe puts it.
Programs its test can’t run
Claude code-modernization: 4 of the 15 programs don’t compile on its laptop COBOL, so they can’t be compared at all.
Codegiant: every program is handled, with mainframe behaviour taken from IBM’s rules, not from a laptop compiler.
8. Proof: what is checked and against what
What gets compared
Claude code-modernization: the output files and 3 lines of the job log. The full log was saved and never compared.
Codegiant: every output file, return code, file status and log line.
What it’s compared against
Claude code-modernization: an open-source COBOL on a laptop, with a stand-in for the mainframe’s abend routine.
Codegiant: real recorded runs from your mainframe.
The test data
Claude code-modernization: sample data that couldn’t show its biggest bug, plus test cases it picked itself. Its bad-data test only hit records that were rejected before the bug could happen.
Codegiant: test data built from every field’s limits and from your real data, plus missing and locked files.
Who checks the work
Claude code-modernization: its own report says the check ran in the same session that wrote the code.
Codegiant: the proof is completely separate from the conversion.
The verdict
Claude code-modernization: it first reported “20 of 20 identical”. With new inputs, its own verdict became NOT PROVEN.
Codegiant: one verdict over every input, and nothing ships unproven.
Money and test strength
Claude code-modernization: it checks that two counts match but never checks the amounts, and it breaks the code on purpose only twice to see whether the tests notice.
Codegiant: counts and money totals per file and per account, and every condition is tested by deliberately breaking it.
Who approved the changes
Claude code-modernization: changes from the original are marked “approved” with no name. One schema choice was made by the AI against its own plan.
Codegiant: every change has a named approver, a date and the evidence.
9. Scale, determinism and your data
A real bank
Claude code-modernization: by its own numbers, a large bank would need about 155,000 to 215,000 AI agents across 150+ separate runs, merged by hand.
Codegiant: no AI until the code is split into small pieces, and no limit on size.
Same answer twice
Claude code-modernization: its own README says running the same command again can give different results.
Codegiant: every run gives exactly the same result.
10. Architecture: memory and handoffs
Helpers who each see one piece
Claude code-modernization: the analysis was split across 97 helper agents, each reading a slice and reporting back a summary. A link between two slices survives only if a summary happened to mention it. That’s how the final map lost every copybook and miscounted who reads the transaction file.
Codegiant: links between programs come from the parser and the JCL compiler, across the whole system at once. No summary sits in between.
Programs stop knowing about each other after conversion
Claude code-modernization: each program is converted on its own, with its own code for reading records and its own copy of the tables. What the next program needs to know is written as a to-do note in a text file.
Codegiant: one shared definition per file, used by every program that touches it. A program can’t read a record differently from the program that wrote it.
The hand-off between programs is never tested
Claude code-modernization: each program is proven against its own COBOL, using test data it made itself. Nobody tests that what the posting program writes is exactly what the interest program reads the next night, and seven programs read the transaction file.
Codegiant: whole job chains run end to end in the proof (backup, then posting, then interest, then combine), with every hand-off compared.
Programs that call each other
Claude code-modernization: called programs and the data they pass are not converted together. In this run, the statement program and the program it calls weren’t converted at all.
Codegiant: called programs, the data passed between them and their shared storage are compiled as one unit.
One brain, with a limited memory
Claude code-modernization: one AI session runs the whole migration and holds the plan in its working memory. Even on this small system, the plan was written from that memory without re-reading the analysis files. A bank’s estate is thousands of times bigger, so the session has to summarise itself over and over, and later decisions are made from summaries of summaries.
Codegiant: nothing important lives in an AI’s memory. Every fact, decision and link is stored, and every stage re-reads it.
11. The platform
One-click deploy
Claude code-modernization: doesn’t deploy one-click anywhere. The conversion stops at Java in a folder.
Codegiant: the converted app deploys in one click to the client’s choice of AWS, Google Cloud, Azure, Oracle Cloud, DigitalOcean, Cloudflare or Fly.io, or on-premises, or any Kubernetes infrastructure you run.
Database
Claude code-modernization: your data lives in whatever database the conversion picked, and each converted program carries its own copy of the tables.
Codegiant: the PostgreSQL tables go to the client’s managed database, deployed with the app.
DevSecOps
Claude code-modernization: the plugin hands you Java in a folder, and you assemble the rest yourself.
Codegiant: its own toolchain with nothing to wire up: Git, CI/CD, Terraform, observability, error and performance monitoring, uptime checks, status pages, docs and code review.
After go-live
Claude code-modernization: the offering stops once the code is converted.
Codegiant: AI SRE, 24/7. It watches the running system, repairs incidents, tunes cost and scaling, catches security drift and keeps runbooks current.
Connect
Claude code-modernization: MCP and connectors bring the tools you already use into the work: Google Drive, Gmail, Slack, Microsoft 365, Notion, Figma, HubSpot and more.
Codegiant: Kronos Automate, Codegiant’s own LLM, connects to 3,000+ services so you can build automations and workflows on top of your modernized transformation. Each modernized app gets its own dedicated automation tenant, running an enterprise-grade engine that supports hundreds of millions of events per month.
Build
Claude code-modernization: none.
Codegiant: new apps, agents and workflows on top of the transformed code. The app builder, the workflow builder for agents and the automation engine are all included, with no add-ons and nothing to bolt on.
Governance
Claude code-modernization: none.
Codegiant: role- and attribute-based access, audit trails and policy enforcement across everything.
Purpose Built Models
Claude code-modernization: only Claude can run it, and your source goes to the AI provider with usage reporting on by default.
Codegiant: Kronos models purpose-built for mainframe modernization and automation, which can be self-hosted inside your perimeter for added safety.
The bottom line
Claude code-modernization is not a tool you can trust with production COBOL. It does not replace your mainframe with Java. It gives you a folder of Java and a summary of what it thinks your system does, and the summary is wrong: the inventory miscounts your files, the map disagrees with itself, the rules contradict the code it wrote, and the exam that says it works is one it marked itself. The failures are silent. The code compiles and the job runs while records change and a rerun charges a customer twice. It cannot scale either. Based on our own tests, a real production codebase would take a ridiculous number of agents, and you would have to merge the results by hand. In our CardDemo test it met 1 of the 62 checks in the comparison above, and the one it met was a connector.
Codegiant runs every program through one pipeline, proves the result against your recorded mainframe runs, and hands you Java on your own database that deploys to your cloud. The difference is between a demo that compiles on a laptop and a system your night operators can actually run.
Related Reading
Try Codegiant's Enterprise AI Platform Today
Codegiant is an enterprise AI platform that gives you full control of the code. What comes out of the conversion is yours: no vendor runtime, no proprietary binary, no engine underneath it. You can read it, change it, and run it wherever you want.
Nothing gets bolted on afterwards. The DevSecOps toolchain, CI/CD, Terraform, observability, uptime checks and AI SRE come with the conversion, and the finished application deploys in one click to AWS, Google Cloud, Azure, Oracle Cloud, DigitalOcean, Cloudflare or Fly.io, or on-premises, or any Kubernetes infrastructure you run.
Kronos Automate, our own LLM, connects the modernized system to 3,000+ services so you can build automations and workflows on top of it. Each modernized app gets its own dedicated automation tenant, running an enterprise-grade engine that supports hundreds of millions of events per month. That is what strict modernization requirements actually demand, and it is the part most platforms stop short of: every target your own policy allows, the whole toolchain in your hands, and no binary, no runtime and no lock-in carried into the next project.