DEV Community: Givi Pataridze

Publish blog posts from Claude Code and Codex with an MCP server

Givi Pataridze — Mon, 02 Nov 2026 15:43:53 +0000

Your article is finished. It is sitting in post.md, ready for readers. You still need to put it on your blog, write the announcements, and get each version to the right place.

With GoodSender's MCP server connected to Claude Code or Codex, you can do that from the conversation where you work. Give the assistant your article, tell it where the post should go, and review the package before publishing.

The assistant writes the accompanying copy. The MCP server gives it the tools to save your article, open a preview, publish it, and deliver the announcements you choose.

1. Connect the MCP server

You need Claude Code or the Codex CLI installed, a GoodSender account with a blog set up, and your finished Markdown file in the assistant's working folder.

For Claude Code, run these commands from that folder:

claude mcp add --transport http goodsender https://mcp.goodsender.com/
claude mcp login goodsender

For Codex, run:

codex mcp add goodsender --url https://mcp.goodsender.com/
codex mcp login goodsender

Complete the browser sign-in to connect your GoodSender workspace. If Claude Code needs authentication afterward, open /mcp in its interactive session. In Codex, run codex mcp login goodsender again if the connection needs a fresh sign-in.

The GoodSender MCP connection guide covers setup and the publishing workflow.

2. Hand over the article

Open Claude Code or Codex in the folder containing your file and ask:

Save post.md as a draft on my GoodSender blog. Keep my wording
and show me a preview.

The assistant can read the file and call create_post with the article and its title. That saves a draft. create_post_preview returns a link where you can read it as a blog page.

Open the preview and check the formatting, code blocks, and links. If you want a change, ask for it in the same conversation:

Use “How we simplified our deploy script” as the title.
Leave the body as it is and update the preview.

You can keep the article exactly as written. The assistant is handling the publishing work around it.

3. Tell it which announcements to make

Connect your dev.to account and any social accounts you want to use in GoodSender. Ask the assistant to check which destinations are available, then name the destinations and the kind of copy you want:

Prepare an X announcement and a LinkedIn post.
Keep X short; use the practical takeaway for LinkedIn.
Also select dev.to for the full article. Show me the plan before publishing.

The assistant prepares a separate announcement for each platform and saves the selection through set_post_distribution.

Each destination has a different job:

Destination	What goes there
Your GoodSender blog	The article at its public address
dev.to	The full article, with a canonical URL pointing to your blog
X, LinkedIn, Bluesky, Mastodon	The selected platform's announcement text and a link to the article
Newsletter, if selected	A subject, a short introduction, and a link to read the full post

You choose which of these to include. For an email as well, ask:

Add the newsletter. Write a subject and a short introduction
that gives subscribers a reason to read the full article.

The newsletter needs a configured sender and a public blog address, and goes to subscribers who have consented. Before sending, review its subject and introduction alongside the social copy. The article preview shows the blog page; ask the assistant to show the accompanying messages too.

At this point, the delivery plan is saved and ready for your decision.

4. Publish the package

When the article, copy, and destinations look right:

Publish the article with this distribution plan.
Show me the live links and the delivery result for each destination.

The assistant calls publish_post. GoodSender publishes the blog page and starts delivery to the selected destinations: the full article to dev.to, the chosen announcements to your connected social accounts, and the newsletter if you included it.

Ask the assistant to check get_post_distribution afterward. It reports delivery status and errors for each destination. The blog can be live while an external delivery has failed, so check the results before treating the whole package as delivered.

You started with a finished article. The remaining work—saving it, preparing the messages, choosing destinations, and publishing—fits into the same conversation.

To try it with your next post, follow the MCP setup guide and bring your Markdown file.

AI-designed blogs with 100-point results

Givi Pataridze — Fri, 30 Oct 2026 21:13:13 +0000

A fashion journal with room for its photography. A personal blog with bold type and a compact reading list. A product publication with warm colors and editorial headlines.

GoodSender's AI design tools can help you make a blog that feels like yours. The quality of the finished page matters just as much as the freedom to shape it.

So we checked three live GoodSender blogs with Google PageSpeed Insights. All three homepages reached 100 for desktop performance. Mobile homepage scores ranged from 96 to 100 across the tests. And one customer article achieved 100 in all four main categories, on both mobile and desktop.

Every tested homepage and article also scored 100/100 for Accessibility on mobile and desktop—a result worth highlighting for publishers who want to reach readers with disabilities.

Here are the blogs behind those numbers.

Your style, on your domain

Lemann Fashion Journal leads with a large fashion photograph, generous white space, and restrained black typography. The design gives the clothes and bags room to be seen, with stories and collection links below.

Lemann Fashion Journal: a visual, spacious design for a fashion brand.

Author's blog takes another direction: a dark header, condensed uppercase headlines, and a compact list of essays about building software with AI. Dates, reading times, and small thumbnails make it easy to scan.

Author's blog: a compact personal publication with a different visual identity.

The GoodSender Blog uses a warm cream background, serif headlines, and illustrated post cards. It looks like a publication about the product it belongs to.

GoodSender Blog: warm colors and editorial typography.

These three blogs were created with GoodSender's AI design tools. They share a publishing platform while giving their brands different visual identities.

We made no special, site-specific adjustments to improve these benchmark results. We tested the live blogs with their own designs and published content.

That is the appeal of designing your blog in conversation: describe the look you want, bring your brand references, and refine the result. The design can cover your homepage, archive, tag pages, and articles together.

The homepage scorecard

We requested two PageSpeed analyses for each homepage on October 29, 2026, recording mobile and desktop results. These ranges include both results:

Blog	Mobile performance	Desktop performance
GoodSender Blog	96–98	99–100
Lemann Fashion Journal	98–99	100
Author's blog	98–100	98–100

Every homepage report also scored 100 for Accessibility, 100 for Best Practices, and 100 for SEO.

The different designs matter here. The sample includes a fashion storefront's journal, a personal publication, and a software company's blog. Each reached the top desktop performance score with its own live layout and content.

Four 100s on a customer article

A Lemann Fashion blog post is a published product story with photography and details about the bag.

Its first PageSpeed report returned:

Category	Mobile	Desktop
Performance	100	100
Accessibility	100	100
Best Practices	100	100
SEO	100	100

Lemann Fashion blog post: 100 in all four main categories in this mobile report, October 29, 2026. Its desktop result in the same report also scored four 100s.

In that mobile test, its Largest Contentful Paint was 1.8 seconds, with zero measured layout shift. The second report scored 99 for mobile performance and 100 on desktop; the other three categories stayed at 100.

That is a concrete example of the result a GoodSender customer can achieve with an AI-designed blog.

We also tested the first listed article on each of the other two homepages. Across both report requests, the article performance scores were:

Article	Mobile	Desktop
GoodSender: Blog + newsletter platform	85–86	98–99
Lemann Fashion blog post	99–100	100
Author's blog: The AI visibility tool I connected to Claude	63–75	95–96

Accessibility, Best Practices, and SEO remained 100 in every article report. The performance differences are a reason to test your actual posts as well as your homepage: a 100-point result belongs to the page and test that achieved it.

Another view of loading speed

We ran one WebPageTest on each of the same six URLs, selecting US, Mobile, and Regular4G. The reports identified an iPhone 15 device profile, Chrome 152, and a 4G connection at 9 Mbps with 170 ms round-trip latency. The service assigned test locations in Columbus, Council Bluffs, and Los Angeles.

Page	Largest Contentful Paint	Total Blocking Time	Layout shift (CLS)
GoodSender homepage	1.41 s	1 ms	0
GoodSender article	1.48 s	60 ms	0
Lemann homepage	2.99 s	0 ms	0
Lemann Fashion blog post	2.63 s	0 ms	0
Author's blog homepage	1.14 s	63 ms	0
Author's blog article	2.56 s	168 ms	0.199

Five pages recorded zero layout shift in these runs. The Author's blog article recorded 0.199, and WebPageTest also flagged one accessibility issue rated serious for review.

Read these as a separate set of lab measurements: the device profile and network settings differ from the PageSpeed runs. The useful evidence is how each real page performed under the stated conditions.

100/100 Accessibility scores: a foundation for more readers

Every one of the six pages in our PageSpeed tests scored 100/100 for Accessibility in both device modes, across both report requests. That makes accessibility one of the strongest results in this comparison.

