Cleaning Up the AI Factory Without Throwing Away the Good Stuff

Bottom Line: Building an AI system is surprisingly easy compared with cleaning one up. The hard part is not deleting old code. It is deciding which lessons, safeguards, and proven workflows deserve to survive.

This sentence is the publication verification marker for the AI Factory cleanup article.

When Experimentation Works a Little Too Well

Give an AI agent enough time, Git access, a few APIs, some Python, and a mildly obsessive human operator, and eventually you do not have a project anymore. You have an archaeological site.

There are working tools. Half-working tools. Experiments that became production systems without anyone officially declaring them production systems. Old branches containing one brilliant idea buried under hundreds of outdated files. Documentation describing architectures that stopped being true months ago. New systems that solved problems the old systems were specifically designed to solve.

Then someone asks the terrifyingly simple question: “Can we clean this up?”

That is where things get interesting, because the wrong way to clean an AI factory is to start deleting things. The right way is to figure out what each old thing taught you before you remove it.

That has become one of the most important lessons from building our local Deep Dive AI Factory.

The Clutter Came From Successful Experimentation

Our AI Factory did not start as some grand enterprise architecture. It grew because we kept solving real problems.

We needed a local YouTube production pipeline, so we built one. We needed thumbnails, so we added them. We needed review gates because automatic thumbnails were not always good enough. We added those. We needed better metadata because one project could accidentally inherit information from another. We built stronger metadata rules.

We needed Blogger publishing, a safer dashboard, better B-roll sourcing, visual review, retry decisions, NotebookLM workflows, local model experiments, MCP integrations, reusable Skills, and publishing orchestration. Each addition made sense when it was built.

That is the important part. The clutter did not come from stupidity. It came from successful experimentation.

But successful experimentation creates its own technical debt. Eventually, “What should we build next?” stops being the most important question. A better question appears: “What do we already have?”

GitHub Branches Became Time Capsules

Git branches are useful because they let you experiment safely. They are also very good at preserving alternate universes.

A stale branch might contain an abandoned architecture. Or it might contain the one missing paragraph explaining a decision that still matters.

That is exactly the problem we recently ran into. We had a canonical Factory branch representing the modern system, but an older branch still contained documentation and ideas that had never completely made it across.

The easy solution would have been: The branch is old. Delete it.

Instead, we treated it like digital archaeology. We compared it against the canonical branch. Some files turned out to be generated noise. Some represented older versions of things we had already improved. Some were obsolete. But some were absolutely worth saving.

Among the useful material we recovered were ideas around OpenMontage MCP integration, Google API authentication repair, canonical project identity, process supervision, safety gates, preservation rules, and future Factory architecture.

The branch itself might eventually disappear. Its useful lessons should not.

Canonical Does Not Mean Everything Else Was Wrong

One mistake people make when restructuring AI projects is assuming the new architecture proves the old architecture was bad.

That is rarely true. Our older Factory systems did exactly what prototypes are supposed to do: they exposed requirements.

The YouTube Social Pipeline taught us that review gates matter. Metadata failures taught us that multiple competing sources of truth are dangerous. Visual experiments taught us that a model saying something “looks good” is not deterministic evidence that something is correct. Publishing tools taught us that ready, attempted, uploaded, and verified are different states.

Factory Command Center taught us that operators need to understand what is happening without opening fourteen terminals. Visual-director work taught us that scene-level decisions and whole-video quality decisions are not the same thing.

Those lessons are more valuable than many of the original implementations.

So when we say we want a cleaner canonical Factory, we are not saying, “Forget everything we built before.” We are saying, “Keep the proven rules. Simplify the machinery around them.”

The OpenMontage Example

OpenMontage is a good example of how this thinking changes development.

We had already spent significant effort designing visual production systems: shot selection, B-roll logic, stock footage, generated imagery, graphics, visual QA, retry behavior, continuity, and scene planning.

Then we found OpenMontage, which already contains a substantial media-production engine.

The temptation would be to ignore it because “we already built something,” or replace everything immediately because “this looks better.” Neither approach is very smart.

