Keep the Shell, Retire the Logic

The thing I kept was not the thing I trusted

I had four older blog-automation repos sitting around. They were built over the past couple of years, each optimized for a different job. One was about volume and click volume. Another cared more about keeping the branding intact.

The tempting move was obvious: pick the repo that looked closest and start changing prompts until the new thing worked.

That would have been the wrong decision. I needed the reusable shell, not the old product instinct inside it.

I did reuse parts of those systems, but I did not trust the old logic just because the code still ran. This time the job was different. I was not trying to build an autonomous loop, a system that keeps running steps on its own, executing and executing until it flushes out articles from day one. I was trying to create a helper, a system that arranges and reviews my own thoughts instead of manufacturing articles on its own.

That distinction changed the whole migration.

I had to rethink it and rebuild it because raw SEO volume was not the product instinct anymore. Trust in the author's own thinking was. The old repos were not useless. They just came from another product instinct. If I copied them wholesale, I would also copy the thing they were trying to maximize.

Working code can still be wrong

The first thing I had to admit was that old automation was built to solve a different problem at a different time.

Back then, a lot of the system was SEO-first. The table-of-contents work and prompt framing made sense for a product that framed posts around technology trends and search demand. It was very relevant and useful for that product.

But the clearest thing to retire was also sitting there. Our biggest problem this time was not producing more SEO-shaped drafts. The problem was that we were trying to build a different product.

The old machinery was a volume play. It was derived to flush out volumes of articles on a daily basis, with human review as a small step. For that world, speed was part of the point. More articles meant the machine was doing its job.

In the new system, that same center of gravity would make the product worse. If the workflow starts by assuming the goal is daily output, it will keep pulling every decision toward daily output. A better prompt or newer model would not change that bias.

That is the part builders can miss. When I copy the automation wholesale, I am not just saving time. I am preserving the old answer: what are we optimizing for?

Throwing everything away is also lazy

Those repos had real work inside them. Some decisions had already been paid for. I wanted to pick the good things from those repos, then start working from there. The mistake would have been treating selective reuse as less clean than a rewrite.

The visual-generation approach was worth keeping. I liked how the old system added visuals. They were more branded then, but the base idea worked because the visuals helped carry the article idea.

Topic scouting, the old keyword-and-idea discovery step, was in the same category. We do not use it in the same way now, but that logic had created benefits in the past. I kept the scouting shape, not the SEO-first reason for using it.

The arrangement structure for articles and blogs also survived in some form. Not the whole editorial brain, but the skeleton of how a piece can be shaped.

For me, shell means the reusable parts around the workflow. Logic means the old judgment about what mattered.

The reusable shell can carry work forward if it is made subordinate to the new job. But if the logic still says volume, then the new product is already compromised.

The before-and-after diagram in my head is not old repo versus new repo. It is old SEO-volume path versus a human-centered ghostwriter workflow, where the system starts from my raw thoughts and keeps me as the source while agents review the draft. The same pipes can sit inside a different workflow.

flowchart TD
  subgraph Old[Old SEO-volume path]
    A[SEO-first machinery] --> B[Technology trends and search demand]
    B --> C[Daily article volume]
    C --> D[Small human review step]
  end
  subgraph New[New human-centered ghostwriter workflow]
    E[Human author's raw thoughts] --> F[AI system arranges them]
    F --> G[Personal council of agents reviews]
    G --> H[Readability and quality]
  end

A helper, not a content mill

In the old system, the article was something the automation pushed forward, and the human review was a small step. In the new one, the human is the source. The system helps arrange what the person is trying to say.

The machinery is more sophisticated now, but I do not mean sophisticated in the sense of more autonomous. I mean there is a personal council of agents, separate AI reviewers with specific editorial jobs, that can review the work with the user. That council can catch readability problems and quality issues I would miss on my own.

The line I keep coming back to is this: these are my thoughts, arranged by an AI system. The system did not invent the reason for saying them.

This is also why the old SEO-first table-of-contents logic could not stay at the center. A table of contents can be useful, but if the system is still trying to manufacture the article from an SEO frame, it starts in the wrong place. The new product has to start from the author's experience.

That is a practical product decision, not a philosophical one. I trust the output because I can recognize the source of the thought.

The real migration is from output to trust

When I look at old automation now, I ask what it was originally trying to maximize.

That question is more useful than repo archaeology. The code may be clean, and the prompts may still produce something. But if the hidden goal is no longer my goal, copying it is a quiet way to make the new product worse.

Every old automation system has a ghost goal inside it. Before I reuse one, I want to know whose goal it is.