Dr. Consulta modernized its eight-year-old subscription platform with coding agents, with its own team supervising.
Dr. Consulta, a network of medical centers, used Ithaca's agentic development platform to modernize its subscription system, which had been in production for eight years. The new system was built alongside the old one and took over in parts while the current system kept running, and Dr. Consulta's own team supervised the coding agents throughout. What changed: the time to ship a feature, who makes text changes, how maintenance is done and infrastructure cost, with the numbers in the table below.
Who this page is for
For CTOs and heads of engineering who have heard the "AI that writes code" pitch before and want a concrete case: what changed, what was measured and what the operation did not promise. It also serves readers who came from legacy system modernization and want operational proof before requesting a deployment.
The full method is on the legacy modernization page. This page covers the Dr. Consulta deployment, Challenge B (refactor legacy).
The problem
Dr. Consulta's subscription platform had been in production for eight years. New features took a long time to build. Touching what already ran was frightening. Maintenance consumed the team. A text change needed a developer. Infrastructure cost grew with the weight of the legacy system.
None of this is unusual for anyone running a critical system in healthcare. The hard part was modernizing without losing what the business already depended on, and without handing control to a black box.
What was done
Dr. Consulta used the agentic development platform for Challenge B: refactor legacy. The path is the one described in legacy system modernization:
- Knowledge base. Code, documentation and anonymized data go in before any new line is written.
- Build beside it. The replacement is built modern and typed, without taking down what still serves.
- Check. Each part is compared with the old system's behavior before it goes in.
- Switch in parts. One part that can be checked goes to production; the next one starts after that.
Coding agents do most of the writing. Dr. Consulta's team sets the limit, reads what goes to production and answers for the result. The platform runs at level 4 of the autonomy scale Dan Shapiro proposed; level 5 is the dark factory. The reasoning is in AI governance in software development and on the dark factory page.
What changed
| Dimension | Before | With the platform | Note |
|---|---|---|---|
| A feature | About two weeks | Up to three days | One representative feature, not a measurement of the whole backlog |
| A text change | A developer | A product manager | No developer ticket needed for the change |
| Maintenance | By hand | Supervising the AI | Sustainment, with the team in control |
| Infrastructure cost | The period before the modernization | 75% lower | Compared with that period |
Each refactored part was checked against the old system's behavior before it went to production.
How supervision and traceability worked in the operation
- Autonomy limit. The team defines how far coding agents go without prior approval and what needs a person's sign-off before it runs. Reading what goes to production applies to everything, and nothing reaches production unread.
- Human reading. To level 4 of Dan Shapiro's scale, Ithaca adds one rule: people on the team read the code that goes to production. When something breaks, someone on the team already knows the code. At level 5, the dark factory, nobody reads it.
- A logged session. The request, the steps, the model, the cost, the result and the authorship are recorded. With that record, each delivery can be audited and improved. The detail of the record is in Observability for coding agents and in the AI governance checklist.
- Sustainment. After the switch, maintenance no longer depends only on people working by hand in the legacy code: tickets come in and fixes go out, with the team supervising the AI.
Limits of this case
- Measurement. The feature that went from about two weeks to up to three days is one representative example, not a measurement of the whole backlog.
- Risk. A failure is still possible. What changes is how much damage it can do and how easy it is to find the cause.
- Operations. The current system keeps serving while the new one is built beside it. Switching parts over may require a maintenance window. There is no zero-downtime promise.
- Compliance. It follows the client's policy and the design of the deployment.
Frequently asked questions
What did Dr. Consulta modernize?
Dr. Consulta modernized its subscription platform, a system with eight years in production, under Challenge B (refactor legacy), using Ithaca's agentic development platform.
What changed at Dr. Consulta?
One feature that took about two weeks took up to three days (a representative example, not a measurement of the whole backlog); text changes are made by a product manager instead of a developer; maintenance moved from work done by hand to supervising the AI; and infrastructure cost is 75% lower than in the period before the modernization.
Was this done without stopping the business?
The method is to build beside the current system and switch in parts, with the current system still running. Switching parts over may require a maintenance window, and there is no zero-downtime promise. The method and its risks are described in Legacy modernization without stopping the business.
Who supervised what the AI wrote?
Dr. Consulta's team. Coding agents execute; people on the team read what goes to production and set the limit. That is level 4 on Dan Shapiro's scale, plus one rule Ithaca adds: human reading before production.
Where does the platform run, and does the code leave the client's network?
The platform is deployed in the client's environment, on a cloud account the client controls or in its own data center, and the repository is not sent to an Ithaca SaaS. Model calls follow the client's policy for provider, region and contract; during inference, code excerpts may go to the chosen model provider under that policy.
Where does a similar deployment start?
A similar deployment starts with one part that can be checked end to end, usually the part that eats the most maintenance. The whole system comes later.
Book a demo
If your legacy system looks like this one, with years in production, slow features, a codebase nobody wants to touch and expensive infrastructure, the next step is a demo of the platform on the first part that can be checked end to end. The deployment starts there, alongside your team.