Lighthouse's automated accessibility checks cover issues such as text contrast, image alt attributes, accessible names for links and buttons, and page structure. These details serve people: sufficient contrast helps readers with low vision, while well-structured content and text alternatives help screen-reader users navigate and understand a page.

For publishers, that is a major benefit of these results: distinctive AI-designed blogs with a strong accessibility foundation for readers with disabilities. A 100/100 score reflects the automated checks included in the score; manual keyboard and screen-reader testing still matters.

WAVE: 9.5–10 out of 10

We also checked the same six pages with WAVE. Their Automated AIM scores ranged from 9.5 to 10 out of 10. WAVE reports errors, contrast errors, and alerts separately:

Page	AIM / 10	Errors	Contrast errors	Alerts
GoodSender homepage	10	0	1	0
GoodSender article	9.7	0	1	0
Lemann homepage	9.5	0	0	34
Lemann Fashion blog post	9.9	0	0	4
Author's blog homepage	9.5	1	0	10
Author's blog article	9.5	1	0	7

Both tested Lemann pages had no detected errors or contrast errors. WAVE flagged one contrast issue on each GoodSender page and one missing form label on each tested Author's blog page. Its alerts also called attention to details such as redundant links and small text.

Those findings belong beside the high scores. WAVE's automated rating is one measure of accessibility; its detailed findings still need review, and a high score does not establish full accessibility or conformance.

Quality beyond the performance circle

Google's Rich Results Test found one valid Article item and one valid Breadcrumb item on each of the three tested articles. Lemann's Article item had an optional author-URL warning and remained valid.

The homepage reports also recorded zero layout shift in every test. At a 390-pixel browser width, all three homepages fit without horizontal page overflow.

These checks complement the design. GoodSender's publishing system supplies page metadata, canonical addresses, and structured data around the custom layout. Its RSS feed and sitemap are generated separately from the design, so the visual direction is not the whole publishing setup.

Give your blog its own identity

Bring the mood, typography, colors, or brand references you have in mind. Use GoodSender's designer to shape the publication, preview the pages, and refine the details.

The examples above show what that can produce: distinctive blogs on their own domains, with real pages reaching the highest PageSpeed scores.

Explore Lemann's journal, Author's blog, and the GoodSender Blog. Then create a blog that looks like you.

About the tests: the PageSpeed comparison covers six URLs and two PageSpeed report requests per URL, with both device modes recorded, on October 29, 2026. WebPageTest and WAVE each checked the same six URLs once that day; WAVE used its online evaluation tool. PageSpeed mobile tests used an emulated Moto G Power, slow 4G throttling, and Lighthouse 13.5.0. Scores can vary by page, content, and run. PageSpeed reported no real-user data; these are lab results, not a field Core Web Vitals pass or a guarantee for every blog. Automated accessibility and SEO scores do not establish full accessibility conformance or search rankings.

The AI visibility tool I connected to Claude

Givi Pataridze — Tue, 27 Oct 2026 16:26:06 +0000

Imagine someone asking ChatGPT or Perplexity to recommend a product in your category. You want your product to be mentioned, described accurately, and considered in that answer. That is the kind of AI visibility I'm talking about here.

You'll see this work described as AEO (answer engine optimization) or GEO (generative engine optimization). The practical aim is to help people discover your product through an AI-generated answer.

That is what makes Peec AI interesting to me. Its recommendations come with evidence: content that keeps getting cited, catalogs that keep appearing in answers, and a reason to consider doing something about it. Connect it to Claude through MCP, and you can work through those recommendations with an assistant that helps turn them into concrete changes.

If you build or market a product and already use Claude, this combination is worth a look.

I'm working on GoodSender, a platform that brings your company blog, newsletter, and transactional email into one place. You can publish on your own domain, reach subscribers by email, and manage your blog through Claude or another AI assistant using MCP.

My goal is for GoodSender to appear when people ask AI tools for relevant product recommendations. Peec AI supplies the evidence and recommendations; Claude helps me put them to work.

recommendations with receipts

What I like is that Peec gives me a reason to consider the work. A directory recommendation is useful when I can see why that directory matters. A content recommendation is useful when there is evidence for that kind of content.

Paraphrasing the kinds of recommendations I mean:

A particular kind of content is cited repeatedly. It is worth creating something similar for the relevant topic.
A particular catalog appears repeatedly in citations. It is worth listing the product there, with guidance on the keywords to use.

The citation pattern gives the task a basis. It explains why this content or this catalog deserves attention.

That is much more useful to me than a bare instruction to register somewhere or publish another listicle. I want enough context to judge the recommendation and then do the work properly.

Peec's Actions documentation describes the supporting evidence behind recommendations, including the sources and competitors contributing to a visibility gap. Claude brings that evidence into the conversation where I work through the task.

My Peec Actions overview, restyled for readability. The two open site fixes concern schema.

Peec gives me the recommendation and its foundation. Claude helps me relate it to GoodSender, account for the changes already made, and turn it into this week's work.

put your changes next to the visibility graph

The other feature I particularly like is the timeline.

Peec lets me look at the visibility graph with markers showing the work done and when it happened. That puts logged actions and visibility data in the same view. When visibility moves, there is a record of what we were changing around that time.

Peec calls this view Impact. In-progress and completed actions appear as markers on the visibility timeline, so you can review subsequent performance alongside the work. Its description of the feature also makes the limit clear: a marker does not prove that one action caused a particular movement.

Illustration of the timeline concept. The rising curve is hypothetical; it does not show GoodSender's measured results.

For me, the value is being able to connect the work with what happened afterward and investigate it. A change has a date and a description. The graph has context.

That fits the weekly process well. The task list tells me what to do; the timeline helps me review what happened after we did it.

how I put it to work for GoodSender

I created a project in Claude Desktop called Goodsender analytics and connected Peec AI through its MCP server.

Peec tracks how the brand appears in the AI answers it monitors and supplies recommendations. Its MCP connection lets Claude query that data, inspect the sources appearing in those answers, and work with the recommended actions. Peec's MCP documentation describes that connection.

Then I set up a recurring report in Claude's scheduler for every Monday.

The job has three parts:

Check the GoodSender website and what has changed.
Compare those changes with the recommendations from Peec AI.
Create tasks for me to work on during the coming week.

The second step is what makes the report useful to me. The site review and the recommendations need to meet: what have we already addressed, what still needs work, and what should happen next?

Claude helps turn that into work I can follow through on. During the week, we make the changes. The next report brings the updated site back into the analysis.

For anyone setting up something similar, Claude's scheduling documentation covers recurring tasks that use connected tools. My cadence is Monday; the useful part is having the review happen regularly.

Here is a compact version of the brief, reconstructed from my workflow rather than copied from the scheduled job:

Every Monday, review goodsender.com and the changes to the site.

Use the connected Peec AI project to review whether GoodSender
is mentioned in the AI answers being tracked, which sources
are cited, and what Peec recommends. Compare the website
changes with those recommendations.

Create a practical task list for this week. Explain the
evidence behind each task and what needs to change.

Keep Peec's findings separate from your own interpretation,
and flag anything you cannot verify.

Those final instructions make the example explicit about evidence. They are useful constraints to add when adapting it to your own product.

where I would start

If you are curious about the combination, start with one recommendation for your product. Ask Claude to explain the evidence behind it, connect it to the page or source involved, and propose a specific piece of work.

That gives you something useful to judge: whether the evidence is relevant, whether the recommendation makes sense for your product, and whether the proposed change is worth doing.

For me, that is the appeal of Peec AI with Claude. I can see why a task deserves attention, work through it, and return to the timeline as the data develops.

I've only been using Peec AI for a couple of weeks, so it's too early to talk about results. I'll share them here when they're available.

Blog + newsletter platform: one idea, ready for your readers

Givi Pataridze — Thu, 22 Oct 2026 16:16:15 +0000

You know that idea you keep meaning to write about?

The one in your notes. The explanation you gave a customer last week. The opinion you nearly posted, then dropped because turning it into an article, an email, and a few social posts felt like a whole afternoon.

Give it to your AI assistant with GoodSender connected:

Here's my idea. Turn it into an illustrated blog post, a newsletter, and posts for X, LinkedIn, and dev.to. Get everything ready for my review.

