Every day, a pipeline scans the day’s AI sources, groups them into stories, throws out anything it has already covered, writes original posts with a point of view, scores each one against a quality bar, makes its own art, and publishes 8 to 10 posts. No human in the loop. It runs on a schedule and pings me on Telegram when it’s done.

I rebuilt the whole thing from scratch by directing an AI coding agent. This post is the full teardown. The architecture, the models, the calls I made, and the parts that broke.

Where it started

The old version was an n8n workflow. It turned curated YouTube transcripts into auto-published posts. About 3 a day, all in the AI-marketing lane.

It worked. But it was narrow. One source type. One topic area. Each post leaned on a single transcript, so it could only ever be as good as that one video.

The brief for v2

I wanted more range and a real spine:

• Broaden the scope from AI-marketing to all of AI. Models, research, builder tools, agents, products, applied workflows, policy, culture.

• Go from 3 posts a day to 10.

• Pull from more sources, and more kinds of sources, not just YouTube.

• Write with an actual point of view, synthesized across multiple sources, in an operator voice.

• Stay autonomous. Auto-publish with spot-checks, no approval queue.

I was open to leaving n8n behind. I did. v2 is a TypeScript pipeline that runs on a daily schedule in GitHub Actions.

How it works now

Each daily run moves through ten stages, end to end, with nobody watching:

1. Ingest. Pull the day’s items from every source.

2. Embed. Turn each item into a vector. Basically a string of numbers that captures what the item is about.

3. Cluster. Group items that cover the same story.

4. Dedup. Compare each cluster against a memory of everything already written, and drop the repeats.

5. Rank. Score the surviving stories by signal.

6. Select tiers. Pick the 2 to 3 biggest as flagships, the next several as notes.

7. Synthesize. Write each post from its cluster of sources.

8. Gate. Score the draft against a quality bar. Reject what doesn’t clear it.

9. Images. Generate a hero plus inline visuals.

10. Publish. Commit the posts, trigger the deploy, send a Telegram digest.

The quiet hero is dedup

If I had to point at one stage that makes the whole thing work, it’s step 4.

It uses a Postgres database with pgvector as a memory of everything the blog has ever covered. Plain version: every published story gets turned into that string of numbers and filed away. The next day, anything too close to something already written gets dropped before it ever costs a writing call.

That’s what stops the blog from repeating itself. A site publishing 10 posts a day will circle the same story five times in a week if nothing is watching. The memory watches. It also saves money, because a repeat dies before the expensive synthesis step ever runs.

Images, and the part I got wrong first

Every post gets at least two images. A hero, which doubles as the social card, and inline visuals. The writer drops a placeholder wherever a diagram or chart would help, and the image stage fills it.

The first version made every hero the same abstract, warm-toned shape. Looked fine on a single post. On the index page, every story looked identical. Just rows of the same blob.

So now there are five art directions: editorial illustration, flat vector, isometric risograph, cinematic still, and Bauhaus geometric. Each post gets one, chosen by hashing its slug. A given post always looks the same, but the feed looks varied. Each direction carries its own palette, freed from the site’s color scheme, and each image is grounded in the post’s actual subject.

One hard rule in the prompt: no text. The image model will cheerfully render any words you hand it, and it renders them badly. Ban the text up front and the problem goes away.

The stack

• Site: Astro, Tailwind, MDX, deployed on Vercel

• Pipeline: TypeScript on Node, run with tsx

• Orchestration: GitHub Actions, daily cron, gated by a repo flag

• Memory and dedup: Postgres + pgvector on Supabase

• Flagship writing: Claude Opus 4.8

• Notes writing: GPT-5.5

• Quality gate: GPT-5.5

• Embeddings: text-embedding-3-small

• Images: gpt-image-1

• Digest: Telegram bot

Sources span RSS feeds, YouTube, arXiv, GitHub releases, Hacker News, and Reddit. The point was variety of input, not one big firehose.

What broke

The architecture is the boring part. The interesting part is always where it broke, and there was plenty.

A couple I already mentioned count here. The identical-hero problem was a real one: the system did exactly what I asked and the result looked broken, because “make a nice hero image” and “make a feed that doesn’t look like a copy-paste” are two different jobs. And the image model rendering garbled text taught me that you don’t ask a model not to do something, you remove the option.

What I’d tell another operator

A messy process doesn’t get better because you added AI. It gets faster at being messy. The thing that made v2 work wasn’t a smarter writer. It was the boring infrastructure around the writer: a memory so it doesn’t repeat, and a gate so it doesn’t ship junk.

If you’re building something that’s supposed to run without you, build those two things first. The autonomy isn’t in the model. It’s in the guardrails.

Next up, I’m watching the gate. I want to know how often it rejects a draft that I’d have actually shipped, and how often it passes one I wouldn’t. That’s the number that tells me whether the quality bar is set right or just set.

I’m not an engineer. I built it part time, off the side of my desk. Total cost: around $300 in credits.

What it actually does

Someone hits the main domain. The site figures out where they are and what language they speak, then renders itself around them.

A visitor in the UK sees products available in the UK, in English.

A visitor in Brazil sees products available in Brazil, in Portuguese, with a one-tap toggle to English.

A visitor in Kenya lands in Swahili first, sees products available in their local market, and can flip to English if they want.

Same domain. A different site depending on where you’re standing on the planet. It’s an affiliate site, so the products matter as much as the language. Sending someone a link to something they can’t actually buy is a dead end.

How I built it

I used HyperAgent, an agent platform running on Claude, to design and build it. The site is hosted on GitHub and runs through Cloudflare.

I started small. An MVP with four countries. Get it working, watch it render correctly, then add more.

Then I iterated. And iterated. I’m on version 15 now. Each version added countries, languages, and market-specific product logic. Europe, South America, Asia, Africa. The map kept filling in.

What it cost

About $300 in credits. A couple of weeks of part-time work.

Here’s the part I keep coming back to. If I had tried to build this by hand, the old way, it would have taken me months. Honestly, I’m not sure I would have finished at all. Sixty countries of geolocation and 30-plus languages with market-specific product logic is a lot of moving parts for one non-engineer.

The coding agents did the heavy lifting. I brought the plan, the corrections, and the judgment about what to build next. The agent brought the speed.

What I learned

Start with the MVP and let the version numbers do the talking. Four countries proved the idea worked. Version 15 is what “prove it, then scale it” looks like when you don’t stop.

The bottleneck stopped being the code. It became deciding what to build next, and checking that each version actually rendered right before adding the next batch of countries.

That’s the shift I keep noticing. The hard part moved from “can I build it” to “what should I build, and is it actually working.” I’ll take that trade.

Next

Keep scaling the country and language coverage, and watch how it holds up as the map fills in. Same approach as the first four: small steps, watch the tape, add the next batch.

A note on how this got made: I talked this one out and had AI help me shape the brain dump into a post. The build, the calls, and the corrections are mine.

I walked out with $10,000 in Hyperagent credits just for showing up. That alone made the train ride worth it.

What I built

My entry was an agent called Sir Pitches-a-lot.

