I Hired an AI to Help Me Build the AI That Helps Me Finish What the First AI Started

Bottom Line: I am experimenting with a simple development workflow: use the most capable AI for the hard engineering, and use a local AI running on my own computer for the repetitive work.

There is a point in every automation project where you realize something slightly ridiculous has happened. You started using artificial intelligence because you wanted to save time. Then you built an automation to save more time. Then that automation needed maintenance. So you brought in another AI to help maintain the first automation.

And suddenly you are sitting at your desk thinking: I hired an AI to help me build the AI that helps me finish what the first AI started.

Welcome to Project Attila.

What Project Attila Is

Attila is deliberately small. It is not an AI writer, not a giant social-media dashboard, and not another all-in-one marketing platform.

The idea is straightforward: bring finished content, publish it to a hosted blog, verify that it actually went live, and prepare the Facebook sharing package.

The article itself might come from ChatGPT, Claude, Gemini, NotebookLM, Qwen, Microsoft Word, Google Docs, or something a person wrote completely on their own. Attila does not care where the finished content came from. Its job begins when the article is ready to publish.

The Rule: No Silent Failure

Anyone who has spent time automating online publishing eventually learns an annoying lesson: a workflow saying “success” does not necessarily mean the job actually succeeded.

The API might return an error. The image might disappear. The post could go live with broken formatting. The internet connection might die halfway through. A blind retry could even create a duplicate post.

That is why Attila has an internal standard: No silent failure.

If something goes wrong, the system should know something went wrong. It should preserve the work, avoid duplicates, retry only when retrying is safe, and explain the problem in normal language when a human needs to step in.

Blogger, WordPress, and the Platform Shootout

Attila began as a Blogger-first project. Blogger still has real advantages: it is free, Google hosts it, and our existing AI Factory already contains working Blogger automation.

But research also made WordPress.com interesting. Hosted WordPress offers a large ecosystem and modern publishing and media APIs. So instead of forcing one platform to win, the smarter test is simple: publish the same article, with the same image and the same failure tests, and see which platform behaves better.

The user should barely notice which adapter is doing the work underneath.

Why Facebook Stays Human-in-the-Loop

Attila will not automatically publish to Facebook. That sounds less impressive, but it removes a mountain of technical baggage: authentication, permissions, token maintenance, app approvals, and API changes.

Instead, Attila prepares the Facebook package after the blog post is verified. That package includes the post text, image, a copy button, the verified article URL for the first comment, and an Open Facebook button.

A short manual step can be better than an expensive automated dependency.

Free First

The current Attila pricing idea is equally small: three successfully verified publishes per month for free, and a Pro tier at $9.99 per year.

Failed attempts do not count. Reliability is not a premium feature. Free users should still receive safe publishing, verification, recovery, and duplicate protection. Pro simply buys more usage and convenience.

Then We Built the Local AI Worker

Building Attila still involves plenty of work, and not all of it deserves an expensive cloud model. There are files to inspect, tests to run, documentation to update, logs to review, and small repairs to make.

That led to another idea: connect Qwen Code to Ollama and create a local development worker.

The intended division of labor is simple. Codex handles architecture, difficult bugs, major reviews, and the hard engineering. Qwen handles repository inspection, routine tests, documentation, smaller repairs, and repetitive daily tasks.

Both work against the same repository and the same project state.

Giving an AI a Job Instead of a Prompt

Most AI use still looks like this: ask the AI to do one thing, get the answer, and end the conversation.

For Attila, I want something closer to a worker walking into the shop every morning. The project keeps durable files that explain what Attila is, what state it is in, and what work remains.

That means the AI can read the state, choose the next unfinished job, do the work, run the tests, update the checkpoint, and continue the next day.

This deterministic sentence is the publication verification marker for the Project Attila workflow test.

The Robot Does Not Get the Launch Key

The AI can build, test, repair, and eventually determine that the release gates appear to pass. But public release remains manual.

The project can reach BUILD COMPLETE, TESTS PASS, SECURITY PASS, INSTALLER PASS, BETA PASS, and RELEASE READY while GO LIVE remains NO.

The robot may build the battleship. The robot does not get the launch key.

The First Local Model Immediately Taught Us Something

Our first local Qwen test also demonstrated why verification matters. The model could chat normally, but when asked to inspect the project files through Qwen Code, it behaved like a chatbot instead of reliably using the coding tools.

That was not a reason to pretend the system worked. It was a test result. The model was not yet the right worker for that job, so the next step became testing a coding-focused local model.

The Goal Is Not More Automation

The deeper lesson from Attila is that the goal is not to automate everything. The goal is to automate the right things.

Automatic Facebook publishing sounded clever until the maintenance burden became obvious, so we removed it. A giant cloud architecture sounded powerful until local storage proved simpler, so we kept the user’s content local. Building another AI writer sounded natural until we remembered everyone already has AI writers, so Attila does not need one.

Every unnecessary piece we remove gets Attila closer to what it was supposed to be: a small tool that works.

The Cat Is Management

The editorial cartoon for this project probably explains the organization better than any architecture diagram. Tiny AI helpers are sorting code, testing posts, and preparing the publishing workflow while a Russian Blue cat sits on the master plan like the CEO.

That may be the most accurate org chart we have produced.

Where Project Attila Goes Next

The next work is deliberately unglamorous: get the local coding worker operating reliably, inspect what already exists in the Factory before creating anything new, and test Blogger against WordPress.com under the same conditions.

No loyalty contest. No technology religion. The platform that proves more reliable for this tiny publishing job wins the first adapter slot.

Final Thought

Artificial intelligence gets attention for the spectacular things it can create: images, music, videos, applications, and entire websites.

But one of the most useful changes may be much quieter: AI doing the work humans never wanted to spend their time doing in the first place.

Checking. Testing. Sorting. Retrying. Documenting. Maintaining.

And eventually handing the human something that simply says: Everything is ready. Flip the switch when you are ready.

That is what I want from Project Attila: not an AI that replaces the person, but an AI that gets the repetitive work out of the person’s way.