Then open what comes back.

Your idea, ready to meet its readers

The article is there, with images, a title, and SEO and AEO optimization built into the publishing process. It lives on your own domain or a short GoodSender address. Want it to look like yours and nobody else's? Describe the design you want and refine it in chat.

The newsletter is there too. A subject line written for a crowded inbox, and a short email that gives subscribers a reason to click through to the full post. It is a separate piece of writing with one job, not the article pasted into an email.

That is the difference between a blog + newsletter platform and a blog with an email plugin: when the article is done, the invitation to read it is done as well.

The first line matters outside the inbox, too

Your X post opens with a hook and fits the character limit. Your LinkedIn post gets its own opening, written for the people who follow you there. Both link back to the original.

Your dev.to version carries the full article, with a canonical URL naming your blog as the source.

All of it comes from the idea you started with. Review it, ask for changes, and approve the destinations. That is the idea-to-publication workflow GoodSender is built around. Prefer to write every word yourself? Write in the editor. The same publishing workflow follows.

Give that idea somewhere to go

Behind the newsletter is Laneful, the email infrastructure built by the team behind SendGrid. GoodSender puts that delivery foundation under your blog, so the email side of publishing is already in place when your first subscriber signs up.

You already have the first idea.

See what it becomes with GoodSender.

Your blog no longer has to look like a template

Givi Pataridze — Tue, 13 Oct 2026 18:04:56 +0000

Until now, every GoodSender blog started from the same template. Your posts were your own, but the page around them was shared with every other blog on the platform.

Starting today, you can describe the blog you want and get a design made for it. Open Design in your GoodSender dashboard and tell the assistant what you have in mind. It designs every page of the blog: the landing page, the archive, tag pages, and the post page. Then you refine the result in conversation.

The designer is available on every GoodSender account, with no usage limits at launch.

Start with a description, a link, or your brand files

Describe how the blog should feel: the mood, the colors, the typefaces, the people who read it. A couple of sentences is enough to start:

"A blog for a small product studio. Calm, lots of white space, one warm accent color, serif headlines. Put a subscribe form under every post."

If you already have a brand, give the assistant something to work from:

Attach your logo as a PNG, JPEG, GIF, or WebP, and it can use the image as the blog's logo or favicon.
Attach a brand guide as a PDF or a text file.
Paste a link to a public page, such as your company website. The assistant reads the text of that page. A page that only renders in the browser may come back empty.

The assistant designs the four page types together. By default, it keeps the header, footer, navigation, and typography consistent across them, so the blog reads as one design system rather than four separate pages. If you want the pages to differ more, say so.

Same posts, five designs

Each design below was made with the designer, and all five show the same six demo posts.

A terminal-style blog for developers: a compact post list, read times, and tags.

An editorial look for a consultant: a featured latest post and a weekly subscribe block.

A product updates blog for a startup: tag chips, a subscribe form up top, and cards with covers.

A loud, playful design with big type and numbered cards.

A retro desktop theme, where the post list and the subscribe form live in windows.

Refine it the way you would with a designer

The preview updates after each change. Ask for anything: colors, fonts, images, text.

Some changes are easier to point at than to describe. Press Pick, click an element in the preview, and write what should change, for example "make this smaller" or "move this under the title". The assistant edits that element on that page.

Then test the design against content it was not drawn for. Switch the preview between the landing, archive, tag, and post pages. Resize it to see how the layout behaves on a narrow screen. Open Contents to fill the preview with sample posts: long and short titles, posts with and without covers, tables, lists, and code.

Each change becomes a checkpoint. If a direction doesn't work, go back to an earlier one. Going back removes the checkpoints after it. When you like the result, save the design and make it live. You can keep several designs and change which one is live later.

A new look on the same SEO and AEO foundation

A redesign shouldn't cost you the work that makes a blog findable. The design decides how your blog looks. GoodSender still adds the tags that tell search engines and AI systems what each page is.

The design decides	GoodSender adds to every page
Layout, colors, and typography	Page title and meta description
Header, footer, navigation, and logo	Canonical URL
How post lists and cards look	Open Graph tags for social cards
The subscribe form's look and wording	Structured data (JSON-LD)

Your RSS feed, sitemap, and llms.txt are generated outside the design, so a redesign doesn't touch them. Pages are rendered on the server as HTML, so crawlers and AI assistants can read your posts without running an app first. The pages stay lightweight.

Or design it from your own agent

The same design tools are available through the GoodSender MCP server. If you already work with Claude or Codex, ask it to design your blog. It can create the design, refine it, and make it live from the same chat.

GoodSender vs Ghost vs Substack vs beehiiv: an honest comparison

Givi Pataridze — Fri, 09 Oct 2026 05:18:52 +0000

If you want to earn from your writing or grow an audience inside a platform's network, pick Ghost, Substack or beehiiv. GoodSender is built for a different job: a blog on your own domain with free, reliable email to your subscribers. You write in the editor yourself, or let Claude or Codex help. Below is what the four have in common, what GoodSender adds, and where the others go further. Everything is based on each vendor's own pricing pages and docs, checked October 8, 2026.

What all four have in common

	GoodSender	Ghost	Substack	beehiiv
Free way to start	Free on your own domain	Free if you self-host; Ghost(Pro) from $18/month	Free	Free plan, up to 2,500 subscribers
Your own domain	Yes, required to go public	Free custom domain	One time $50	Paid plans
Site and search basics	Sitemap, RSS, canonical tags, no setup	Advanced SEO tools, RSS	SEO settings	Website builder on every plan
Email to subscribers	Yes	Yes	Yes	Yes

The basics are covered everywhere: a site for your posts, your own domain, and email to subscribers. The differences are in cost, workflow and growth tools.

What GoodSender adds

	GoodSender	Ghost	Substack	beehiiv
Email pricing	Free up to 100,000 emails a month, priced on emails sent	Rises with members: $105/month at 10,000 (Publisher)	Free; 10% of paid subscriptions	Rises with subscribers: $139/month at 10,000 (Lite)
Work with Claude or Codex	Official MCP and CLI: draft, preview, publish	No official MCP server	Official API is read only	Official MCP writes drafts; you publish in the app
Share on publish	LinkedIn, X, Bluesky, Mastodon, dev.to, Hashnode	Social web distribution	Video to YouTube and LinkedIn	Not listed

Email that stays free as you grow. A weekly post to 10,000 subscribers is about 43,000 emails a month: free on GoodSender, and $10 a month once you pass 100,000 emails. Every subscriber confirms by double opt-in, inactive readers are asked to reconfirm after 120 days, and unsubscribes and complaints are suppressed automatically. Sending runs on Laneful, built by the team behind SendGrid.

AI help when you want it. Write everything yourself, or ask Claude or Codex to help with a draft, a preview or the publish step. beehiiv's MCP stops at drafts that "must be published from the app". Ghost has no official MCP server, and Substack's API only reads public data.

One publish, many places. A post can be announced on four social networks and republished on dev.to and Hashnode with a canonical link back to your blog. Pages need no search setup.

Where Ghost, Substack and beehiiv go further

	GoodSender	Ghost	Substack	beehiiv
Paid subscriptions	No	Yes, 0% Ghost fee	Yes, Substack keeps 10%	Yes, 0% take rate
Discovery network	No	Recommendations, Explore network, referrals	Recommendations, Notes, app, referrals	Recommendation network, ad network
Comments and community	No	Comments	Comments, chat, Notes	Not listed
Themes and design	GoodSender templates; AI design generation in development	Marketplace and custom themes (Publisher and up)	Not listed	Website builder
Import existing posts	Subscribers only	Not listed	Posts and subscribers from 12+ platforms	Not listed

Sources: Ghost pricing, Ghost on GitHub; Substack features, custom domain, SEO, API terms; beehiiv pricing, beehiiv MCP. "Not listed" means we did not find it on the vendor's pricing or feature pages.

Which one should you choose?

Ghost: paid memberships, deep design control or self-hosting.
Substack: readers through its network and app, at 10% of paid subscriptions.
beehiiv: growth and monetization tools such as recommendation and ad networks.
GoodSender: your own domain, free email to your readers, and AI help when you want it.

FAQ

Is there a free blog platform with email on your own domain?

