
Our blog cover images were a mishmash. Years of varying styles and quality, no through-line, nothing that read as one brand. It bugged me for months. Filing a design ticket felt like a three-week detour, so one afternoon this week I did it myself.
Eighty-one posts, two years of the blog. New cover on every one. Done before dinner.
Three tools carried it: Claude Code to run the pipeline, the Contentful MCP to hold the posts and take the new covers back, and Ideogram to generate the art. Here is how the afternoon actually went.
The biggest unlock wasn't a tool. Our engineering team told me: just push your work to production. For web deploys, don't wait for human review. If the AI does the code review and says it's good, ship it and move on.

One from the batch: the new cover on Top 10 push notification providers.
Claude Code built the pipeline and ran it as a fleet: Opus 4.8 orchestrating, Sonnet 5 doing the work, one agent per post, all in parallel. I wrote no code. Nobody does anymore.
The framework was mine: six angles per post. Four depict the actual content:
The other two are abstract fallbacks, for when the literal ones miss. Each worker did the same job: read its post, summarize it, write one concept per angle, render all six through Ideogram.
Then it built me a small local picker. Six options per post, side by side with the current cover, click to choose. When one was close but not right, I edited its prompt in the picker. It re-rendered that one image and swapped it in place. No reload. Once I picked the winners, it optimized each one and pushed it back to Contentful.

The new cover on Why AI is so good at translation.
The Contentful MCP moved the content in and out. Our posts are structured entries, not pages to scrape.
Going in: Claude pulled each post through the MCP and read it, so it knew what the article was about. Coming out: once I picked a cover, Claude uploaded it, set the headerImage, and republished. Same MCP, both directions.
No dashboard. No clicking through 81 entries by hand. The old images stayed in the library, so nothing broke. That is the real value: structured content I can drive from code, not a UI I have to sit in.

The new cover on I built an AI board member in Cursor.
Two choices did the heavy lifting.
First, the style. Instead of describing a house look in all 81 prompts and watching it drift, I ran every one through a single Ideogram style model, a minimal "poster" look. The style came for free, and every cover matched the next.
Second, the prompts. They stayed short, one line of concept per angle. Ideogram's magic-prompt expanded each one into the finished art direction. I owned the idea, the model owned the styling.
The concepts came from real summaries, so the covers were about the article, not stock art. The two abstract angles were a safety net, a clean fallback when a literal take missed. And renders came back in seconds. That is the only reason iterating across 500 of them was possible.

The new cover on Build with AI: let your agent handle notifications end to end.
The gap between "our blog should look better" and "our blog looks better" used to be a couple headcount coordinating. Three tools closed it to an afternoon. This is the same reason we ship a Courier MCP: when the plumbing gets out of the way, one person can do a lot, fast.
But tools were only half of it. Because I could push straight to prod, I owned the problem and the outcome end to end.

Test Courier emails end to end with your AI agent
Give your coding agent an AgentMail inbox, and it can test your Courier emails the way a user would: send the change, check what arrives, review how it renders, and fix what it finds before the change reaches Production.

Let your agent check every email before it ships
Courier Device Preview gives your coding agent real screenshots from Outlook, Gmail, and Apple Mail. Here's the prompt and workflow to have it check every email, fix the draft, and check again before you publish.

Courier vs Customer.io: 2026 messaging platform comparison
Courier and Customer.io both send across email, push, SMS, and in-app, but they are not priced or built the same way. Courier bills by the send, puts journeys, experiments, broadcasts, an in-app inbox, preferences, and 50+ delivery providers on one platform, and exposes all of it through an API, a CLI, and an MCP server. Customer.io bills by the number of profiles in your database and fits a marketing team that needs deep behavioral segmentation. This comparison covers pricing, journeys, channels, in-app messaging, localization, and preferences, with every competitor figure linked to Customer.io's own pages.