The job was narrow on purpose. Sir Pitches-a-lot exists to pitch Ashe Brands, my branding company, to prospective clients. That is the entire personality. I built it start to finish inside Hyperagent’s interface, which is genuinely pleasant to work in. You describe what you want, you wire up the behavior, and the thing runs. No glue code, no fighting a harness.

When the moment came, it pitched the person it was assigned to in the room, and it did a great job. The agent held its own. For something I had stood up in an afternoon, watching it pitch a real human in real time was the highlight of the event.

A couple of notes from the build. From where I sat, Hyperagent is a polished agent layer running on Claude. The models on offer were all Claude, at least for now, so with $10K in credits burning a hole in my pocket, I reached for the best one available, Opus 4.8. Obviously.

And the economics are the part that stuck with me. Hyperagent prices on tokens, so spend is real spend against real work. Building and running Sir Pitches A Lot for the whole competition cost me about $20. Which means I walked out with $9,980 still in the account. That is an absurd amount of runway for a tool I just met.

I can share the code for Sir Pitches-a-lot if anyone wants to poke at it.

The room

The people were the other half of the value. It was an eclectic crowd. I met Vic from Hyperagent, who does a lot of their social and training content. I met Elaine, who works at a major credit card company. I met Ed, who is a VC. I met a guy who had flown in from Europe for the week. Good conversations, the kind you only get when a room is full of people who actually build things.

They also loaded me up with merch. A name tag, a t-shirt, sunglasses, and a wristband. I did not put any of it on, but it is always nice to get handed something on the way in.

[IMAGE: flat-lay of the Hyperagent merch, t-shirt, sunglasses, wristband, name tag]

I did not stay to see who won. I wanted to catch my train and spend the evening with my family, so I ducked out before the final votes. No regrets there.

The actual problem

Here is the thing I am still chewing on.

I now have nearly ten grand in credits sitting inside a tool that is fun to use and clearly capable. I cannot picture a version of myself that does not dig in and build something real with it.

But the same night, Chief, my own agent running on the Hermes harness, did something on its own. Completely unprompted, it spun up a nightly job and built a small tool: an Affiliate Opportunity Scorecard that ranks content ideas by likely business value instead of vibes. A Python CLI, a generated HTML dashboard, unit tests, all of it working and sitting on my server when I woke up. I did not ask for any of it.

So that is the fork. Hyperagent is a polished playground with a five-figure head start. Hermes is mine, and Chief is already acting like a teammate who works the night shift without being told. I do not yet know how I split my time between them.

It is a good problem to have.

So I built one. I’m calling him Chief, because that’s the job: chief of staff. I like the name, and it stuck immediately.

Here’s how Chief came together, and where I’m taking him next.

The harness underneath: Hermes

Chief runs on Hermes, an open-source agent harness from Nous Research. If you haven’t run into the term, a harness is the layer that wraps around an AI model and gives it the things a raw model lacks: tools, memory, and a workflow structure for getting real work done over time. The model is the engine. The harness is the chassis, the steering, and the dashboard that turns that engine into something you can actually drive.

What sold me on Hermes specifically is that it ships the harness for you. Other agent setups I’ve looked at, like Claude Code and OpenClaw, expect you to hand-build all of that yourself: the memory files, the hooks, the workflows. Hermes comes with those layers already in place, and it’s model-agnostic, so I’m free to point it at whatever brain makes sense.

One naming note, because it tripped me up at first too. I didn’t name the harness. Hermes came with that name. I only named my instance. The harness is Hermes; the chief of staff I’m running on top of it is Chief.

Why a chief of staff, not just a chatbot

I already talk to AI all day. What I didn’t have was something that sits above the work: a single point of contact I can hand a vague instruction to and trust to route it correctly.

That’s the chief-of-staff idea. Not the one who does every task, but the one who knows the org, holds the context, and decides who handles what. I wanted one agent I could message like a human colleague, one that would quietly coordinate everything happening underneath.

So Chief isn’t meant to be the smartest model in the room. He’s meant to be the responsible one.

The stack

I kept it deliberately boring, because boring is what survives contact with daily use.

The brain: GPT-5.5, running on OpenAI’s $100/month Pro plan. OpenAI split Pro into two tiers earlier this year, a $100 option and the older $200 one, and for me the $100 tier is the sweet spot. It’s the same model suite as the top tier but with 5x Plus usage limits instead of 20x, which is plenty for an orchestrator that delegates most of the heavy lifting rather than grinding through everything itself.

The interface: Telegram. I spun up a brand-new Telegram bot specifically for Chief, so he lives in his own chat thread, separate from everything else. This turned out to be the best decision of the whole setup. Telegram means I can reach Chief from my phone, my laptop, anywhere, with no app to open and no tab to find. I just message him like I’d message anyone else. The chief-of-staff framing only works if talking to him feels as low-friction as texting a person, and Telegram nails that. It also plays to one of Hermes’ strengths, since the harness is built to run an agent across messaging, not just a terminal.

The future muscle: a Mac mini sitting at the office, which is where the sub-agents will live.

Setup was almost suspiciously easy

I’ll be honest: I expected this to eat a weekend. It didn’t.

Because Hermes ships the harness, I skipped the part that usually eats the weekend. I didn’t have to hand-craft memory files or wire up workflows from scratch. The real work was pointing Hermes at GPT-5.5 and connecting it to a fresh Telegram bot, and then Chief was responding in his own thread.

The genuinely hard part of any agent project was never the plumbing; it’s deciding what you actually want the thing to do. Once I’d answered that, the assembly was almost anticlimactic.

That’s worth saying out loud, because a lot of people assume building a personal agent requires some heroic technical lift. The pieces are all sitting right there now. The bottleneck is clarity, not capability.

Where this is going: orchestration

Here’s the part I’m most excited about, and the part that’s still ahead of me.

Right now Chief is the single agent I talk to. The plan is to turn him into a conductor. The Mac mini will host a set of sub-agents, specialized workers for specific kinds of tasks, and Chief’s job becomes orchestration: take my instruction, break it down, hand pieces to the right sub-agent, collect the results, and report back to me in Telegram like nothing complicated happened.

That’s the whole point of the architecture. I don’t want to manage a fleet of agents. I want to manage one agent who manages the fleet. I give Chief a goal; the Mac mini does the work; I get the answer. The complexity stays downstairs.

A Mac mini is a great little box for this. It’s quiet, low-power, always on, and happy to sit in a corner running jobs around the clock. It becomes the back office while Chief stays the front desk.

What I’ve learned so far

A few things stand out even this early:

The interface matters more than the model. GPT-5.5 is excellent, but the reason Chief feels useful is that he’s one Telegram message away. Reduce the friction to near zero and you actually use the thing.

Naming matters too, weirdly. Calling my instance Chief, and handing him a role, shaped how I set it up. I stopped thinking “what prompt do I write” and started thinking “what would I delegate to a competent person who never sleeps.”

And separation of concerns is everything. One agent to talk to, many agents to do the work. The moment I drew that line, the rest of the design fell into place.

Next steps