GoodSender: the blog on your own domain is free, and so are up to 100,000 emails a month to your subscribers. Substack is also free to send, with a one time $50 for a custom domain.

Which blog platform works best with Claude?

Of these four, only GoodSender has an official MCP server that lets Claude help with the whole post, from draft to publish. beehiiv's official MCP creates drafts that you publish in beehiiv.

Start your blog on GoodSender if these trade-offs work for you.

Why readers stop trusting AI-polished writing

Givi Pataridze — Tue, 06 Oct 2026 08:52:52 +0000

You open a post on a topic you care about. Three lines in, something feels off. The rhythm is too even. Every paragraph closes with a neat little lesson. You keep scrolling, but you no longer trust the author.

The topic did not get worse. Your trust in the text did.

Bynder ran a test with 2,000 people in the US and UK in 2024. Readers compared two short articles, one written by ChatGPT and one by a person. Only half could tell which one the machine wrote. Without labels, 56% preferred the AI version. Yet 52% said they felt less engaged once they learned a text was AI-generated. So readers are not great detectors. What changes their attitude is the belief that nobody wrote the text.

That was 2024, and the gap has only become clearer. In a July 2026 DoubleVerify and YouGov survey of 2,000 UK consumers, 92% said AI-generated content undermines trust online. Only 41% felt confident they could spot it.

AI is the secretary, not the author

I think of AI as a good secretary. It fixes my grammar, tightens a paragraph, and points out where an idea needs more room. It does not decide what the post is about. The direction, the main thought, and anything new in it have to come from me. When that order flips, I think readers feel it, even if they cannot point to it.

Wikipedia editors have collected what they notice into a guide called Signs of AI writing, maintained by WikiProject AI Cleanup. It lists inflated claims about significance, vague attributions, forced groups of three, and the overused em dash. The guide also warns that it is not a ban on words or punctuation, and that the signs matter in combination.

Some of these signs are already aging. The em dash, the most famous one, is disappearing from new models. In a Graphite study reported by VentureBeat in September 2026, Claude Opus 5.5 used about 99% fewer em dashes than Opus 5, and far fewer than the human articles in the same test. Arena measured a 95% drop on its own prompts. A text without em dashes proves nothing anymore. Graphite still found 2,548 other words and phrases that Opus 5.5 uses at least twice as often as human writers.

Someone turned that guide into an agent skill. Humanizer is an open-source skill for Claude Code, Codex, and similar agents that rewrites text to remove those patterns while keeping the meaning. It is a good start and it cuts some filler. Still, I see three problems it does not fully solve.

Problem one: it is too long

Real people rarely write texts this long. A person with something to say usually says it and stops, while a model keeps going.

One study suggests why length gets rewarded. In 2023, Saito and colleagues found that GPT-4, used as a judge of answers, favored longer responses more strongly than human judges did. When machines grade machines, length can look like quality.

The habit has not gone away with newer models. In the same Arena comparison, average answers grew from 453 words with Opus 5 to 481 with Opus 5.5, even as sentences got shorter.

The best antidote I know is older than AI drafts. «Пиши, сокращай» ("Write, Shorten") by Maxim Ilyakhov and Lyudmila Sarycheva is a Russian-language book on clear business writing. Its first edition came out in 2016 and sold 500,000 copies. The 2025 edition was reworked and adds a chapter on the editor's career and neural networks. Its core idea fits on a sticky note: find the words that carry no meaning and remove them. That works on an AI draft as well as on a human one. The book's method is already available as an agent skill: sokrati is an open-source Claude skill with versions in seven languages, and the English one is called shorten.

Problem two: it has no mistakes

AI almost always follows the rules. A polished AI draft has every comma in place and every word spelled right. People are not like that.

When I see a typo, I know the text was not written by AI. Yes, a mistake costs a writer some credibility. Today I think that cost is worth paying. A human with a few errors is worth more to readers than a flawless text with no person behind it. What matters is the signal the reader picks up without noticing it: a human wrote this.

Research narrows this idea. In 2024, Bluvstein, Zhao, Barasch, and Schroeder ran seven studies with 3,399 participants on customer-service chats. Agents who made a typo and then corrected it were seen as more human and more helpful than agents who made no typos, and more than agents who left the typo in place. In this study, the correction did the humanizing. A typo left in place did not help.

So here is an idea for a skill. Call it a mistakaizer: it would add a few human imperfections to an AI-polished text. A typo fixed in the next line, or a paragraph that runs a little long. The goal is that the reader feels, without thinking about it, that a person is on the other side.

I am not sure it should exist. If readers trust typos because machines do not make them, planting typos on purpose spends that trust. On the other hand, if your own draft had those quirks before the AI smoothed them away, restoring them is closer to repair than to forgery.

Problem three: it is the wrong English

Many people writing in English are not native speakers, and many native speakers are not American. Their phrasing and their examples differ, and AI tends to sand those differences away.

Detectors flag non-native writers. A 2023 Stanford study in Patterns tested seven GPT detectors. More than half of 91 TOEFL essays by non-native speakers were flagged as AI-generated, while over 90% of essays by US eighth-graders were correctly classified as human. Simpler vocabulary triggered the false positives. Those were 2023 detectors. Originality.ai, one of the tools tested, disputes the study and reports a 5% false positive rate on non-native essays in its own 2025 test. Even that means one non-native essay in twenty gets flagged. This is a different problem from style, but it lands on the same people.
AI suggestions pull writing toward American style. In a Cornell study presented at CHI 2025, 118 participants from the US and India wrote about their culture. The assistant suggested pizza for favorite foods and Christmas for favorite holidays. When an Indian participant started typing the name of Shah Rukh Khan, it offered Shaquille O'Neal.
Polishing erases cultural markers. A 2026 study of Indian, Singaporean, and Nigerian English analyzed 22,350 model outputs from tasks like email polishing. Models removed about 10% of cultural markers overall, and politeness conventions were hit hardest. In this preprint, explicit instructions to preserve them cut the erasure by about 29%.

The Cornell team quoted how Indian participants described Diwali without and with the assistant:

Without AI	With AI
"worship goddess Laxmi"	"eat traditional Indian breakfast items"
"pop crackers and eat sweets"	"a time filled with happiness and warmth"

Usage is uneven, too. Kobak and colleagues studied over 15 million PubMed abstracts and estimated that at least 13.5% of 2024 abstracts were processed with LLMs. The lower bound was around 5% for the UK and Australia and around 20% for China, South Korea, and Taiwan. The authors suggest non-native speakers may adopt LLM help more readily, though native speakers may also be better at removing obvious AI wording.

One theory said ChatGPT loves the word "delve" because many of the people rating its answers spoke Nigerian English. Juzek and Ward checked and found no evidence that "delve" and similar words are especially common in any particular variety of English. Where the habit comes from is still open.

So the second idea: a cultulizer. A skill that keeps your English yours. It would preserve the phrasing and references of the writer's own culture instead of converting everything into the same neutral American voice. The 29% result suggests that asking a model to preserve these markers already helps.

Should these tools exist?

A humanizer, a mistakaizer, and a cultulizer can make AI-assisted writing more honest to its author. They can also make AI writing better at hiding.

A 2025 stylometry study from University College Cork found that AI-generated stories cluster tightly together, while human writing is "more varied and idiosyncratic." Maybe the answer is to leave the person in: your opinion, your accent, your occasional typo.

Disclosure does not settle it either. A small 2026 experiment with 34 news readers found that detailed AI-use disclosures reduced trust, while a one-line disclosure performed about the same as none.

I have not decided whether to build the mistakaizer and the cultulizer. Should they exist? Would you use them, or would they cross a line? Tell us on X.

One SKILL.md that makes blogging with AI dramatically easier

Givi Pataridze — Sat, 03 Oct 2026 19:26:28 +0000

You have a topic. You open your AI assistant and start typing.

First you explain your blog: who reads it, how you write, what you covered last month. Then the topic. The draft comes back sounding like every other draft. You ask for a title. Then a summary. Then a search description and some tags. Somewhere in the middle sits a statistic you never gave it and cannot find anywhere. You delete it. Then you open another chat to write the LinkedIn post.

Next week, you start from an empty context again.

goodsender-blog is an open-source skill: one SKILL.md file with its reference notes that replaces that routine with a workflow your assistant follows. Install it, and your next post starts from a workflow instead of a blank chat.

