Why legacy is the best place to start with AI
Brazilian companies run on systems that are 10, 15, 20 years old: PHP ERPs, Java applications on outdated servers, .NET Framework systems tied to a specific Windows box, COBOL routines in banks and insurers. The common problem is not the code; it is the knowledge that left the company with whoever wrote it. Nobody knows exactly what a routine does, so nobody touches it.
Language models are very good at exactly that: reading code and explaining in plain language what it does. It is a low-risk application (the AI changes nothing, it only describes), with immediate return (documentation in hours, not months) and no need to train a model or buy a platform. The large vendors reached the same conclusion: Google uses Gemini to generate specifications from COBOL in its mainframe assessment tool, and AWS repositioned mainframe modernization around AI agents.
What works today
Four uses are mature. Documentation: generating a module map, screen descriptions, scheduled routines and external dependencies from the code, reviewed by someone who knows the system. Business-rule extraction: turning scattered conditionals into a readable list of rules ("5% discount for orders above X, except customers of type Y"), which becomes the specification for the new version. Test generation: creating test cases from current behaviour, which later validate the functional equivalence of the modernized module. Assisted translation: converting a PHP 5 module to PHP 8, or a COBOL routine to Java, with the developer reviewing line by line.
In all four, the pattern is the same: the AI produces the draft, the human validates against the real system. At JBKR that means running the generated test against the production system before accepting any description.
What does not work yet
Rewriting a whole system "with one button" does not work, and anyone promising it is selling you 2028's problem. Models get implicit rules wrong (what the system does by accident and the business came to depend on), code with embedded data and undocumented integrations. Automatic language migrations produce code that compiles and behaves differently, and the difference shows up at month-end close, in tax filing, in the customer who complains.
It also does not work without governance: pasting a client's source code into a public chat violates contracts and privacy law. Use APIs under an enterprise agreement that does not retain data for training, or private models on the client's infrastructure. JBKR publishes those commitments on its Responsible AI page.
How JBKR uses AI in the legacy assessment
JBKR's two-week assessment has four stages, and AI takes part in three. Inventory: assisted reading of code, database and server to map modules, routines and integrations. Risks: ranking by urgency (unsupported versions, missing backups, single-person dependency); here AI helps list, the human decides what is serious. Documentation: a model-generated draft, reviewed and tested against real behaviour. Roadmap: modernization options (in place, rehost, replatform, refactor) with estimates, without AI, because estimating is experience.
The report is delivered in writing and stays with the client, even if the next step is done by another team. Usually the outcome is that the company discovers it needs to modernize two or three modules, not the whole system, and that the rest only needs a version update and backups.
The COBOL case in Brazil
Brazilian banks, insurers and public bodies still depend on COBOL routines, and the problem is demographic: the professionals who wrote them are retiring, and market vendors point to that generation's exit as the decade's biggest risk. JBKR's founder started his career with two years on the IBM mainframe at HSBC (z/OS, COBOL, JCL, CICS, DB2) and recognizes the pattern: the documentation lives in two people's heads.
AI changes the economics of that problem: a 3,000-line COBOL routine can have a readable explanation and a set of test cases in one day of assisted work instead of weeks of reading. It does not replace the specialist; it lets one specialist cover ten times more code. For large projects, JBKR brings in specialists on demand under the founder's technical coordination.
Where to start
Pick the system you are most afraid to touch and ask for an assessment, not a migration. In two weeks you will have documentation, risks and a written roadmap, at a cost that fits the On-Demand plan. Then decide, with information, whether to modernize in parts, move to the cloud or just update and protect.
At JBKR the initial 30-minute assessment is free and the two-week report is yours. The promise has been the same for 20 years: understand before touching, and never stop operations.