The orchestration layer on the Mac mini is the next build, and I’ll write that one up too, including what the sub-agents end up being and how Chief decides who gets what.

For now, I have a chief of staff who lives in my phone, runs on a $100 plan, and is about to get a team of his own.

Not a bad hire.

If you’re setting up something similar, the two decisions that mattered most for me were: pick a low-friction interface (Telegram, for me) and define the agent’s role before you write a single line of config. Everything else is just wiring, and with a harness like Hermes, a lot of that wiring is done for you.

They didn’t agree. Not on tone, not on what I write about, not even on who I am.

That sounds like a problem. It was the most useful thing that happened all week.

Here’s why they disagreed. Two of the three had built their guide around an older version of me, heavy on monetization and growth tactics. All real parts of my background. None of it where I’d actually landed. What I’m building now runs on a simpler rule: no public pitch. I’m learning in public, and the writing isn’t a sales funnel. The AIs weren’t wrong. They were working off old game film.

So the job changed. I wasn’t averaging three documents. I was deciding which version of me was current and reconciling everything to it. One draft had the sharpest voice. The other two had the better scaffolding, the templates and the vocabulary. I kept the sharp part, kept the useful scaffolding, and cut everything that was selling a business I’m not running in public.

Then came the rounds. And this is the part I didn’t expect: every pass made the guide less about adjectives and more about control. The edits that mattered weren’t “sound warmer.” They were the boring, load-bearing ones:

• Rule priority. An order for what wins when instructions collide, because they will. Accuracy and privacy beat sounding like me, every time.

• A missing-receipts rule. “Proof over hype” is a great line right up until the AI invents the proof. So if there are no receipts, write it as a hypothesis or a question. Never fake a case study.

• “Context is not boilerplate.” Every draft wanted to open with “as a non-engineer spending 20 hours a week...” Once, that’s context. Every time, it’s a tic.

• A prompt an agent can actually run, split into the part that never changes and the part that’s today’s assignment.

By the end it was about 580 lines. I QA’d it by running it back through all three AIs until they stopped finding things to fix. So I now own a 580-line document about how to sound less like a 580-line document. Progress.

If you want to find out where your own positioning has quietly drifted, here’s the cheapest test I know: have three different AIs describe you, and watch where they disagree. The gaps are the map.

For the record: I built the guide with AI, and used AI to help write this post about building it. The voice is mine. The typing was a team effort.

What we actually built was a playbook.

That matters, because “make this sound like me” is a terrible instruction for AI. It feels clear when you say it. It is not clear to the machine.

The machine does not know what “me” means.

It needs examples. Boundaries. Rules. Preferences. Corrections. A scoreboard.

That was the real work.

The problem I was trying to solve

I’ve been learning to build with AI in public. Part of that means writing about the process.

Build logs. Reflections. Notes on what worked. Notes on what broke. The occasional reminder that AI can make a messy workflow faster, which is not always a compliment.

But there was a problem.

Every time I used AI to help draft something, I could feel when it drifted.

Sometimes it sounded too polished.

Sometimes it sounded like a LinkedIn post that had been through three committees and one motivational speaker.

Sometimes it added hype I would never say out loud.

Sometimes it made me sound like I was pitching something, even when the whole point was that I’m not.

So the job became pretty clear:

Build a guide that helps AI write with me, not instead of me.

That sounds simple.

It was not simple.

Naturally, humans were involved.

We started with the obvious stuff

The first pass was basic.

Tone. Voice. Topics. Things I say. Things I do not say.

Plain English.

Short sentences.

No guru energy.

No “AI is coming for your job” doom bait.

No “this will change everything forever” hype parade.

Useful before clever.

Operator-to-operator.

That got us started, but it was still too vague.

Because “plain English” can mean a lot of things.

So can “optimistic but grounded.”

So can “don’t sound like a brand bot,” which is accurate, but not exactly a repeatable instruction.

The guide needed to get more specific.

The second pass was about tension

This was the part that made the guide useful.

My voice lives in the middle of a few tensions:

Confident, but not guru.

Optimistic, but not naive.

Technical, but plain-English.

Personal, but not oversharing.

Structured, but not sterile.

Business-minded, but not salesy.

Learning in public, but not pretending to be clueless.

That middle lane is important.

A lot of AI writing fails because it runs to the extreme. It tries to sound impressive. Or inspirational. Or authoritative. Or warm in that weird fake way where every sentence sounds like it wants to put a hand on your shoulder.

That is not the goal.

The goal is simple:

Sound like a real person who has done the work, is still learning, and is willing to show the process.

Then we built the guardrails

This is where the guide turned from “voice notes” into an actual operating system.

We added rules for what wins when instructions conflict.

Accuracy beats style.

Privacy beats color.

Usefulness beats jokes.

Specific task beats generic branding.

That matters because AI will happily optimize for the wrong thing if you let it.

Tell it to sound more like you, and it may start forcing jokes into places they do not belong.

Tell it to be inspiring, and it may invent confidence the work has not earned yet.

Tell it to write a build log, and it may quietly turn a half-tested idea into a case study.

No thanks.

Receipts over rhetoric.

If I built it, tested it, measured it, paid for it, broke it, or learned something real from it, we can write from that.

If not, the piece has to be framed honestly.

A hypothesis.

A plan.

A reflection.

A question.

Not fake proof.

The “AI tells” section became the film room

This was one of the most useful parts.

We made a list of phrases and patterns that make writing feel like generic AI output.

Things like:

• “It’s not just X, it’s Y”

• “Let’s dive in”

• Overusing em dashes

• The same tidy three-part rhythm everywhere

• Corporate filler words

• A closing paragraph that just repeats the article in nicer shoes

That section is basically film review.

Watch the tape. Find the bad habits. Fix the mechanics.

The point is not to make the writing less useful.

The point is to make it sound less manufactured.

AI has a house style. Once you see it, you cannot unsee it.

And once you can name it, you can remove it.

We also had to decide what not to say

This part matters more than people think.

A style guide is not only about what belongs in the writing.

It is also about what stays out.

For me, that means a few clear boundaries.

No public pitch.

No private business mechanics unless I explicitly ask for them.

No family details beyond broad, normal references.

No pretending audience metrics are the scoreboard.

No turning every post into “look at me building a personal brand.”

The scoreboard is learning.

That line became one of the anchors.

Because if the writing is supposed to document the education, then the content should serve the learning. Not the other way around.

The guide had to become usable by machines

A normal style guide is helpful.

A style guide that an AI agent can actually use is better.

So we turned the guide into drop-in prompts.

One markdown version.

One XML-ready version.

A stable system prompt for agents.

A user prompt template for each specific job.

That was the operator part of the process.

Do not make the instruction live only in your head.

Do not rely on memory.

Do not keep correcting the same mistakes forever.

Turn the judgment into a checklist.

Turn the checklist into a prompt.

Turn the prompt into a repeatable workflow.

That is where AI starts to become practical.

Not magic.

Just practical.

The weird part: the guide is not finished

This was another important decision.

The guide has stable parts and temporary parts.

