You ever ship a new feature and then immediately think — "wait, what about all the old stuff?" I do that constantly. Yesterday my AI cleaned up one of those cases for me. 58 already-shipped posts on my EN page were missing a source-link comment that all new posts get automatically. One sentence to my agent, one script, six minutes — done.

The job itself isn't a big deal. But the script my AI wrote is the kind of detail-heavy work that I think is worth showing — because it's exactly what separates an AI agent that actually does work on your behalf from a chatbot that hands you code and walks away.

The Problem: I Shipped a Feature and Forgot About the Old Posts

Quick context — Documentor is my auto-content system, the one that publishes to my EN Facebook and Instagram pages multiple times a day. The content gets researched, written, image-generated, and posted on a schedule, with zero touch from me.

Two weeks ago I added a small feature — every post now gets an auto-comment with a source link right after it goes up. So readers who liked the post can jump straight to the original article, video, or repo.

The label on the comment changes based on the post's category:

  • youtube → "Full video here:"
  • oss → "Repo:"
  • case_study / news / how_to / failure → "Source:"

New posts worked great. Every piece of content shipped after that day had its source comment. But the 58 posts that were already live before the feature existed? Bare. No source link.

I opened the page, scrolled my own feed, and it just looked sloppy — half the posts had a clean comment thread that started with the source, and half didn't. Not consistent.

So I told my AI: "I need a backfill script — go find every old post that doesn't have a source-link comment yet, and add one."

Dry-Run First — Because the FB API Bites Hard

I'm extra careful about anything that hits the Facebook API in bulk. If you fire requests too fast, FB doesn't just rate-limit you — it blocks API access for your whole page for hours or days. I got burned by that exact pattern testing the FB Marketing API once and it was enough to make me paranoid forever.

So I told my AI up front: "Don't fire anything live yet — give me a --dry-run first, I want to see which posts you're targeting and what the comment text will be."

I didn't have to ask twice. My agent built the flag into the script from the start:

  • With --dry-run → print exactly what would post where, but make zero API calls
  • Without it → fire for real and commit to the DB

Dry-run found 58 candidates, spread across every category: 21 news, 8 how-to, 7 case studies, 7 failures, 7 youtube, 6 oss. The numbers passed my gut check — the page has been auto-posting for about a month, multiple times a day, and that's roughly what I'd expect.

I sanity-checked a few of the preview messages too — labels matched the category, the URLs were the real source URLs, the formatting was identical to what new posts were getting. Good. Time to send it.

Three Seconds Per Post — and Why That Number, Specifically

My AI dropped a time.sleep(3) between every single API call. Not just between posts — between every hit to the Graph API.

Each loop iteration fires twice: once to comment on the FB post, once to comment on the IG cross-post. So the script sleeps 3 seconds after the FB call lands, then another 3 after the IG call before moving on. That's roughly 6-7 seconds per post, or about 6 and a half minutes for 58 posts. Long enough to make a coffee, short enough that I didn't need to leave it running overnight.

I asked my AI at one point if we could go faster. The reply: "Not worth it. 6 minutes vs. the cost of getting the page's API blocked for a day or two — bad trade." Correct. That's the kind of judgment call I actually want my agent making on my behalf instead of asking me every time.

The Best Part: FB Succeeds, IG Fails — Don't Crash the Batch

This is the detail I want to call out because it's the one most people would get wrong.

My posts cross-post to FB and IG through the same Graph API token. Most of the time both succeed. But sometimes FB takes the comment fine and IG rejects it — maybe the media ID has aged out, maybe IG's comment policy is stricter that day, maybe the cross-post linkage broke for that specific post. It's a known quirk.

If you write the obvious version of this script — "if anything fails, raise and stop" — then one bad IG response on post #4 leaves 54 untouched posts behind and you have to figure out where to restart.

My AI structured it differently:

  • Fire FB first → if FB fails, count it as a failure for this post and move on to the next post
  • FB succeeds → fire IG
  • IG fails → log a warning but count the post as a success, then commit to the DB with the real fb_comment_id and ig_comment_id = NULL

Result: 58 candidates, 58 successes. FB was clean on every single post. A handful of IGs were soft-failures, recorded as NULL, but the batch never stalled.

This is the same defensive-coding lesson I wrote about when my Documentor pipeline died silently for 3 days — production systems break in partial ways, and your scripts need to keep doing the rest of the job when one limb fails. (Another version of "the pipeline has more layers than you think" — see how my AI injected a per-audience campaign footer and stopped it from leaking through the translation step.)

Record to the DB Immediately — Or Pay for It Later

The last piece that made this script feel "finished" — after each comment lands, my AI INSERTs a row into the blocks table with the fb_comment_id and ig_comment_id right then and there.

Why bother recording? Because the regular daily cron — the one that comments on new posts — also uses that same blocks table to decide what's already been handled. The query is basically "find posts that don't have a comment block yet, and add one."

If the backfill script posted the comments but forgot to write the DB row, then the next morning the daily cron would see those same 58 posts, think they were still missing comments, and post a second source-link comment under each one. Duplicate comments. Bad look.

My AI commits to the DB after every iteration — not in one big batch at the end. So if the script dies mid-run (network blip, FB hiccup, anything), the work that's already done is safely persisted. Re-run the script, it skips everything that was already committed, picks up where it stopped. Idempotent. The script can be re-run a hundred times and the page will look the same.

That's the property you want for any backfill script that touches an external API: rerunnable, no duplicates, no surprises.

Why a Tiny Job Like This Matters for People Running a Business

I'm telling this story not because the feature itself is important — it's a comment, on old posts, on one page. The story is the example.

This is the kind of work that lives in a quiet category I'd call "good to do, if doing it were cheap enough."

Think about my options without an AI agent:

  • Do it myself — open Facebook Business Suite, find each of 58 posts, paste a source link comment, switch to Instagram, find the corresponding post, paste the comment again. 1-2 hours, minimum. Mind-numbing.
  • Hire a VA — write the SOP, train someone, QA the output, fix mistakes. For a one-time job, this costs more than just doing it myself.
  • Skip it — accept that half the feed looks one way and half looks the other, and people will form whatever impression they form.

With my AI on my server — I typed one sentence: "write a backfill script for old posts that don't have a source-link comment yet." Ten minutes later I had a script with a --dry-run flag, rate limiting, graceful IG failure, and idempotent DB writes. I previewed it once, ran it for real, and it was done before I finished dinner.

This is what I keep coming back to: an AI agent on your own server lowers the threshold for "is this worth doing." Tiny jobs that you'd normally let slide because they don't justify the work — now they get done. Polish accumulates. Loose ends close themselves.

The Bonus — My AI Kept the Script Around

When the run finished, my agent printed a clean summary: ok=58 fail=0 dry=False, category breakdown matching the dry-run, and a note that it had saved the script to /root/scripts/inc-content-backfill-comments.py for future use.

That's the part I actually loved — it didn't treat this as a throwaway. The next time I add a new comment category, or extend the auto-comment logic to a new format, this script becomes a starting point instead of starting from scratch. The tool stays in the toolkit.

If you run any kind of content system, e-commerce store, or SaaS product, you've got cases just like this — features you shipped that didn't get applied to old data, polish that's worth doing but not worth blocking out an afternoon for. Having your own AI agent on your own server is what makes those cases trivially fixable. That's exactly what Newton is — a private server with an AI agent already wired up, ready to write your backfill scripts, your dry-runs, your idempotent DB writes, and everything else, without you writing a single line of code. See how it works →

— Pond