Right-altitude automation

There’s a discipline I keep watching people get wrong, and I almost got it wrong myself last week while parking a small piece of work on my blog.

The piece of work was image sourcing. The blog needs hero images for essays. There’s a service called Unsplash with a public API. The lazy version of the build was obvious. Wire the Unsplash API into the site, pull a topic-matched image at page-load, ship. The site looks alive, the images stay fresh, nothing has to be picked by hand.

I was about to file that as a build candidate, and then I stopped, because something about the shape of it felt off. Not the kind of off you can name immediately. The kind that just sits there as a small wrongness while you keep thinking.

I walked away from it. Came back later. The wrongness was still there. So I tried to name what was bothering me, and that’s the move I want to write down, because the answer turned out to be portable past the specific case.

i.The surface temptation to automate everything

Here’s the temptation. You hold a content discipline. You’ve spent months locking down voice, register, no-go phrases, punctuation tiers. The discipline has a price. Every post takes longer because nothing ships unedited. You feel the price.

When automation appears that looks like it would relieve some of that price, the gravitational pull is to take it. The voice work was the hard part. The image was always the easy part. So why wouldn’t you let a machine source the image, the same way you’d let a machine spell-check the prose?

The problem is that the spell-checker runs at a different layer than the prose. The spell-checker is editorial tooling. It runs at authoring time. I see its suggestions, I accept or reject, the post goes out with my hand on every word.

A runtime image API is something else. It runs at page-request time. Some reader hits my essay six months after I published it, and a third-party service hands my page an image I’ve never seen. The page on the reader’s screen is no longer the page I shipped. It’s the page my discipline shipped, plus whatever Unsplash thought matched the topic that minute.

That’s the thing I almost walked past. The two automations look the same on the surface, because they’re both automation involving the same API. They are not the same. They are operating at different altitudes, and the altitude is what matters.

ii.The runtime-API problem

Let me name the runtime version cleanly so I don’t lose it later.

If my site calls a third-party API at the moment a reader hits the page, my discipline ends at the moment I publish. After that, the third party is co-publishing. Every reader sees a page assembled in part by a system I don’t control, can’t review, can’t preview, can’t roll back. The image that loads on Tuesday isn’t the image that loads on Wednesday. The image that loads in Berlin isn’t the image that loads in Atlanta. If the third-party rotates inventory, my page rotates with it.

The deeper problem isn’t unpredictability. The deeper problem is that the brand voice I’ve spent months disciplining is now coexisting with content I haven’t held to the same standard. The prose passed through five rules and a thesis-check. The image passed through a search query. They aren’t editorial equals. And the reader can’t tell which part I picked and which part a service decided.

I have a content pipeline SPEC that quietly already settled this for me. No runtime third-party API. The whole site renders statically. Every byte the reader sees is a byte I published. The discipline holds through the read, not just through the draft.

I’d been treating that rule as a deployment constraint. What I realized walking around the Unsplash question is that it’s actually a brand constraint dressed as a deployment constraint. The reason no runtime third-party API isn’t for performance. It’s because the discipline doesn’t survive the handoff to anyone else’s runtime.

That’s the rule. I almost broke it without seeing it, because the automation looked like it was operating on the same surface as the spell-checker.

iii.The build-time carve-out

Now the carve-out, because the rule isn’t no-automation.

There’s a version of Unsplash-API use that’s completely on-brand. It’s the editorial tooling version. The use case looks like this. I’m about to publish an essay. I want an image to go with it. I run a script at authoring time that hits the Unsplash API, pulls a dozen candidate images that match the topic, drops them into a folder on my machine. I look through the candidates. I pick one. The picked one gets copied into the site repo, given a sensible filename, committed alongside the prose. The site builds. The deployed page ships with that one image, baked in.

The reader’s page doesn’t talk to Unsplash. The reader’s page has a file in it that came from Unsplash six months ago. Past tense.

The automation worked. It did the boring part. It pulled twelve candidates faster than I would have searched for them. But the automation never crossed the line into authorship. I picked the image. My eye was the editor. The discipline survived because the discipline was applied between the API and the publish, not after.

This is editorial tooling. Same shape as the spell-checker. Same shape as a thesaurus, a draft preview, a grammar pass. Tools that propose, the human disposes, the publish reflects the human’s hand.

The framing I landed on for myself is right-altitude automation. Not no-automation. Not all-automation. Automation that operates at the depth where the human still owns the gate. Authoring-time API is at the right altitude. Page-request-time API is not.

iv.Why this distinction is portable

I’m writing this down because I don’t think it’s specific to image sourcing or to blogs.

Anyone building with AI is going to hit the same fork over and over. There will be a hundred places in your build where an API call could save you time. Some of those places are inside the editor, where the human still sees and decides. Some of those places are inside the running product, where the API call happens between you and the end user with no human review in the middle.

The two feel identical when you’re picking which API to wire up. They are not identical. The first preserves your discipline because you stay in the loop. The second hands part of your product to a vendor and asks the vendor to hold your standards, which the vendor never agreed to do.

This is going to come up more, not less, as AI-driven services proliferate. Image services. Summarization services. Recommendation services. Voice services. Any of them, wired at the right altitude, are leverage. Any of them, wired at the wrong altitude, are a discipline hole.

The general rule, as best as I can phrase it after the walk, is something like this. Automation that runs before the human’s editorial gate is leverage. Automation that runs after is delegation, and delegation needs a level of vendor trust your voice discipline almost never has.

The boundary is the gate. Where the gate sits is the discipline.

v.How to apply it elsewhere

The practical version, the one I can use as a check next time I’m staring at an API and trying to decide whether to wire it up, is three questions.

First. When does this call run? Build-time or runtime. Authoring-time or read-time. Inside the editor or inside the deployed product.

Second. Who sees the result before the end user does? If the answer is “I do, and I can reject it,” the automation is editorial tooling. If the answer is “no one does, because it goes straight to the reader,” the automation is co-publishing.

Third. If the third-party rotates, changes, breaks, or starts behaving differently next year, does my published work change without me touching it? If yes, the automation is wired too deep. If no, the automation is at the right altitude.

Three questions, one boundary. The boundary keeps the brand from being co-authored by services that never signed up for the standards.

I almost walked past this last week because the temptation was framed as efficiency. Pull images automatically. Save time. The site looks alive. All of that was true. But what was also true was that the page would have stopped being mine the moment the API call moved from build-time to runtime.

The discipline isn’t no-automation. The discipline is knowing where the gate sits and refusing to wire anything below it.

I parked the runtime version. The build-time version is still on the table. That’s the carve-out. That’s the rule.

Drafted with Bishop, my AI partner.
Words picked, edited, and approved by me.