The stable parts are voice, boundaries, tone, privacy, and principles.

The temporary parts are channel strategy, cadence, and where the work is currently showing up.

That feels right.

Because the work is going to change.

The tools are going to change.

The platforms are going to change.

The format will probably change six times before I pretend I planned it that way.

But the voice should not reset every time the workflow changes.

That is the point of the guide.

It gives the work a home base.

What I learned

The useful lesson here is not “everyone needs a style guide.”

Maybe you do. Maybe you do not.

The real lesson is this:

If you want better output from AI, you need to get better at explaining your judgment.

Not your preferences in some vague way.

Your actual judgment.

What good sounds like.

What bad sounds like.

What lines you will not cross.

What tradeoffs matter.

What examples count.

What proof is required.

What gets cut even if it sounds nice.

That is the work.

The prompt is the easy part.

The judgment behind the prompt is the hard part.

My takeaway

This guide started as a writing tool.

It became something bigger than that.

It became a way to make my own thinking more visible.

To me.

To the machine.

And eventually to anyone reading the work.

That is the part I did not expect.

Building with AI is not only about getting the machine to do more.

Sometimes it is about forcing yourself to define the work clearly enough that the machine has a chance.

That is a useful exercise.

Even if the first version is ugly.

Especially then.

AI involvement

This post is AI-assisted.

The style guide was built through an iterative process: draft, review, correct, tighten, test against examples, and turn the useful parts into repeatable instructions.

The machine helped organize the thinking.

I made the calls.

Next play: use the guide on real posts, see where it breaks, and update it from the work.

The honest version: an automated pipeline drafts every post on that blog. It reads, researches, writes, edits. Then it has to clear a 40-point quality gate before anything publishes. And most of the time, I look it over too before it goes live.

That’s worth saying out loud. So now it does. The new subtitle reads:

AI-written field notes from a marketer building with AI in public.

A few reasons I made the switch:

1. The whole point of this project is to show that AI can do real work when you actually engineer the workflow around it. Hiding the fact that AI is doing the writing works against that.

2. The 40-point gate is the proof. Plenty of people are posting AI slop with zero review. I’m not, and I want that visible.

3. “AI Blog” was a placeholder name. “The Lab” tells you what the place actually is.

Nothing else changes. Same URL. Same posts. Same RSS feed. The newsletter you’re reading right now stays in my own voice, drafted by me, no pipeline involved.

If you’ve been forwarding the blog to someone, the link still works. If you’d like to see how the 40-point gate actually works under the hood, I’ll write that one up next.

—Ken

Seven days later, the blog has been writing itself.

I haven’t tweaked the prompts. I haven’t bumped the gate threshold or rerouted a node. The pipeline runs every six hours, picks a video from one of the channels I’m monitoring, fetches a transcript, writes a 1,500-word post, scores it on a 40-point rubric, and either ships it or queues it for review. While I sleep. While I’m doing literally anything else.

That part is impressive. But it’s not the most interesting thing I learned this week.

The most interesting thing is what’s hosting the blog.

My blog lives on GitHub

There is no WordPress. No Ghost. No headless CMS. No hosting service with monthly tiers and storage limits and bandwidth overages. No “Editor” UI with logins and permissions to manage.

My blog is a folder of files in a Git repo.

That sounds like a small technical detail. It is not. It is the whole reason this build works for a non-engineer on a budget, and I think it’s one of the most underrated patterns for anyone building with AI in 2026.

A normal blog stack looks like this: you pay a hosting service, you log into an admin UI, you write your post in an editor, you click publish, and the hosting service stores your content in a database and serves it to readers. Three or four separate tools, each with its own UI to learn, its own pricing tier, its own way of breaking.

My stack looks like this: I have a GitHub repository. Inside it is a folder called content/blog. Every post is a single MDX file with some frontmatter at the top (title, date, tags) and the post body below. To publish a new post, the AI pipeline writes a file and commits it to the repo. Vercel watches the repo, sees the commit, and rebuilds the site automatically. The post is live in about 90 seconds.

That’s the whole thing. The GitHub repo is the host, the CMS, the editor, the database, and the version control system. One tool, doing the work of five.

What that actually gets you

This is not just elegance for its own sake. It unlocks specific, real-world things.

No hosting bill. Vercel’s free tier handles this kind of traffic comfortably. The only thing I pay for is the LLM tokens to write the posts. The infrastructure is free.

No CMS to wrangle. The schema of a post is whatever I want it to be. Frontmatter at the top, body below, done. If I want a new field tomorrow (say, an aiGenerated: true flag, which I might add), I just add it to the frontmatter. No CMS migration, no plugin compatibility check.

Everything is a commit. Every change to the blog is a Git commit. I can see what changed and when, and I can roll back any post, any edit, or the entire site, with a single command. This is version history that a normal CMS makes you pay extra for, and it’s free here because it’s built into how Git works.

The pipeline can manipulate the site directly. Posts, drafts, edits, deletions, configuration changes, design tweaks: all of it is just files in a folder. The n8n pipeline writes files. I write files. GitHub Copilot writes files. Everything is the same kind of object.

I can edit the blog from anywhere. I made a few edits this week from my phone, in GitHub’s web UI, while waiting in a parking lot. No app to install. No editor to configure. Just a text editor and a “commit” button.

The manual rescue workflow

This was the thing that really sold me on the setup.

Earlier this week, the gate queued a handful of posts that I thought were actually publishable with light touch-ups. In a normal CMS flow, I would have to log into the admin UI, find the draft, edit it in some WYSIWYG editor that may or may not handle Markdown well, click Save, click Publish, and then maybe wait for a cache to clear.

What I did instead: I opened the repo on GitHub, opened the queued MDX file, changed draft: true to draft: false, made a couple of small wording fixes inline, and clicked “Commit changes.” The post was live in 90 seconds.

That whole flow took about a minute per post. No special software. No admin login. Just a web browser and the same GitHub interface I use for everything else. The fact that “publish” is just “flip a flag and commit” is what makes manual rescue practical instead of annoying. I did this two or three times this week with posts I felt were strong enough to go live with minor edits.

And then there’s Copilot

This is where it gets weirder, in a good way.

I’m not a developer. I can read code, sort of. But navigating a real repository, finding the right file, understanding what a commit changed, asking “what does this configuration actually do,” used to be a wall for me.

GitHub Copilot inside github.com has dissolved that wall. I can highlight a file and ask what it does. I can ask why a build failed. I can describe a change I want and have it draft the diff for me. I am operating a software project through plain English, in a browser, as a person who does not write software.

This is the broader pattern I keep running into. Every tool I use is becoming an AI surface. Not “has an AI feature bolted on,” but is, structurally, an AI surface. GitHub is one. Vercel is another. n8n itself is one.

For non-engineers, this is the unlock. The technical depth required to ship something real is collapsing in real time.

What I’m watching

I haven’t tweaked the system this week, partly to see what it does on its own. Seven days in, here’s what I’ve noticed.