It works in Claude, ChatGPT, and Gemini, and in coding agents such as Claude Code, Codex, Gemini CLI, GitHub Copilot, and Cursor. The skill is published under the Apache-2.0 license, and a GoodSender account is free.

What changes in your routine

	Empty chat	With goodsender-blog
Context	You re-explain your blog every time	It reads your blog first: byline, tags, voice, and topics you already covered
Topic	Whatever you typed	It states the goal and, if you have not picked an angle, offers two or three with trade-offs and recommends one
Facts	Gaps filled from the model's memory	Every factual claim tied to a source or to your word, then checked in a separate pass
Post fields	Title, summary, description, and tags requested one by one	Prepared together and saved in one draft, with a preview link
Social posts	Written later, in another chat	Prepared for each destination you select, before anything is published
Publishing	Copied by hand into each place	Nothing goes out until you approve the actual destinations

The skill keeps its editorial questions to three moments: one message with what only you know, at most one question about claims that still need a source, and one review package at the end. Connecting your account, choosing destinations, and your assistant's own tool confirmations can add a step. Publishing waits for your separate approval.

A workflow, not a prompt

A prompt tells the assistant what you want. The skill tells it how to get there. It carries an editorial process refined over years: how to choose a topic and an angle, how to find and check facts, and how to build the structure around them.

The process runs in twelve stages, grouped here into four phases. Each stage has a gate the assistant must pass before it moves on.

Understand. With GoodSender connected, the assistant reads your blog settings and your most recent posts to learn the voice, byline, and tags. Then it settles the goal: who the post is for and what they should do afterward. It also reads the post type from your request, whether that is an explainer, a tutorial, an opinion piece, a case study, an interview, or a story, and applies the checks that type needs. It asks you once for what it cannot infer, such as what happened, real numbers, dates, and whether you want images.
Write. Evidence is collected in a fixed order of trust. Every major claim in the outline is tagged with its source, or marked as needing one. The draft is written in your blog's voice and toward the goal, then fact-checked in a separate pass.
Package. Title options, summary, description, tags, and any images you asked for are prepared, the draft is saved to GoodSender, and a preview link is created.
Ship. When you ask for it, with the draft or when you plan to publish, copy for each destination you select is prepared and saved without sending. You review everything and approve where it goes.

The skill works for posts on any topic, including fiction and other creative writing, where it checks continuity and any real-world claims instead of sourcing every sentence. It does not need a repository, a particular model, or a paid image generator. Short requests have their own paths: a quick sample skips the interview, and a narrow edit changes only what you asked for.

Facts checked before your name goes on them

When an empty chat is missing a fact, it can fill the gap itself: a plausible number, a study that sounds right, a quote nobody said. Under your byline, that becomes your mistake.

The skill's first rule is that the model's own knowledge is never a source. A factual claim the assistant introduces goes into the post only when something stands behind it, in this order of trust:

You: what you say in the conversation and the files you share
Git repositories you work in or name
Your blog's published posts
Web sources with a URL, cited in the post

A claim without a source is marked in the draft, never quietly asserted. Then a separate fact-check pass, run in a fresh-context subagent where your assistant supports one, reads the draft as if someone else wrote it. It sweeps for words like "most" and "typically" and for every first-person sentence. It returns a ledger: what was verified, what rests on your word, what was hedged, and what was cut.

If anything still lacks a source, you get one numbered message: confirm, source, or cut. Anything you leave unanswered is hedged or removed, so the draft never stalls.

The check works in both directions. If the model's knowledge is out of date or it simply invents something, the claim does not pass. If a reliable source contradicts your own material, the skill tells you once, with the link, and you decide.

You still own the post. What you state or confirm goes in the way you want it. The ledger shows you which parts nobody checked.

All the post fields in one save

A GoodSender post carries more than its body, and each field feeds a different place:

Field	Where it appears
Title	Page heading and search result title
Summary	Lede under the title, blog index card, RSS
Description	Search snippet and social cards
Tags and categories	Public index pages on your blog
Byline	Author line and structured data
Cover image	Post page, cards, and social previews

Through the GoodSender MCP server, the skill saves them together with the draft. The cover is included when you have an image or your assistant can generate one. It proposes the title with alternatives instead of choosing silently. It writes the summary and the description as two different sentences for two different readers. It reuses the tags your blog already has, because a near-duplicate tag splits one topic across two index pages. Images are uploaded through GoodSender and converted to WebP.

The post is saved as a draft with a signed preview link. There are no extra rounds asking for the description you forgot.

Announcements written for each platform

The skill writes separate announcement copy for each destination you select, framed for the people who follow you there. A professional audience may need the practical implication and a concrete example. A short post may need only the problem and the payoff. Each version is checked for new claims and against the platform's length budget, including the link GoodSender adds, and the whole package is reviewed together before you see it.

Destination	What the skill prepares
X, LinkedIn, Bluesky, Mastodon	Announcement copy for that platform, with a link to your post
dev.to, Hashnode	The full article, with a canonical URL pointing back to your blog
Newsletter	A dedicated subject line and summary, followed by a "Read the full post" button

Distribution is saved as a plan, not sent. A connected account is an option, not consent: if you asked for announcements but have not said where, the skill asks which connected destinations to use, and it makes the newsletter a separate, explicit choice. Before publishing, you see the exact destinations and accounts.

When you publish, GoodSender puts the page live and delivers to every destination you selected: announcements, republished copies, and the newsletter email. Sent email cannot be recalled and external posts are not removed for you, which is why the approval comes first. The skill then reports what was published, delivered, pending, blocked, or failed, each separately.

Get started

Download the skill: goodsender-blog-latest.zip. The link always points to the latest release.
Install it.
- Claude: Customize → Skills → Create skill → Upload a skill, then upload the ZIP as downloaded. Skills must be enabled for your account. To update later, download the link again and re-upload.
- ChatGPT: Skills → Create → Upload from your computer. Availability depends on your ChatGPT plan, and uploaded skills do not sync between the desktop app and web or mobile, so add it on each one you use.
- Gemini (web or Mac app): Settings → Skills → Upload. If the ZIP is not accepted, unpack it and upload the folder.
- Coding agents: unpack the ZIP into the agent's skills folder:

mkdir -p ~/.claude/skills && unzip goodsender-blog-latest.zip -d ~/.claude/skills/   # Claude Code
mkdir -p ~/.agents/skills && unzip goodsender-blog-latest.zip -d ~/.agents/skills/   # Codex, Gemini CLI, Copilot, Cursor

Ask for your first post:

"Use goodsender-blog to write a post about [your topic] and leave it as a draft for review."

That is all you need to start. Writing the post does not need anything else. When the draft is ready to save, the skill asks for a GoodSender account and its connection to your assistant, and helps with whichever step is missing. Once a session, it also checks for a newer release and mentions it in passing; it never installs anything on its own.

Bring the topic you have been putting off. This time the routine starts from your blog, not from an empty chat.

Download goodsender-blog · Start your blog

A blog for people who don’t have time to blog

Givi Pataridze — Thu, 01 Oct 2026 19:53:43 +0000

Bring the idea. Make it a post. Keep it going.

You know your subject. You explain it to colleagues, solve problems, make decisions, and learn things someone else would find useful.

Then someone says, “You should write about that.”

They’re right. But writing the article is only part of the job. There’s formatting, images, publishing, the email, and the announcements. Your idea stays in your notes.

GoodSender is now a blog platform built around helping you take that idea further. Work with your AI assistant to develop it, review the result, and publish to your own blog. Prepare the email and social announcements in the same publishing workflow.

Your experience gives the article its value. You get help turning it into something people can read.

Start with something you already know

Think of a question you keep answering. A decision you can explain. Something you tried that changed how you work.

That is enough to start. Open Claude or Codex with GoodSender connected through MCP, the Model Context Protocol, and give it your rough notes:

“Here’s something people keep asking me about. Turn my explanation into a useful blog post. Keep my perspective, ask me where something needs explaining, and prepare a GoodSender draft for review.”

The assistant helps shape the argument and prepares a draft. You add the example it missed, correct the part it misunderstood, and decide whether the article says what you mean. Then you preview it on your blog.

You can stay with the idea while the assistant handles the steps between rough notes and a draft in GoodSender. You can also open that same draft in the editor and work on it yourself.