Our current plan is more conservative: use OpenMontage as a sidecar media engine, connect through MCP, let it expose its native capabilities, test what it already does well, and then add only the Deep Dive AI-specific rules that are actually missing.

That means previous Shot Builder work does not get thrown into the furnace. It becomes a reference implementation and fallback. If OpenMontage fails to reproduce something we know worked before, the old Factory provides evidence.

The old system becomes a benchmark instead of baggage.

One Project Needs One Identity

Another useful idea recovered from the cleanup is the need for a canonical project identity.

This sounds boring. It is not.

AI workflows tend to create state everywhere. One tool writes a JSON file. Another creates its own queue entry. Another stores a project directory. Another creates a publishing manifest. Another agent remembers something in its conversation. Another service has an internal job ID.

Eventually, the same project can be “complete” in one system and “waiting” in another. That is how factories become haunted.

The cleaner direction is to give every production project one canonical identity and manifest. That record should know what the original source was, which SRT is authoritative, which outputs belong to the project, what derivatives exist, what has been approved, what has been published, what proof exists, and what still needs work.

Agents can do work. Media engines can render things. Publishing tools can send things. But none of them should be allowed to silently redefine what the project is.

The Difference Between Cleanup and Destruction

Good cleanup reduces confusion. Bad cleanup erases evidence.

That is why we are using a simple mental classification:

• KEEP — still correct and useful.
• ADAPT — good idea, older implementation.
• PROVEN — solved a real problem and belongs in the requirements.
• REFERENCE — may no longer run, but provides a benchmark.

Then there are the easier categories: DUPLICATE, OBSOLETE, GENERATED NOISE, and OLD ASSUMPTIONS.

That last category matters. An old assumption is not necessarily a mistake. It may simply be a decision that was correct when the Factory had fewer capabilities.

A visual hierarchy designed before OpenMontage existed should not automatically control how OpenMontage is allowed to work. The architecture changed. The lesson can remain.

AI Makes This Problem Bigger

AI can generate software incredibly quickly. That means we are entering a world where creating twenty prototypes may be cheaper than thoroughly planning one.

That is useful, but it creates a new bottleneck: selection.

If AI can create five possible solutions overnight, the valuable skill is no longer just building. It is knowing which solution deserves to survive, which behavior should become permanent, which files are authoritative, which experiments should be retired, which lessons should be documented, and which assumptions are no longer valid.

In other words, the future of AI-assisted software development may involve a lot more gardening.

Grow aggressively. Prune carefully. Keep the strongest plants. Save the seeds.

Our Permanent Factory Rule

One rule emerging from this cleanup is worth keeping:

Retrieve → inspect → reuse → adapt → test → break → repair → verify.

Do not rebuild a generic capability just because we can. First check whether a mature tool already does it. Inspect the tool. Use as much as possible. Adapt only what is necessary. Then deliberately test where it breaks.

That approach is slower than immediately asking an AI agent to generate thousands of lines of new code. It is also much faster than maintaining seventeen overlapping systems six months later.

What the Factory Is Becoming

The goal is not a bigger AI Factory. It is a clearer one.

We want the specialized parts that matter to Deep Dive AI: canonical project identity, validated SRT, publishing approval, visual quality review, brand rules, and proof of completion.

And we want mature external systems to handle generic infrastructure whenever possible.

That is why systems like Hermes and OpenMontage are interesting. Not because we need more tools, but because they may allow us to own less code while keeping more capability.

That is a very different definition of progress.

The Lesson Hidden in the Junk Pile

The editorial image for this project shows a cluttered factory floor. One conveyor is labeled STALE GITHUB BRANCH. Another is labeled CANONICAL FACTORY. Between them, useful plans are being rescued while obsolete pieces fall into scrap bins.

That is basically where we are.

And the cat sitting on the DO NOT DELETE YET box may actually represent the wisest engineer in the building.

Because the final lesson is simple:

Old code is cheap. Lost reasoning is expensive.

Delete the duplicate files. Retire the dead experiments. Consolidate the architecture.

But before throwing anything away, ask one question:

What did this teach us?

If the answer still matters, save the lesson. That may be the most valuable piece of the entire system.