The gate is rejecting roughly at the rate I expected. Mostly for unsourced claims and overstated certainty, which is what I tuned it to catch. A few queued posts have been clearly recoverable with small edits, which is how the manual rescues started. The posts that pass the gate read like a smart operator’s notes, not marketing copy. That was the goal of the voice tuning, and it’s holding.

I’ll probably make my first real tweak this week. Or maybe not. One thing I’m learning about building with AI in public is that not touching the thing is sometimes the hardest part of the build.

Real name, no business, no pitch. Just education in public.

Ken

Day 2 was supposed to be about going from “tested” to “live.” It ended up teaching me more than I expected.

Pressing publish was the easy part. What came after was the actual learning.

The bug in the first output

The very first post the system generated had a tell. Buried in the third paragraph:

“The source video gets into this from a builder’s angle, and it lined up with something I’ve been chewing on for weeks.”

There it was. The source video. The whole point of the architecture is that the YouTube transcripts are research material, not subject matter. They’re scaffolding I’m reading to identify topics worth writing about. A post that says “the source video” is fundamentally a summary of someone else’s content, not original thinking.

It read like AI. Worse, it read like derivative AI. Exactly what Google’s helpful content updates were designed to penalize.

I caught it before publishing. The manual review on Day 1 was specifically so I could catch things like this. But the fix wasn’t trivial.

Why one behavior needed three fixes

You’d think you could fix “stop saying ‘the source video’” with a one-line addition to the prompt. You can’t. Here’s what it actually took:

Fix one: the writing prompt. Added explicit bans on “the source video,” “this video,” “the channel,” “the speaker,” and a dozen variations. Spelled out the philosophy: the transcript is research, not subject matter. The reader should never know a video informed the post.

Fix two: how the transcript was framed. The original instructions to the writing model literally labeled the transcript “Source video:” with the channel name and URL at the top. That framing was telling the model “this video is what you’re writing about.” I stripped all of that out. Reframed the transcript as “Research material that informed this topic” with explicit “do not reference this directly” instructions.

Fix three: the quality gate. Added source material references to the list of critical fails that the second AI must catch. Now even if a future prompt change causes the writing model to slip up, the gate auto-queues anything that mentions “the source video” for human review before publishing. Defense in depth.

The lesson: AI system failures often need fixes in multiple places. Where the model picks up the bad pattern. Where the input primes it for the bad pattern. Where you catch the failure if both upstream fixes fail. Single-point fixes feel cleaner. They’re fragile.

The Practitioner’s Take rule

The other big addition: every post must end with what I started calling a “Practitioner’s Take.” Not labeled with a heading. Just a closing paragraph that adds applied analysis instead of summary.

Generic AI-generated content tends to close with a summary or a “what this means going forward” platitude. That’s the gravity. Forcing the model to write something specific (what would you actually try, what’s the implication for someone shipping today, what’s the catch most readers miss) pulls it out of summary mode and into practitioner mode.

This is the move that separates a working note from a transcript paraphrase.

Feeling the system breathe

Going from manual to scheduled isn’t just flipping a switch. It means you need the system to tell you what’s happening when you’re not watching.

Telegram is my interface to the pipeline. Every successful post pings my phone with the title, the gate score, the verdict reason, any flags. Every queued post tells me what failed and why. I can feel the system breathing from my pocket.

This is the part most “AI agent” demos skip. A system you can’t observe is a system you can’t trust. The notifications are what let me let it run.

Pressing publish

When I activated the schedule trigger, the pipeline went from a thing I run to a thing that runs.

That’s a real shift. The work changes shape. Instead of building, it becomes watching, reading, tuning. Less typing, more judgment. Less code, more taste.

The system is now generating up to 3 posts per day, on a 6-hour cadence, with the quality gate filtering anything below 30 out of 40. Posts that pass go live within 90 seconds. Posts that don’t go to a draft queue I can review.

But pressing publish wasn’t the finish line. It was the start of the actual learning.

Three things real production taught me

Within the first 48 hours of the schedule firing, three problems surfaced that I hadn’t designed around. Each became its own small lesson.

Real data isn’t clean data. My topic-identification call was breaking on actual YouTube transcripts because they contain quotation marks, special characters, and other things that messed up how the API requests were being constructed. Worked fine in testing because my test transcripts were clean. Broke immediately with real ones. The fix was rebuilding that part of the pipeline so it handles whatever weird text shows up in the wild. Once I rewrote it the right way, I applied the same pattern to my writing and quality-gate calls too. Three brittle pieces became three reliable ones.

Real APIs are flakier than test APIs. Anthropic occasionally returns “overloaded” errors when their servers are busy. Doesn’t happen in light testing. Happens regularly when a scheduled run hits at peak times. The fix was tiny: small pauses between heavy API calls, so the pipeline doesn’t burst requests. Costs 30 seconds per run. Saves an entire run when it would otherwise fail.

A system that runs without you needs to tell you when it’s struggling. I had notifications on success but nothing on failure. If a node errored, I’d find out only by checking the workflow manually. Added an automatic error alert path. Now if anything in any node fails, my phone tells me which node and what the error was. Failures are now a notification, not a silence.

The pattern across all three: production exposes gaps that testing misses. Real data is messier than test data. Real APIs are flakier than mocks. Real schedules trigger bursts that manual runs never would. Building the resilience layer is mostly defending against this kind of variability.

What this is really about

The blog is one experiment. There will be more.

The whole point of this project is to build with AI in public. To learn what works by shipping it. To see what surprises me when a system runs without my hands on it. Every fix this week taught me something I wouldn’t have learned by reading about autonomous content pipelines. Every surprise was a piece of knowledge that didn’t exist for me before I shipped.

That’s the work I want to be doing. Build the thing. Watch it run. Fix what breaks. Take notes. Build the next thing with everything you learned from this one.

If you missed Day 1, here’s how the whole pipeline got designed and built.

The blog itself is at kenashe.ai/blog. This newsletter is where the longer-form essays come out. Subscribe if you want to follow what comes next.

The live version is at kenashe.ai/blog. As I write this, the pipeline has been built end to end and tested manually. Day 2 is switching from manual to scheduled triggers and tuning the prompts based on what the first real batch of output looks like.

Below: the plan, the tools, what got built on Day 1, and where I hit a wall.

The plan

The goal is something every marketer should be paying attention to in 2026: a content engine that runs without me. Not “AI-assisted blog posts that I edit and publish.” Autonomous posts that go live without my fingers touching them, gated by quality controls that catch the bad ones before they ship.

Specifically:

• Monitor 10 curated YouTube channels in AI and digital marketing for new uploads

• Pull transcripts for new videos posted in the last 48 hours

• Identify the single best angle worth a 600 to 1000-word post (most videos don’t have one, reject those)

• Generate the post in my voice, structured for SEO, with frontmatter ready for Astro

• Score it on a 40-point rubric (originality, voice match, factual defensibility, reader value)

• Auto-publish if it passes, queue for review if it doesn’t

• Cap at 3 posts per day

• Notify me on every result so I can pull anything that slipped through

