A system, not a model
Scriba AI is an AI-based code conversion platform, built entirely on proprietary technology and without LLMs. It doesn't translate line by line: it reconstructs the application logic and rewrites it in your stack.
- No LLMs
- Proprietary technology
- Deterministic verification gates
- Idiomatic code
Specialized models, deterministic components, proprietary orchestration
Scriba uses no LLMs: no general-purpose language models, whether commercial or open source. It is a system of specialized models and deterministic components, each dedicated to a narrowly defined task, coordinated by an orchestration layer developed in-house and entirely proprietary.
For migrations it works as a service: you send us your legacy application together with the rules of the target system, and we return it to you converted, tested and documented.
Specialized models
Proprietary, each dedicated to a narrowly defined task. No general-purpose language model.
Deterministic components
Each component consumes a specific type of input and produces a repeatable result.
Proprietary orchestration
Sets the sequence, the routing and the conditions for moving forward between components.
Verification gates
Deterministic: moving from one phase to the next depends on passing them.
Main components of the platform
Simplified viewSyntax tree and structural relationships between components, with lexing aware of the vendor's dialect
Semantic analysis: application logic, dependencies, data flows, business rules
Mapping between equivalent constructs across different languages
Code generation following the target's conventions
Specific frameworks and edge cases; when models disagree the case is escalated, with no silent errors
Compilation, types, rule compliance, differential behavioural equivalence
Every input is routed to the component that consumes it: source code to the parsers, target constraints to generation, tests and test cases to the verification gates. That's why the format and completeness of the material you send us determine the quality of the result.
Six phases, a verification gate between each one
The orchestration takes the code through six phases. No phase moves forward unless the previous one has been verified.
Parsing
Syntax tree built with parsers specific to each language and dialect.
Semantic analysis
Types, dependencies, control flow and side effects.
Logic reconstruction
Business rules made explicit, traced and separated from the legacy runtime.
Multi-model
Specialized models in an ensemble: disagreement triggers an escalation.
Validation
Compilation, types, client rules, differential tests on behaviour.
Generation
Idiomatic code in the target, project structure, build and evidence.
Deterministic verification gates: no phase moves forward unless the previous one has been verified.
What changes in practice
If you've already tried migrating code with an LLM, directly or through an agent system, you're used to prompts, iterations and corrections along the way. With Scriba, that approach doesn't apply.
The code is sent to a third-party model, or requires dedicated infrastructure to run
Nothing is sent to model providers; the platform can also run in an isolated (air-gapped) environment
Prompts, skills and conversational iterations
Declarative rules in instructions.md, verified on the output
An error can look plausible and go unnoticed
Disagreement between components triggers an escalation; anything that fails the gates is not delivered
The judgement of whoever reads the output
The execution result of declared tests and quality gates
Token consumption, varying with the iterations
Terms defined before the start
There's no need to send prompts, skills or conversational instructions: Scriba has no language model to address them to. What we need is a precise description of the expected result (instructions.md), the criteria to verify it (test.md) and reference data from the original system.
Five ways to migrate a legacy system, and Scriba AI
Sooner or later, all of them produce code that compiles in the target language. The difference lies in what you can prove about the result: that it behaves like the original, that it follows your rules, that it's maintainable, and what it costs to get there.
| Criterion | AManual | BCommercial tools | CGeneral-purpose LLMs | DAgents on commercial LLMs | EAgents on open-source LLMs | SScriba AI |
|---|---|---|---|---|---|---|
| Understanding of business logic | High, depends on the team | Low: syntactic translation | Limited to the fragment | Limited to the agent's context | Limited to the agent's context | Reconstructed across the whole scope |
| Consistency across hundreds of programs | Left to the team's discipline | High, but on the legacy structure | Not guaranteed | Depends on the pipeline built | Depends on the pipeline built | Guaranteed by orchestration and rules |
| Quality of the code produced | Idiomatic | Often JOBOL | Variable | Variable | Variable | Idiomatic, following your rules |
| Adherence to the client's conventions | Yes, with review | Limited | Repeated with every request | Via prompts, not verified | Via prompts, not verified | Declarative rules verified on the output |
| Equivalence verification | Acceptance testing of known cases | Compilation | None | To be built | To be built | Differential tests against the original |
| Tests and quality gates | Up to the team | Separate project | Separate project | To be built | To be built | Generated, executed, completion criterion |
| Documentation | Often incomplete | Technical, generated | On request, not verified | To be built | To be built | As set out in docs.md, traced to the source |
| Dependencies after migration | None | Vendor runtime and licences, often | None | API subscriptions to evolve | Infrastructure to maintain | None |
| Code confidentiality | In-house | Depends on the vendor | Code sent to third parties | Code sent to third parties | In-house | Governed by NDA and DPA |
| Cost predictability | Low | Medium: licences | Low on large scopes | Low: token consumption | Medium: infrastructure | Fixed, guaranteed price |
| Accountability for the result | The team's or the supplier's | On the tool, not the result | Yours | Yours | Yours | Scriba's, until the gates are passed |
The ratings describe the typical behaviour of each approach; individual tools or projects may differ.
Sooner or later, every alternative produces code that compiles. The useful question is a different one:
How do you prove that the migrated system behaves like the original?
Scriba answers with a verifiable criterion: the migration is complete when the code passes every test and quality gate specified by the client, including differential tests that compare the outputs of the migrated system with those of the original system on the same inputs.
Three practical elements that, with the other approaches, have to be built or negotiated case by case
A single point of contact
Accountable for the result, from code analysis to delivery of the evidence.
No infrastructure
No agent pipeline to build or maintain, no GPUs, no subscriptions to external models.
A price set upfront
Based on the actual scope analysed, not on a consumption estimate.
Idiomatic code, not a line-by-line translation
JOBOL is Java code that keeps the structure of the COBOL it came from. It compiles, but Java developers can't maintain it, and it carries the technical debt over into the new stack.
Scriba reconstructs the application logic and the business rules and rewrites them the way a team that works with that stack every day would write them.
COMPUTE-INTEREST.
IF WS-CONTRACT-TYPE = 'L'
COMPUTE WS-INTEREST ROUNDED =
WS-PRINCIPAL * WS-RATE / 1200
ELSE
MOVE ZEROES TO WS-INTEREST
END-IF.A paragraph that calculates the monthly interest on a leasing contract.
Illustrative, simplified example.
public void computeInterest() {
if (WS.contractType.equals("L")) {
WS.interest = Fmt.pic9(
Double.parseDouble(WS.principal)
* Double.parseDouble(WS.rate)
/ 1200, 9, 2);
} else {
WS.interest = "00000000000";
}
}- Paragraphs turned into methods
- Global variables
- Simulated jumps
- Fixed-length fields handled as strings
public Money monthlyInterest(Contract contract) {
if (contract.type() != ContractType.LEASING) {
return Money.ZERO;
}
return contract.principal()
.multiply(contract.annualRate())
.divide(1200, RoundingMode.HALF_UP);
}- Classes, layers and types of the target language
- Error handling and naming following your instructions file
- Semantics of the original system (decimal arithmetic, sequential record access, return codes) isolated in dedicated, documented components
Put Scriba to the test on your own code
A proof of concept on a closed scope of up to 30,000 lines, with success criteria agreed before the start.