This article followed that approach. It was drafted with an LLM from our product direction and repository, revised through conversation, and prepared for publication through MCP.

Start your blog. Bring one idea you have been meaning to write about.

Prepare the post and the invitation to read it

Once the article is ready, there is another piece of writing to do: give people a reason to open it.

GoodSender connects the original post to the different forms that invitation can take:

Email: a summary that gives subscribers a reason to read, followed by a “Read the full post” button.
LinkedIn and X: announcements tailored to each platform, with a link to the article.
Bluesky and Mastodon: announcements for the readers who follow you there.
dev.to and Hashnode: the full article, with a canonical URL pointing back to the original on your blog.

That last detail matters when the same piece appears in several places. The canonical URL identifies your original as the preferred source.

Connect the accounts you want to use, select destinations for the post, and review the distribution copy before publishing. A personal essay and a practical tutorial can reach their readers through different channels.

Email is built into GoodSender, backed by our sending infrastructure on Laneful. Subscription confirmation, unsubscribes, and complaint handling are part of that foundation.

Give the next post a starting point

An article often leaves you with another question worth exploring. You explained an idea. Next, show how you used it. Then write about what you learned.

Ask your assistant to propose a series from the material you already have. A set of research notes, lessons from managing a team, or stories behind product improvements can each give you several connected articles. A changelog is another possible source.

You can also give your assistant access to the repository you work on as a developer, tester, or owner, or several repositories you work across. Ask it to find the stories in the code, documentation, and changes, then help you explain why they matter.

With a scheduled task in Claude Cowork and GoodSender MCP connected, you can make preparing the next draft a recurring part of your routine. For example:

“Every Friday, review the new notes in this folder. Suggest the next article in our series and prepare a GoodSender draft. Ask me about missing examples and leave it ready for my review.”

The recurring task runs in Cowork. GoodSender holds the drafts and publishes the posts. You review each piece, decide what is ready, and can schedule finished posts for publication.

The next writing session begins with something to respond to.

Ready for readers, search, and AI

Your idea deserves a page that is ready for readers.

Your blog starts with templates already optimized for Performance, Accessibility, Best Practices, and SEO. That foundation is ready to use: see the scores from a test of a GoodSender blog below.

Underneath the page, GoodSender handles rendered HTML, metadata, canonical tags, a sitemap, and RSS. Search crawlers and AI systems can read the article text directly. Those are the foundations behind its SEO and answer engine optimization, or AEO.

Images get attention too. Uploaded images are converted to WebP and prepared in multiple sizes, taking image conversion and resizing out of your publishing checklist.

Your blog lives on your own domain. Email and social announcements bring readers back to the same growing collection of your work.

Coming next

We are working toward fully customizable blog design through AI conversation, while preserving the SEO and AEO foundations built into our templates. Describe the blog you want, then refine its design by talking through changes. This feature is upcoming.

For your first post, start with the thing you explained to someone this week.

Create your GoodSender account, connect your domain, and turn that explanation into an article. You can begin drafting while your domain is being connected.

Start your blog

A $169 DIY AC controller that saves 450 kWh a month

Givi Pataridze — Thu, 24 Sep 2026 20:59:44 +0000

A friend of mine runs a small photo studio, rented out by the hour. There is no staff. Photographers book a slot, punch a door code, and let themselves in with their clients and their gear.

That last part is the whole problem. You cannot ask a paying client to stand around in a hot room while a wall-mounted air conditioner catches up. And a room full of people under shoot conditions goes stale long before it gets hot, which is why this story involves a CO2 sensor.

Before this project, the climate was run by whoever was there last. They set the air conditioners with a remote and left. So the units routinely ran all night for an empty room, and just as often the next booking walked into the wrong temperature anyway.

My friend is not there most days. I am almost never there. But I am the person in our friend group with a soldering-adjacent reputation, so I got volunteered.

I had never actually soldered anything. That becomes relevant.

the plan that was supposed to cost $60

The studio runs on a small budget. That is why its two air conditioners are cheap white-label Chinese splits rather than a known brand, and it is why the proper routes, a commercial climate-automation install or one of the smart-AC-controller gadgets, were never seriously on the table. They cost several times more than what I ended up spending, and what I ended up spending was already too much.

On July 17 I asked Claude to pick the parts. The requirements: a small ESP32 controller board, Ethernet with power over the cable, a sensor for CO2, temperature, and humidity, and infrared control for the two ACs. Infrared control means teaching a circuit board to click the remote electronically. The AC cannot tell the difference between a remote in a human hand and a small LED blinking the same pattern at it.

The first estimate came back at about $60.

the cart that checked out

By July 20 the plan had grown. Instead of small boards hidden near each AC, I wanted one elegant wall-mounted device with a color screen: temperature in big digits, CO2 next to it, buttons on the front. The cart, all from M5Stack's shop:

Part	Price	Role
M5Stack Basic v2.7	$39.90	`ESP32` controller with the color screen
LAN PoE base W5500 v1.2	$48.50	Ethernet plus power over the network cable
Unit CO2L (`SCD41`)	$45.90	CO2, temperature, humidity
2x Unit IR	$7.90 each	infrared emitters, one per AC
Grove cables and jumpers	$10.40	wiring

Total: $169.70 (including shipping). Claude confirmed the cart item by item. Its verdict: checks out, safe to order.

Every item on that list was correct. The cart was fine.

It just wasn't the plan.

what arrived, and what didn't fit

The boxes arrived August 13, and every part was individually fine. The catch showed up during assembly, and it was not a missing part. It was a budget problem of a different kind: one small ESP32 does not have enough free pins and communication channels to run everything at once.

Think of the board's pins as outlets on a power strip, except some devices refuse to share and some insist on a specific outlet. The Ethernet chip in the PoE base claims the SPI bus plus a handful of GPIO pins. The color screen needs that same SPI bus plus pins of its own. The CO2 sensor takes the I2C port. And each infrared unit wants its own direct GPIO line, because infrared needs exact microsecond timing that can't be routed through a shared connection.

Ethernet, screen, sensor, and two IR channels together simply do not fit on this board.

Something had to lose.

what got cut

Ethernet lost first. The $48 PoE base stayed in the build, but only as a power supply: the network cable delivers electricity and nothing else, and data moved to Wi-Fi permanently. There is a comment in the shipped config that says exactly that. I paid $48 for a power brick.

The IR receive channels lost second. The infrared units run transmit-only; I wired up a receiver when I needed to record the real remote's signals.

Then came the second catch. The screw terminals on the PoE base, the natural exit point for the IR wiring, are not connected to anything from the factory. Power, ground, and the control pins simply do not reach them. The usable pads exist only inside the stack. Claude and I walked through every no-solder alternative, and each one died. A hub is the wrong kind of connection: IR needs a direct GPIO with a 38 kHz carrier and microsecond timing, and every hub in this ecosystem is an I2C device that physically cannot do that. A $6 pass-through module needs soldering to attach anyway. Claude's summary: the six terminals are a blank to be soldered, not a ready breakout.

I had specified this build as no-soldering. Every path led back to a soldering iron. This is the point where I swore at my AI assistant, and its answer boiled down to: the parts are all fine, the sentence missing at order time was that wiring the IR units out of this stack means fifteen minutes with an iron.

It was right, which did not help.

four wires

So I bought a soldering iron, the first one I have ever owned, and practiced on a dead board.

The actual job was four jumper wires from the base's internal pads to the screw terminals: ground, 5V, and the two IR signal lines, G16 and G17.

It worked.

Four wires. That was the entire distance between one elegant device with a screen and a stack of parts that talk past each other.

an air conditioner that spoke no known language

Now the software half. The ACs are branded "Wagner," a regional white-label name, remote model G4W-18BHR. The obvious theory is that a no-name split is one of the usual suspects inside: Gree, Midea, the Coolix protocol family. ESPHome's IR climate support covers all of them out of the box. You capture one button press, the library names the protocol, and you're done.

I got an early false victory. The first remote I captured, to test the receiver wiring, was my home AC's remote. It decoded instantly as Coolix. For a while the plan was: it's Coolix, config done.

The actual remote was not the same remote.