Why three a day, not ten or twenty? Google’s helpful content updates have been brutal to high-volume AI content that doesn’t add value beyond its sources. Three good posts daily for a month gives Google enough data to start ranking the domain. Three good plus seven mediocre gets the whole domain penalized. The cap is the SEO insurance policy.

The tools

I’m running four AI models plus a stack of services. Each has a specific job:

n8n is the orchestration layer. It’s a workflow automation tool similar to Zapier or Make, but more flexible and self-hostable. The entire pipeline lives as a single n8n workflow with 18 nodes. n8n calls the APIs, passes data between them, handles error states, and (starting today) runs on a schedule.

Claude Opus 4.7 (via the Anthropic API) is the writing engine. When I tested both Claude and GPT-5.5 against the same source material, Claude produced posts that read more like a real person and less like a press release. For long-form writing in a specific voice, it’s still the best.

Gemini 3.1 Pro does topic identification. This is the upstream filter that decides whether a video is worth writing about at all. Most videos aren’t. Gemini reads the transcript, identifies the single most interesting angle, scores it on novelty, search potential, and audience fit. If the angle scores below 21 out of 30, the workflow skips it and waits for the next video.

GPT-5.5 is the quality gate. After Claude writes a post, GPT-5.5 reviews it on a 40-point rubric and decides whether it ships or gets queued for human review. Using a different model for review than for writing is the key insight. Each model has different blind spots. The same model can’t reliably catch its own mistakes.

Supadata handles YouTube transcript extraction. Cheap, reliable, simple HTTP API. About half a cent per transcript.

GitHub and Vercel are the publishing pipeline. n8n commits new posts as Astro MDX files to my GitHub repo. Vercel detects the push and rebuilds the live site in about 90 seconds. The whole site auto-deploys with no manual step.

Telegram is where notifications land. Every published post and every queued draft pings my phone with the score, the reason, and a link to read or pull.

Worth mentioning: this site itself was built with Claude Code (and reviewed by Codex, OpenAI’s coding agent) over a weekend before this automation went on top of it. That’s the foundation the blog pipeline is committing into.

Day 1: what got built

Day 1 was about laying down the pipeline end to end. The full architecture went in: define channels, fetch RSS feeds, parse, extract latest videos, dedupe against history, check the daily cadence cap, fetch transcripts, score topics with Gemini, generate posts with Claude, gate with GPT-5.5, format as MDX with a date-prefixed slug, commit to GitHub, trigger Vercel, and ping me on Telegram.

Eighteen nodes in n8n. Most of the build time was on three things: getting the cross-node data references right (n8n’s expression syntax has gotchas, and node naming matters more than I expected), wiring up the API authentications for five different services, and debugging a stubborn 404 from GitHub that turned out to be a token scope issue rather than anything in my code.

The hardest single piece to get right was the slug generation. The original plan generated slugs from the post title alone, which would have caused GitHub collisions any time two posts had similar titles. I switched to a date-prefixed format like 2026-05-14-title-slug so collisions are functionally impossible. Two posts can’t share a slug across different days, and the daily cap prevents same-day collisions in practice.

By end of Day 1, the pipeline runs end-to-end on a manual trigger. New video → new post → on the live site within minutes. That’s the bones working.

The Claude usage cap, and the Gemini pivot

About halfway through the build, I hit Anthropic’s usage cap. I’d been using Claude as my pair-programming assistant for the whole build (separate from Claude Opus 4.7 as the writing engine inside the pipeline). The cap fired with a couple of hours of work left, and I was already paying for overage.

Two options at that point: keep paying for more overage, or pivot to a different assistant. I’d been wanting to test Gemini in a real working context anyway, so I switched mid-build. Gave Gemini the workflow JSON, the error messages, and asked it to help fix the remaining issues. Both models delivered. Different strengths, but the build kept moving.

Lesson: have a backup AI assistant configured before you need one. Not because any one of them is unreliable, but because hitting a usage cap mid-build is exactly when you don’t want to be configuring API keys for a new tool. The cost of having two assistants ready is roughly zero. The cost of being stuck is half a day.

Day 2: what’s left

A pipeline that only fires when I press a button isn’t autonomous. Day 2 is two things: switch the manual trigger to a scheduled trigger (every six hours), and tune the prompts based on actual output.

The prompts are the biggest lever in the whole system. Every time the first batch of posts has a phrase I wouldn’t write, that phrase goes into the banned list. Every time the gate misses something, the rubric gets tightened. After a week of tuning against real output, the system prompts will be twice as long as the Day 1 versions and the failure rate will be much lower.

The plan after Day 2 is to let it run for a week at three posts per day, watch the Search Console data, then decide whether to expand the channel set, raise the cadence cap, or add image generation. Anything I scale before seeing real ranking data is betting in the dark.

What this is proving

This whole project (building kenashe.ai with Claude Code and then this automation pipeline on top of it) is a real test of a real thesis. Application-layer AI work is no longer something only engineers can do. A digital marketer in 2026 who isn’t shipping AI-built systems is going to be outpaced by those who are.

The bar to entry isn’t the math. It isn’t the model weights. It isn’t the cost. It’s deciding that this is the work and putting in the hours. Twenty hours over a weekend gets you a custom site. Eight more hours gets you a blog that writes itself.

If you’re a marketer reading this and you’re not building, build.

Here’s how it came together.

Starting from scratch with Claude Code

I’ve been spending a lot of time in Claude Code lately, and I wanted to push past the daily email (which is still humming along on Substack) and build something new. So today I sat down to build a personal site from scratch. No templates. No themes. No Wix or Squarespace. Just me, the terminal, and Claude Code.

My prompt was simple: I want a minimal, editorial site with a link to my Substack newsletter, an automated AI blog (which I’ll wire up to n8n down the road), an about section, and a contact form. Clean. Quiet. Typography-first.

Claude Code spun up an Astro project with TypeScript, Tailwind, and MDX. It gave me back exactly what I asked for, plus one section I didn’t ask for: a Projects page meant to highlight what I’m building. I almost cut it, but then I realized: this site is the project I’m building right now. So it stays. I’ll fill it in as I go.

Total cost for the initial build: under $10 in Claude API credits.

Then I handed the code to Codex

Here’s the part I want to spend more time on, because I think this is the real unlock.

Once Claude Code had finished the initial build, I opened a second terminal window (same Mac, just another tab) and pointed OpenAI’s Codex at the same repo. Same code, different model, different review. I wanted a second AI to QA what the first AI had written.

Codex caught things Claude hadn’t flagged. One example: my homepage pulls the latest posts from Substack via their feed, with placeholder posts as a fallback in case the feed ever fails. Codex pointed out that those placeholders, “Placeholder essay one, Placeholder essay two, Placeholder essay three,” would render on the live site if Substack ever hiccupped. Not a great look. The fix was simple: gate the placeholders behind a development-only flag and show a proper empty state in production. Claude Code agreed and shipped the change.

That was one of eight fixes Codex flagged. Some were security-related, some were accessibility improvements, some were schema cleanups. All of them were issues I would never have caught on my own. And importantly, ones Claude hadn’t surfaced either.

