About the project
Inspiration
Legacy software is rarely “just old code.” It contains years of customer data, orders, payments, inventory decisions, workflows, and business rules that may never have been formally documented.
That is what inspired us to build tviqOS — an AI Modernization Engineer.
Today, AI coding tools are becoming very good at generating new code, but modernizing a real legacy system is a different problem. The biggest risk is not whether AI can produce a new application. It is whether the new application still behaves like the old one where the business actually depends on it.
Our core idea is simple:
Don't rewrite. Understand first.
tviqOS is designed to understand a legacy repository before transforming it, extract the business logic hidden inside the system, research current modernization patterns, create a migration plan, and then verify that the modern system preserves the behavior that matters.
What we built
We designed tviqOS as a modernization operating system rather than a one-shot AI code converter.
The workflow is:
Ingest → Trace → Blueprint → Generate → Verify
A repository can contain source code, databases, APIs, configuration, documentation, logs, and years of accumulated technical decisions. tviqOS turns these signals into an evidence-backed modernization workflow.
The system is organized around three AI roles:
- Archaeologist — Excavate the legacy
- Reads code, databases, APIs, configuration, Git history, documentation, and logs.
- Builds a System Map showing how the existing system works.
- Identifies implicit business rules and dependencies.
- Architect — Design the path
- Determines how the system can be modernized safely.
- Uses Tavily to bring current technology and migration knowledge into the decision-making process.
- Produces a modernization Blueprint, rather than blindly converting every file.
- Engineer — Build & compare
- Generates the modern implementation.
- Runs it inside a sandbox.
- Executes scenarios against both legacy and modern systems.
- Compares their outputs and identifies behavioral drift.
The result is not simply “new code.” It is evidence that the new system still behaves correctly.
Why Tavily matters
Modernization decisions should not be based only on what an AI model learned in the past.
Frameworks change. Migration strategies change. APIs are deprecated. Recommended architectures evolve.
We therefore integrate Tavily into the Architect stage so tviqOS can research the current technology landscape while planning a migration. The research becomes part of the modernization evidence rather than an isolated web search.
In our prototype, the product interface explicitly surfaces the research step as “current migration intelligence”, connecting the modernization plan with verified external sources.
How we built it
The architecture combines several layers:
- Repository / MCP for interacting with the existing software system.
- Code, database and logs as the raw evidence.
- A sandbox runtime for safely executing generated changes.
- tviqOS Agent Orchestrator for coordinating the workflow.
- NVIDIA Nemotron as the reasoning core.
- Nebius as the inference and compute layer.
- Tavily for current-world technology and migration intelligence.
The overall loop is:
$$ \text{Observe} \rightarrow \text{Reason} \rightarrow \text{Research} \rightarrow \text{Act} \rightarrow \text{Compare} $$
This architecture is intended to make AI useful in a high-risk engineering environment without treating AI output as automatically correct.
What we learned
The biggest lesson was that modernization is fundamentally a knowledge problem before it is a coding problem.
A legacy system may have relatively simple-looking code while containing complicated business behavior. The most important rules may be spread across database constraints, API behavior, conditionals, configuration, workflows, and undocumented conventions.
We also learned that an AI modernization system needs to make its reasoning inspectable.
Instead of simply saying:
“The migration succeeded.”
tviqOS should be able to show:
- what it discovered,
- why it made a migration decision,
- which business rules were identified,
- what changed,
- which scenarios were tested,
- where behavior differs,
- and where a human needs to make a decision.
That led us to design confidence gates and human review points into the workflow. AI can observe and propose autonomously, but consequential ambiguity should remain visible to a human engineer.
The biggest challenge
The hardest problem is not generating the target application.
It is proving that the target application has not silently changed the business.
For example, a legacy order system may contain an undocumented rule involving customer status, order value, and payment verification. A developer looking only at the UI may never know that rule exists.
tviqOS therefore treats business rules as first-class artifacts. It extracts them, maps them to evidence, and compares behavior between the legacy and modern implementations.
Our prototype demonstrates this concept through a Business Rule Diff and scenario comparison workflow, where preserved and changed rules can be inspected rather than hidden behind a single success score.
Another challenge was avoiding the temptation to build a “magic AI migration” demo. A perfect-looking conversion can be impressive but does not necessarily prove that the system is useful in the real world.
We therefore changed the product philosophy from:
“AI migrates your application.”
to:
“AI helps you understand, modernize, and prove your application.”
That distinction became central to tviqOS.
What comes next
We are starting deliberately narrow.
The first target is a real legacy CRM-style application, such as:
PHP + MySQL → Next.js + FastAPI
The goal is to prove three things:
- Can we reliably build a useful System Map?
- Can we extract meaningful business rules?
- Can we demonstrate behavioral equivalence through scenario-based verification?
From there, the roadmap is to move from one real repository to a delivery team using tviqOS across multiple modernization projects, and eventually into a broader Modernization OS with multi-repository workspaces, reusable migration playbooks, audit trails, and enterprise governance.
Our vision is not to replace experienced engineers.
It is to give them something legacy modernization has historically lacked:
a system that can remember what the old software actually does, explain why it matters, and provide evidence before the team ships the new version.
Log in or sign up for Devpost to join the conversation.