When the runbook becomes the operator: how Cortex Code cut a five-day data migration to one

80 percent less engineer time. 21 production tables. 8 hours instead of 5 days.

That is the headline result from a recent migration we ran on a large enterprise data platform, using an AI coding assistant with live access to the Snowflake environment. The number is genuine, and we can hit it again on the next migration that looks like this one. But quoting it without the context behind it sets up the wrong expectations for any team looking to do the same.

This is a short account of what was migrated, how the assistant accelerated it, what it could not have done without the team's prior investment, and the four other places we expect the same pattern to apply.

The job: 21 tables, one slice of a 40-pipeline backlog

The migration moved 21 production tables off a legacy ETL platform onto a Snowflakenative ingestion framework built on Apache NiFi. Each table had between 20 and 130 columns. Each column needed to match, by name and by data type, the legacy production schema, so that downstream dashboards and reconciliation processes saw no change. On top of the column mapping, the source system returned timestamps in Microsoft's /Date(epoch_ms)/ notation, the legacy ETL had emulated a half-dozen audit columns the new framework did not produce natively, and every table had to pass a four-test validation suite before it could ship. Multiply that by 21 and you have a week's work for an experienced engineer.

This migration is one slice of a broader program. The platform has over 40 legacy ingestion pipelines on the backlog for the same modernisation effort, of which roughly 15 are structurally similar to the one described here. Those 15 are candidates for the same 80 percent compression on the day they are executed.

The 80 percent saving is real on the day. It is also the part of the story that most needs context.

The 80 percent doesn't include the runway

Before the assistant touched anything, the team had already paid a significant fixed cost. The ingestion framework had been established during the initial design. A ~700-line migration runbook had been written, edited, and refined across several earlier table migrations. The four-test validation suite, the test-results page template, the filenaming conventions, the cutover process, and the live execution bridge between the assistant and the Snowflake environment were all in place. None of that work appears
in the 8-hour number.

The right way to read the result is this. The investment in framework, documentation, and tooling has a fixed cost that is paid whether or not an assistant is involved. The assistant does not reduce that cost. What it does is sharply reduce the marginal cost of every migration that follows, once the pattern is established. Table one is expensive. Tables two through 21 are almost free.

A leadership team that hears "5 days into one" and expects the same compression on the first project a new tool touches will be disappointed in the pilot. The compounding only starts after the runway is built.

Where the 80 percent actually came from

The assistant did not do anything an engineer could not have done. What it did was remove the friction between the steps.

For a single table, the workflow is unglamorous: query the legacy schema, query the new staging environment, build a view that reshapes the new staging table to match the legacy contract, apply the COALESCE recipe to timestamp columns, hardcode the audit columns, insert a control record, write four validation queries, run them, record the results. Each step is uncomplicated. The cognitive load comes from doing it 21 times without losing place.

The assistant compresses this for three concrete reasons, none of which involve cleverness.

No context switching. A human engineer flips between the source schema, the target schema, the view template, the test queries, and the documentation template, and pays a tax on every switch. The assistant holds all of those in working memory simultaneously and emits output in the order the runbook prescribes.

No typos on columns it has just queried. When the source of truth for a column name is a live INFORMATION_SCHEMA query, the assistant has no opportunity to introduce the half-percent typo rate a human keyboard does by default.

Documentation written in the same session as the code. The test results and the deployment notes are produced while the context is still loaded, rather than as an afterthought hours later when the details have started to fade.

None of these are glamorous. They compound across 21 tables and look like 80 percent on the day.

What got delivered, in one session

Inside one supervised session, the assistant generated and executed the following:

Metadata inserts 21 idempotent DELETE + INSERT blocks, packaged as a Flyway versioned migration Test suite 84 assertions (4 tests x 21 tables) run live against Snowflake, all passed Flow definition Openflow flow JSON with parameter context, UTC-converted cron schedule, and bundle version pin Documentation Deployment page and test-results wiki page written in the team's standard voice and structure 

The engineer's role across the session was to direct, to verify, and to make the small number of judgement calls the runbook did not cover. The pull-request review process did not change. The four-test validation suite did not change. The deployment cycle did not change. What changed was the elapsed time inside the engineer-supervised portion of the work.

On novel work, it stops being the executor

So much for repeatable work. The more interesting question is what happens on work that is not repeatable, and this is where the case for the technology shifts shape.

Genuinely new work, like designing a new ingestion pattern, modelling a new business domain, or debugging a production failure with no obvious cause, is where the runbook does not yet exist. There is no procedure to follow, no template to fill in, no validation suite to execute. On work like that, the assistant is not the executor. The engineer is the executor, and the assistant becomes the second pair of eyes.

This is the quieter use case and it does not generate 80 percent productivity numbers. What it does generate is fewer mistakes that ship, fewer review cycles caused by oversights that should have been caught earlier, and a reduction in the slow drip of small frustrations that come from working alone on complex material. The assistant becomes the colleague you would have asked to look over your shoulder, available at every moment.

For engineering leaders, this dual nature is the important point. The headline use case is the easier business case to make. The quieter use case is likely where the productivity actually accumulates across the year. A team that catches three small bugs per engineer per week in design rather than in production saves more time than any one-off automation.

The runbook is the real technology

Credit the model and you will misdiagnose the result. The model is good. The model is not the differentiator.

The differentiator is the runbook. The migration page the assistant consumed was approximately 700 lines of structured procedure, written explicitly to be executed by an AI assistant and read by a human engineer in the same breath. Its opening sentence reads: "This page provides a complete step-by-step procedure for migrating an ingestion job to the new framework. It is written for consumption by an AI assistant to fast-track migrations, but is also human-readable for reference."

A team that writes its institutional knowledge down in this style produces an asset that compounds. Every engineer who reads it absorbs the procedure faster. Every assistant that executes it produces output the team trusts. Every edge case discovered on a Tuesday becomes a row in the common-pitfalls table by Wednesday. The runbook accumulates institutional learning in a form that survives staff turnover and technology change.

Most teams do not have runbooks like this. The practical guidance is uncomfortable but simple. Invest in the runbook first. Invest in the live-execution capability second. The model itself is the third investment and the least differentiated of the three. Vendors will sell you the third one. The first two are on you.

Where else the pattern shows up

The migration case study is a clean illustration, but the same shape of work appears in many corners of an enterprise data platform.

In every one of these cases, the productivity story has the same shape. Structured procedure plus live execution. The assistant executes a process the team has already written down. Where no process exists yet, the assistant becomes a reviewer and a sanity check, and the value shifts from speed to quality.

The takeaway

The migration result is real. 21 tables in 8 hours is a number worth talking about, and the 80 percent saving on this class of work is reproducible on every migration that fits the same pattern. The value of the result, though, is in what it implies about the conditions that produced it.

If your organisation is considering AI productivity tooling for data engineering, the question is not whether the model is good enough. The model is good enough. The question is whether your team has the procedural assets the model needs in order to be useful. If the runbooks exist, the productivity will follow. If they do not, the first investment is to build them, and that investment is one your team should be making regardless of whether an AI assistant ever gets involved.

The compounding case for the technology is not about replacing engineers. It is about making the tedious work cheaper to perform and the interesting work more likely to be checked by a second set of eyes before it ships. Both of those are worth having.

If your organisation is evaluating how AI coding assistants can be embedded in
enterprise data platform delivery, we are happy to share more detail on the runbook
structure, the live-execution architecture, and the governance pattern that surrounds
them.