That workflow, building with one model and reviewing with another, feels like something I’m going to keep doing. It’s the AI equivalent of getting a code review from a colleague who thinks slightly differently than you do. Next project, I might flip it: have Codex write the first draft and Claude Code review. I’m curious whether the strengths reverse.

For this build, I only did one review pass before shipping. I could’ve gone deeper, but it’s a simple static site. The real complexity will come when I start wiring the blog up to n8n for automated publishing.

Shipping it

Once the fixes were in, I committed to GitHub and connected the repo to Vercel. A few rounds of copy edits (bio, about section, headlines) and the site was live. The whole end-to-end process, from empty directory to public URL, took less than a day.

What I’m taking away from this

A few things stuck with me from this build:

• Watching the API meter run was eye-opening. We’ve been talking about the economics of AI-built products in one of my Maven classes, but seeing it line up in real time, under $10 to scaffold a real, deployable site, makes the math hit differently than any slide deck ever could.

• Running two coding agents side by side on a Mac was surprisingly seamless. Two terminal tabs, one building, one reviewing. No framework, no plugins, no fancy orchestration layer. Just two AIs, one repo, and me in the middle.

• Claude Code’s default design choices were more than serviceable. I went MVP just to stand the site up. Clean, restrained, no AI-startup gradient nonsense. I’ll loop back with Claude Design to push the visual layer further once the foundation is solid.

What’s next

This is the foundation, not the finished product. The big build is the AI blog: I’m planning to use n8n to scrape AI and digital marketing content from YouTube and other sources, generate posts, and publish them automatically to the new blog section. That’s where things get expensive. And that’s where things get interesting.

Go check out kenashe.ai, subscribe to the newsletter if you haven’t, and follow along. I’ll be sharing the n8n build next.

I’m on the Pro plan, and I’ve been keeping a close eye on my usage. If you didn’t know this (and a lot of people I talk to don’t), you can actually monitor your Claude usage in real time at claude.ai/settings/usage. I’ve been checking it constantly.

What the Usage Page Actually Shows

The page breaks your usage into three buckets, which is genuinely useful once you understand what you’re looking at:

• Current session limits, your rolling 5-hour window

• Weekly limits across all models, the broader ceiling that resets seven days after your session starts

• Claude Code plus additional features, a separate bucket that accounts for things like agentic runs

Right now my current daily limit is at 66% and my weekly limit is at 43%. Watching those numbers tick up in real time has actually changed how I prompt. I’m more deliberate. I start fresh chats more often instead of letting one giant thread balloon. Long threads burn tokens faster because Claude has to re-read the whole conversation every turn.

The “Extra Usage” Toggle

I’ve also turned on extra usage. This is the setting that lets you keep going after you hit your plan’s limit. Instead of stopping cold, you opt in to continue at standard API rates with a monthly spend cap you control.

I turned it on because I’m still on Pro and I’m not quite ready to jump to Max. Hitting a wall mid-session and having to wait it out kills momentum. Paying a little for overflow felt like the right tradeoff for now.

How I Balance Load Across Claude: Using the API for Claude Code

Here’s a strategy I’ve landed on that works well: I use the Claude API for Claude Code, separate from my Pro subscription.

Pro covers chat, Projects, and Cowork, all of which share the same usage pool. Claude Code is the heaviest token consumer in my workflow by a wide margin, so if I run it through the same Pro plan, it eats my limits before I’ve done anything else.

By routing Claude Code to the API and paying per-token, I keep all the other surfaces (chat, Projects, Cowork) running smoothly inside my Pro budget. Yes, the API is more expensive in the moment, but it means I’m not hitting walls across the entire Claude ecosystem just because I had one heavy coding session.

It’s basically load balancing for my own usage.

Tips to Stretch Your Tokens

A few habits I’ve picked up that genuinely help:

• Use Projects. This is my biggest one. I love Projects. They’re a great way to save context, build “experts” for specific topics, and store examples of the kind of output you want. Instead of pasting the same long context into every new chat, you set it once and Claude carries it forward. Massive token savings, plus way better answers.

• Start fresh chats more often. A long thread isn’t free. Claude re-reads the whole history every turn. When you’ve shifted topics, open a new conversation.

• Don’t paste the same document twice. If you’re going to reference it again, that’s what Projects are for.

• Use the right model for the job. Not everything needs the most powerful model. Routine reformatting, quick lookups, and simple Q&A don’t need to burn through your premium budget.

• Watch the usage page before big sessions. If you’re at 70% on a Tuesday, plan accordingly.

Why I Haven’t Upgraded to Max Yet

The honest reason - I already pay for a lot of AI tools.

• ChatGPT (OpenAI)

• Gemini

• Grok

• n8n

• ElevenLabs

• OpenRouter credits

Adding another $100 to $200 per month on top of all that has been a hard sell. For context, Claude Max comes in two tiers: Max 5x at $100/month (5x the usage of Pro) and Max 20x at $200/month (20x the usage of Pro).

What I Actually Use Each Tool For

I get asked this a lot, and the answer isn’t a clean one. Part of the reason I have all these subscriptions is that I genuinely want to try different things in each. But here’s how it’s shaken out in practice:

• Claude. Claude Code is where it really shines for me right now. That’s my main use case.

• ChatGPT. I find it very useful for Codex. Different strengths, different workflow.

• Gemini. This is my daily Q&A app on my phone. I’ve basically replaced Google search with Gemini. When I need to answer something on the go, I’m opening Gemini, not Google.

• Grok. I got access through X and don’t use it daily, but I find it refreshing when I want to dig into an area that other apps consider too sensitive or unethical to engage with. Grok doesn’t seem to have those concerns. If I hit a wall on another model, I immediately go to Grok and usually get a great answer.

• n8n and ElevenLabs. Totally different use cases (automation and voice respectively). These aren’t really “redundant” with the LLMs. Same will be true for Higgsfield once I add it.

Here’s the thing: the best models from all the major LLM providers are all very good at this point. In theory I could consolidate down to one. But I really don’t want to. I have legitimate use cases for each, and I find it genuinely powerful to have all of them at my disposal.

The Break-Even Math on Max

The math is actually pretty straightforward:

If you’re spending $20/month on Pro plus another $80 or more in extra usage (or API tokens), you should just get Max 5x at $100/month.

That’s exactly where I expect to land. I’m not there today because I bought a chunk of extra usage credits and I want to use those up first. Once I burn through them, I’m 100% switching to Max. Same dollars, fewer interruptions, no per-token accounting in my head.

The Real Cost of Hitting Limits

This is the part nobody talks about enough: the cost of hitting your limit isn’t dollars, it’s momentum.

When you’re deep in a project and Claude tells you to come back in three hours, you don’t just lose those three hours. You lose the mental state you were in. You lose the thread of where you were going. You come back to a project that’s gone cold, and you have to rebuild context for yourself, not just for the model.

This is literally why I bought extra usage credits. Not because I couldn’t afford to wait, but because I couldn’t afford to context-switch. Stopping mid-thought to deal with a usage wall is way more expensive than the $20 or $50 of overflow tokens that would have kept me moving.