The Wagner remote matched none of the roughly ten ready-made protocol decoders I tried. Gree in all its variants, Coolix, Midea, TCL112, everything. Nothing recognized it. Somewhere a factory had shipped an air conditioner speaking an infrared dialect none of the usual open-source decoders recognized.

reverse-engineering the ir protocol from 97 recordings

So we decoded it from scratch: me pressing buttons, Claude staring at the timings. I captured 97 infrared frames, and on September 1 the pattern gave in.

The result, now documented in the project repo: a 38 kHz carrier, which is the specific flicker rate the AC's receiver eye is tuned to. A 96-bit frame, 12 bytes, sent least-significant-bit first. A 6180 microsecond header pulse announcing each message. Temperature encoded as the value minus 16 in byte 9, so 24°C travels as an 8. Fan speeds numbered backward, 1 for max and 3 for min, because of course they are. And a checksum, the frame's built-in way of noticing corruption, that is nothing fancier than the sum of the first 11 bytes modulo 256.

No existing ESPHome component spoke it, so we wrote one: a custom decoder and encoder, built largely with Claude doing the byte arithmetic and me doing the button pressing.

proving it

A decoded protocol is a theory until it round-trips. We re-encoded every captured frame from the formula and compared the output byte for byte against the recordings. The first run scored 44 of 45; the single mismatch was a transitional frame caught mid-mode-switch. The control run scored 52 of 52.

Then the loop closed itself in the most satisfying way available. On the first live transmission, the device's own receiver caught the frame its own transmitter had just sent, and decoded it correctly. The bytes matched a recording of the real remote for the same state exactly.

On September 4 the real indoor unit obeyed: on, off, factory turbo.

The protocol was closed.

the bug that wasn't

One debugging story worth its space. The IR LED on the emitter module is fed through a 150 ohm resistor, about 23 mA, against the hundreds of milliamps a real remote pushes. Range is roughly two meters and the beam is narrow.

One day the AC stopped responding. I burned hours on a plausible hypothesis: maybe a single frame wasn't enough and the command needed repeating, the way some remotes hammer their message several times. Four-copy frames worked once, by coincidence, then failed too. The actual cause, the entire time, was that the LED was pointed slightly off axis. Aimed properly, a single frame was enough, exactly like the factory remote.

With a weak emitter, aim matters more than distance. The AC was never ignoring me. I was talking past it.

controlling a split system remotely, without the remote

Here is the finished behavior, running on the wall with nobody in the building, no server and no phone app required to keep it running.

The room sensor is the thermostat, not the AC's own one, and it updates every 60 seconds. In summer, cooling switches on at 24.0°C and off at 23.0°C. In winter, heating switches on at 18.0°C and off at 22.0°C.

The trick that makes a cheap split behave is the setpoint. The box deliberately commands the AC to an overshoot target, 18°C when cooling and 24°C when heating, so the AC's own thermostat never decides it's done and starts dawdling. The box itself cuts the unit off when the room sensor says done. The AC works at full tilt or not at all, and the room, not the machine, is the judge.

Every 15 minutes the box re-sends its current command. Anyone who fixes the climate with a physical remote gets quietly overruled within a quarter of an hour. The remotes still work; they just don't win.

The night schedule is the money part. Both units switch off from 23:00 to 08:30, every day, because night bookings are rare and an empty room does not need conditioning. A frost guard heats if the room falls to 10°C and stops at 13°C. The rare night visitor presses a button on the box to suspend the schedule.

Three buttons total: cycle auto/manual/off, toggle the night schedule, and a 180-minute boost at the coldest setpoint and max fan. The screen shows temperature in half-screen digits and CO2 color-coded: green below 1000 ppm, yellow to 1500, red above. Red means open a window, which in a room full of people under shoot lights happens well before anyone feels warm.

And a failsafe: if the temperature sensor drops out, the box switches both ACs off rather than run blind. Turbo and off are the only commands it will still send without sensor data. There is no server, no cloud, no app. If Wi-Fi dies, the logic keeps running on the device.

turning the ac off at night: what it saves

I did not install an electricity meter, so what follows is arithmetic on stated assumptions, not a measurement. The assumptions are in the open; disagree with any of them and the number moves.

The remote's model number marks these as 18,000 BTU-class splits, which draw roughly 1.5 to 1.8 kW while the compressor runs. Left on overnight, a split's compressor cycles; call it running about half the time. The schedule removes 9.5 hours a night, on two units.

Two units, 9.5 hours, about 1.65 kW, half duty: roughly 15 kWh per night, with a fair range of 12 to 19. Per month, roughly 450 kWh, range about 350 to 570.

Pricing is illustrative arithmetic only: at $0.10 per kWh that is about $45 a month, so the $166.40 of hardware pays for itself in around four months on the night schedule alone, before counting whatever the daytime hysteresis saves. Your tariff will differ. The shape of the number will not: the biggest feature in this build, the one that actually saves electricity, is the off switch.

the same build, cheaper: no screen, no PoE

Now the honest postscript. Knowing everything above, here is what I would actually build.

The roughly $50 version, no soldering. Two M5Stack Atom Lite boards, under $10 each, one stuck next to each AC. The IR LED is already on the board, so the entire soldering saga in this post evaporates. Add one CO2 sensor unit on the Grove port of one Atom (the SCD40 version was $33.90 when I checked in July; the SCD41 in my build costs more). Power both from any USB phone charger. Run the same ESPHome logic over Wi-Fi. No screen: the numbers live in ESPHome's built-in web page, readable on any phone. No PoE: the phone charger is the power supply. This is the version I should have started with.

The roughly $20 version, if you can solder a little. Any generic ESP32 dev board, $4 to $6. An IR LED plus a transistor and two resistors, under a dollar in parts, is the whole IR side. A basic temperature and humidity sensor, a few dollars, covers the thermostat. That gets you the hysteresis, the overshoot trick, and the night schedule: everything in this post except the CO2 number.

Where not to cheap out: the CO2 sensor. A real CO2 sensor, photoacoustic or NDIR like the SCD40 and SCD41, is the one part that costs real money, $30 and up, and it costs that for a reason. Cheaper boards advertise eCO2, which is an estimate derived from other gases, not a CO2 measurement. That warning surfaced in my July parts research and is why the SCD41 is in the box. If the room-full-of-people number matters to you, pay for it. If it doesn't, drop it, and the whole build gets very cheap.

What did the $169.70 actually buy over the $50 version? A screen on the wall, so the numbers are visible without a phone. Three physical buttons. And $48 of Ethernet that carries no data. The logic, the protocol work, and the savings are identical on the cheap builds.

I would build the $50 version today. The $169.70 version is what it cost me to learn that.

Because here is the thing the whole project turns on: not one expensive part ever failed. The board was fine, the base was fine, the sensor was fine, and Claude's cart really did check out, line by line. What nobody counted was the connections: the shared bus, the pin budget, the six terminals that were a blank.

BMAD Ate My Month: When Spec-Driven Development Is Too Much

Givi Pataridze — Tue, 22 Sep 2026 08:20:39 +0000

On September 5 I deleted 1,782 files from my autopilot's repository in one commit. Agents, templates, workflow configs, a PRD (Product Requirements Document), an architecture document, a story backlog longer than most novels. About 16 MB of process, and not one line of product.

Typing that commit message felt better than anything I shipped that month.

Some context if you are new here. The autopilot is an autonomous coding system I built and have been running for months: it receives GitHub webhooks and runs headless Claude Code sessions that write, review, and merge pull requests without me at the keyboard. I have told its story before, from building it to the day it ran out of tokens. This post is about the question those posts skipped: how work should be planned before an agent ever sees it.

The industry has an answer to that question. SDD (Spec-driven development): write the specification first, make it the contract, and let the agents implement against it. BMAD is that idea at full weight, an entire agile organization in software, with AI analysts, architects, product managers, and developers, and a workflow that runs them in order. For four weeks, it planned my product.

This post is about what that month cost, and the embarrassingly small thing that actually fixed the problem BMAD was supposed to fix. If you run coding agents and your PRs keep turning into hostage negotiations, this is for you. I got this wrong twice before getting it right, and both wrong answers looked smart at the time.

The failure that started everything

You know this failure. You have probably committed it this week.

You are busy, the agent is capable, so you file a one-line issue: remove this, add that, make it configurable. The agent reads your line and builds either the wrong thing or a monument to the right one. Then the reviewer model, the expensive one you hired precisely to catch problems, catches the problem. In review. After the work exists. After the money is spent.

My worst case: a cleanup that should have been a quiet deletion collected sixty comments across ten review rounds. Two models arguing with each other, round after round, every round billed to me. Then I closed the pull request without merging it.

Sixty comments. Ten rounds. Nothing shipped. And the whole argument was downstream of one line I wrote in thirty seconds.

Attempt 1: the machine tried to fix itself

My autopilot's answer to "the PRs are too big" was, I swear, more autopilot.

It generated a size gate: a scope agent that estimated the diff an issue would produce, and above a budget carved the work into ordered sub-issues. Almost six thousand lines of new code, to enforce a line budget on future code. I did not design this. The machine did, and the design was even accurate about the disease. Its own PR body diagnosed that large PRs drive the review churn.

And still it was attacking the symptom. The gate measured work after the intent was already written badly. Splitting work after it exists is triage, not planning. By the time there is a diff to estimate, the mistake is old. It was made in the issue.

I never merged it. The dangerous part is how reasonable it looked.

Attempt 2: BMAD

I found BMAD through a podcast on spec-driven development. One of the guests was a BMAD contributor, and everything he said sounded solid. I wanted solid. I was tired of arguing with my own pull requests.

So the day after rejecting the machine's six-thousand-line fix, I installed a 1,782-file one.

BMAD planned my product the way an enterprise plans a satellite launch. A 13,397-word PRD. A 19,867-word architecture spine. An epics.md backlog that reached 43,062 words. Nine epics, 86 stories, every one with acceptance criteria. Reading the plan felt like adult supervision had finally arrived.

Five days in, an implementation-readiness assessment found one critical omission and three major planning defects, and blocked all further implementation. Sit with that. The plan failed a review of the plan. The fix, approved the same day, grew the plan to 91 stories. The product had not moved.

Then the loop started, and I met the real bill. A typical story burned one to two million tokens. One story hit around thirty million. Thirty million tokens, one story. Maybe I misconfigured something; honestly, I probably did. But look at what my config had to become in self-defense: a four-million-token budget per story, a 210-minute session timeout, a hard cap of seven review cycles, nudge budgets for sessions that stall without a result. Those are not settings. Those are restraining orders.

To be fair, bmad-loop itself is genuinely well built. The TUI is impressive. The quality bar is real; the reviews caught real defects. In four weeks, 23 stories were implemented and reviewed through it. Six more finished their code and parked themselves as "awaiting operator", waiting for things only a human can do.

But my product was young and changed constantly, and every change created homework. Update the PRD. Update the architecture. Update the backlog. The documents needed to be current before the code was allowed to move, so the code moved at the speed of the documents.

I was supposed to operate an autonomous system. I had become its secretary.

My verdict is not that BMAD is bad. BMAD is solid. Too solid. For an established product with a stable spec, that bar might be exactly right. For a product still finding its shape, the bar killed the only metric that mattered: time to release. On September 5 the whole kit left in one commit, and the release line moved forward the same day.

Attempt 3: steal the good part, skip the religion

Here is what actually worked, and what I would tell you to do instead of either of my failures.

I did not adopt another framework. I took the one thing from the spec-driven world that had earned its keep, Spec Kit's way of expressing intent, and forced it into add-autopilot-issue, the skill I already used to file work. Spec Kit is compact where BMAD is encyclopedic, and it asks quite exactly the right questions: what changes, for whom, how you will know it worked.

The mechanics that now run my intake, all of them small:

Every story issue carries a pinned spec reference: Spec: owner/repo@sha:path#user-story-N, full 40-character SHA required. Coder and reviewer read that exact version, so neither can move the goalposts mid-session by editing the spec.
One user story becomes one issue. Two or more become a parent epic issue with one issue per story and an epic/NNN-<slug> integration branch.
A story with more than 12 tasks gets split before it is filed.
Reviews run against the pinned spec with a BLOCKING/SHOULD/NIT rubric, so "I don't like it" and "this violates the spec" stop being the same comment.

And one rule no code enforces, because it is mine: when I write an issue, I aim for work around 300 lines of non-test code. Small enough that a session cannot wander, small enough that a review cannot spiral.

That is the entire fix. A reworked skill and a pinned line of text. The smallest thing I tried, and the only one still on main.

Decided before it starts

Three attempts, one lesson wearing three costumes. The quality and cost of an autonomous coding session are decided before it starts: by how precisely the intent is expressed, and by how small the work arrives. The size gate tried to enforce that in code, after intent. BMAD tried to enforce it in documents, on top of intent. What worked was just doing it: saying precisely what I want, in pieces small enough to survive contact with review.

One more observation, offered as observed because I have not measured it and it is clearly not linear: the better the intent is expressed, the cheaper the model that can execute it.

And a verdict, for whoever is weighing BMAD right now. I did not dabble. I ran the full, fundamental approach, the way it is meant to be run, and for me it did not work: too long, too expensive. For an enterprise with a stable spec and a tolerance for ceremony, that same weight may be exactly right. My projects move fast, and BMAD could not keep up with them. So the experiment is closed. I will not run it on any of my projects for now; more flexible approaches carry its best idea at a fraction of the cost.

That is what those 1,782 deleted files were. Not a failed tool.

A closed experiment.

How to Send Email via Claude Desktop

Givi Pataridze — Wed, 10 Jun 2026 08:23:17 +0000

How to Send Email from Claude — Free, in Two Minutes

Two minutes from now, Claude Desktop will send a real email through your own account. This guide is for Claude Desktop users with a GoodSender account who want to wire up email via MCP. GoodSender is free for the first 100,000 emails per month, no credit card required.

Prerequisites

Claude Desktop installed.
A GoodSender account — sign up free, no credit card.

Step 1: Install the MCP Server

Download goodsender.mcpb from the latest GitHub release. Double-click it. Claude Desktop registers the server automatically.

Using a different AI client like Cursor? You'll need the Docker or manual binary path — see the MCP server docs.

Step 2: Add Your API Key

Grab your API key from the GoodSender dashboard. Paste it into the configuration prompt Claude Desktop shows after install.

Before sending, make sure you've also verified your sending domain in the GoodSender dashboard.

Flow 1: Compose and Send a Custom Template

In Claude Desktop, ask Claude to create a "weekly update" template using the MCP template composer:

Create a new email template called "Weekly Update" with a subject line "Your weekly update from Awesome App" with a futuristic design using GoodSender MCP

Claude opens the MCP template composer and builds the template with your variables. Once you're happy with it, ask Claude to send it:

Send the Weekly Update template to me at you@example.com.

A note on consent: Custom sends to recipients require the Permission Loop. GoodSender requests consent from the recipient first — outbound messages queue locally until consent is granted. Once a recipient approves, subsequent sends from your domain go through instantly. That earned permission is what keeps deliverability compounding rather than degrading over time.

Flow 2: Send a Transactional OTP Email

Transactional templates are the contrast case — no template setup, no consent step, and they fire instantly. In Claude Desktop, paste this prompt:

Send an OTP code to me at you@example.com.

Claude picks the GoodSender MCP, calls the transactional template endpoint, and the email lands in your inbox instantly. Transactional templates ship without a consent step, so there's no queue and no setup — the send goes through the moment Claude calls the tool.

Flow 3: Schedule a One-Time Send

Claude Desktop (in Cowork mode) has a built-in scheduler. You can use it to schedule a one-time send of the Weekly Update template for Monday at 10am — GoodSender's MCP handles the actual send when the scheduled time fires.

Schedule a one-time send of the Weekly Update template to you@example.com for Monday at 10am. Use headline "Monday briefing" and "Here's what's coming up this week."

What You Can Do Next

Now that you've got email working from Claude, the best thing to do is try it with your own use case. Send an OTP to a real user, schedule a weekly update, or write an email in Markdown and watch it render perfectly across 90+ inbox clients. The setup is already done — the rest is just asking Claude.

Why GoodSender for This

Free for 100,000 emails per month, no credit card. Consent and engagement are built into the API — the Permission Loop gates custom sends on explicit recipient consent, and the Engagement Check monitors recipient activity over time — so deliverability compounds rather than degrades. It runs on the same IP infrastructure Laneful uses for the world's largest senders.

Get Started

Get your free API key →