If you’re using Claude for real work, that’s the number that should drive your decision, not the sticker price of Max.

Still on the Roadmap

I don’t pay for Higgsfield yet, but that’s the next service on my list to evaluate.

If you’re using Claude more than casually, bookmark the usage page. It’s the difference between guessing what your workflow costs and actually knowing.

What I tried to build

A daily personal email, sent to me every morning at 6 AM, that includes:

• The day’s forecast

• A dad joke

• A few stock tickers

• 300–400 words on a topic that rotates by day of the week

The seven topics:

1. Stoic philosophy

2. Meditation and mindfulness

3. Nutrition

4. Communication skills

5. Humor

6. Golf tips for a scratch golfer

7. AI learning tips

How I accessed Claude Code

There are a few ways to use Claude Code. The two easiest are the terminal on a Mac, or the Claude desktop app.

I went with the terminal for two reasons:

1. It’s native to macOS, so it’s fast and plays nicely with the rest of my system.

2. I’m not locked into the Claude app. I can use the terminal with Codex or any other major LLM coding agent.

What went well

Building the daily email with Claude Code was surprisingly straightforward. I bounced between Claude Code in the terminal and Claude in the desktop app to think through the design, then let Claude Code actually write the thing.

The solution it landed on was a Python script that runs locally on my Mac Mini and fires at 6 AM each day. I:

• Set up a dedicated email address for Claude Code to send from

• Hooked up APIs for weather and stock tickers

• Let Claude generate the 300–400 word section based on the day of the week

I tested it manually. The email fired. The right topic showed up for the right day. The dad joke even landed:

Did you hear the joke about the wandering nun? She was a roaming catholic.

Looked good.

Where it failed

The next morning I woke up at 6, checked my inbox… nothing.

It turned out the original setup didn’t have the right macOS permissions to run the script on its own at that time. Not something I could have caught in a manual test, as it only failed when it had to fire on a schedule, unattended.

The solution

I went back to Claude in the desktop app, told it the email never showed up, and walked through possibilities. The fix was to remove the cron job and replace it with a launchd agent.

I’ll be honest: I don’t know the deep technical difference between those two, and at this stage I don’t really need to. I made the changes Claude suggested, and the next morning at 6 AM the email landed in my inbox.

How long did this take?

About three hours, all in.

That sounds like a lot for something this simple, and it would have been much faster, except:

• I was deliberately going slowly - reading the Python scripts Claude Code wrote and making sure I actually understood what was happening, instead of just rubber-stamping it.

• I had to set up a fresh email account from scratch for this project.

• That fresh account got me into trouble with Google. I was firing so many test emails from a brand-new sender that Google flagged it, and not in the normal “check your spam folder” way. The emails were hidden from my personal inbox entirely, not even visible in spam. Took some troubleshooting to figure out what was happening.

• The three hours also covers the next morning’s debugging when the 6 AM run didn’t fire.

For three hours of work, what I got was a thing that runs on its own every day, forever. That math feels pretty good.

Then it failed again

A few days later, 6 AM came and went. No email.

This time the problem wasn’t permissions. It was fragility. The weather API I was pulling from happened to be down that morning. My Python script tried to fetch the forecast, the call failed, and the entire email failed with it. One missing piece took down the whole thing.

I went back to Claude Code, described what happened, and asked it to diagnose. It walked through exactly what had gone wrong and proposed a fix: instead of letting a single failed API call crash the script, the weather fetch now fails gracefully. If the API is down, the email still goes out, just without that day’s forecast.

The bigger lesson is one I think every first-time builder runs into: making something work is one problem; making something resilient is a different one. The first version of this assumed every API call would succeed. The second version doesn’t.

What I’d do next

Getting a daily newsletter written by me, for me, is genuinely cool. I’m going to keep iterating:

• Add more tickers

• Rotate or expand the daily topics

• Maybe add a comic strip if I can find one I like

After the weather API outage, the QA idea I’d been kicking around feels less optional. The plan is to run this project through Codex as a code review pass — point a second coding agent at what Claude built and see what fragility it catches. Claude builds, Codex reviews, or vice versa. Both failures so far were ones I could only catch at runtime; a second set of eyes might surface the next one before it bites.

Final thought

I can’t speak to the quality of the underlying code or whatever tech debt I might be racking up. But for a first build, at my level of experience, the bar was simple: does it work?

It does. And that feels like a real unlock.

Not on AI engineering. That’s not where I’m headed.

In her book AI Engineering, Chip Huyen describes the AI engineering stack as having three layers: application development, model development, and infrastructure. I’m focused on the top layer, application development. That’s the part anybody can do today, using the models that already exist. It’s about giving a model good prompts and the right context to produce real, usable results.

And honestly, that’s what makes this moment so exciting. You don’t need to train models or build infrastructure to create something useful. Anybody can pick up the tools and start building. That’s the part I plan to live in.

The space is moving fast. I believe we’re heading toward a future where everyone will need to know how to leverage AI, and I’d rather be early than have to catch up later.

The plan: 20 hours a week, 8 weeks

For the next eight weeks, I’m dedicating 20 hours a week to AI, with a deliberate balance.

The priority is building. Most of that time goes into actually using the tools, shipping projects, breaking things, and iterating. That’s where the real learning happens.

Alongside the building, I’m doing two things to keep the foundation solid:

• Taking a class (more on that below)

• Reading AI Engineering by Chip Huyen

The reading and the class are supplemental, but they’re not optional. Building without context produces shallow skills; theory without building produces no skills at all. I want both.

I’m also fortunate to be at a point in my business where I can step back briefly and invest this kind of time into developing new skills. That window doesn’t come around often, and I don’t want to waste it.

Why I’m documenting it here

I’m going to document the entire process on this Substack: the wins, the failures, the projects, and the lessons along the way.

Two reasons for that:

1. Sharing the journey. If anything I do here helps someone else figure out their own path into building with AI, that’s a great outcome.

2. Solidifying my learning. Writing forces me to slow down, review what I did, and actually understand it. The act of documenting is part of the learning itself.

Where I’m starting from

I’m not starting at zero. I’ve been prompting AI extensively for a while now (from work projects to planning vacations), and I’ve taken a couple structured AI courses through Maven, which has been my go-to platform for this kind of learning.

So far, I’ve completed two Maven certifications:

• AI Prototyping for Product Managers

• How to Scale a Business With Agentic Workflows (by AI Build Lab)

  

  

And I’m currently in the middle of:

• Course: OpenClaw & Claude Code Certification for AI-Native PMs (by AI Product Academy, taught by Dmitry Shapiro and Dr. Marily Nika)

• Book: AI Engineering by Chip Huyen

Honestly, it’s this third class that pushed me from “I should really do this” to “I’m doing this now.” The combination of OpenClaw and Claude Code is opening my eyes to what’s possible when you can actually design, build, and ship AI agents without being a traditional engineer. I want to spend serious time exploring it.

What’s next

I’ll be posting regularly here as the sprint unfolds. I’ll also be sharing progress on LinkedIn and X along the way.