In this issue:

--- Claude can now work while you don't ---

Here is a feature most people building with AI have not noticed yet: Claude can now run tasks on a schedule, on its own, without you starting them.

It is called Scheduled Tasks, and it lives inside Cowork — Claude's desktop app for non-coders, the one with no terminal and no code. You describe a job once: "Every Monday at 8am, check my calendar and Slack, and write me a brief on what matters this week." Claude saves it and runs it on that cadence, delivering a finished output every time. A morning briefing, a weekly report, recurring research on a competitor. You set it up in under a minute by typing /schedule.

A few months ago, this kind of automation meant APIs, scripts, and connecting services — work that put it firmly out of reach for a non-coder. Now you describe what you want in plain language, and it runs itself.

One honest catch, and it is a real one: the task only runs while your computer is awake and the Claude Desktop app is open. If your laptop is closed when 8am comes, the job waits until you open it again. Anthropic has a cloud version in preview called Routines that runs even with your laptop shut, but it is not generally available yet. For now, treat Scheduled Tasks as a very capable assistant who only works when the office lights are on.

Still — this is the first time "set it and forget it" automation is genuinely within reach for someone who has never written a line of code. That is worth your attention.

--- Lovable ships Skills ---

Lovable shipped a feature called Skills. Small, quiet, useful.

Every new chat in Lovable, you re-paste the same context. Your color palette, your tone rules, your QA checklist. It is friction you absorb because there is (was) no way around it.

A Skill is a plain Markdown file that Lovable picks up on its own when it is relevant to the task. You write it once. Lovable reads it whenever the task fits. The format is the same one Anthropic introduced for Claude, and Lovable says the file works in Claude and OpenAI too. One file, three tools.

If you have ever briefed a freelancer the same way ten times, you already understand the entire value of this feature.

"Steal from the best": there is a public repo of Andrej Karpathy's guidelines for AI coding agents. It is one file, and it does one thing well — it tells your AI to surface its assumptions instead of guessing, keep its code minimal, make surgical edits rather than sweeping ones, and define what "done" actually looks like before it starts. Drop it into Lovable, set the trigger to "Use when writing, reviewing, or refactoring code," and you have your first Skill without writing a word of it yourself.

--- Biron Clark and the 365-day bug ---

Biron Clark spent ten years in digital marketing and SEO. He built every website of his career in WordPress. He is not a developer, and he does not pretend to be one.

A few months ago, partly out of curiosity and partly because WordPress was no longer the right shape for what he wanted to build next, he tried vibe-coding instead. What came out is called Insider Hawk: a single-page app that pulls insider and politician stock trades from the SEC's public Form 4 filings.

The premise is simple. Corporate insiders and politicians often trade on information the public cannot see. The SEC requires them to file those trades publicly, but only after the fact. Insider Hawk reads the filings and shows you, in plain view, what informed money is doing.

He tried Cursor and VS Code first, found them "cumbersome," and switched to Lovable. He used Supabase for the database. Standard non-coder stack.

What is interesting is not that he built it. What is interesting is what he caught when it was almost done.

Biron asked the tool to grade politicians' trading records based on the last 365 days. It did the work, and it even wrote the tooltip text — the little description visitors see on the page — confirming that the rating was based on 365 days. Then Biron opened the finished version, noticed Nancy Pelosi had a one-star rating, knew her reputation, sensed something was off, and went digging.

The tooltip said 365 days. The code said 30. As Biron put it: "The actual code was only looking at 30 days, not 365."

This is the part of working with AI tools nobody warns you about: AI will confidently document features it did not actually build. Not maliciously. It generates the explanation that sounds right next to the code that seemed reasonable, and those two things do not always agree. The only reason Biron caught it was domain knowledge — he knew Pelosi's reputation, the score did not match, he investigated.

If he had not been paying attention, that bug would have shipped. On a site that publicly grades politicians' trades, that is the kind of bug that ends up in a screenshot with your name on it.

The interesting question is not "how do I get AI to write code without bugs" — that is not a solvable problem at this stage of the technology. The interesting question is "what is my verification routine, and is it good enough to catch the bugs that will happen?" Biron's routine was that he knew his domain. Yours had better be at least as good.

Read Biron's full write-up

--- Software is layers ---

Aron taught me this one a few weeks ago and I have not stopped thinking about it. If you take one thing from this email, take this:

Software is layers, and bugs hide at the boundaries between them.

Every piece of software you have ever used is a stack of layers. The top is what you see. The bottom is the actual hardware sitting in a data center somewhere. Everything between is software talking to other software, each layer hiding the complexity of the one below it. That hiding is the entire reason any of this works.

The bug is almost never inside a layer. The bug is at the seam, where one layer hands off to the next. Biron's 365-day bug? Classic boundary problem. The tooltip layer said one thing. The query layer said another. They did not agree, and nobody noticed until the output looked wrong.

This matters because AI tools generate code at every layer at once, and they are not always careful at the joints. Inside any one layer, they tend to be fine. At the seams, the weird stuff lives. If you know the layers exist, you know where to look. If you do not, you scroll and you hope.

Try this tonight. Open your project in Cursor, Claude Code etc. chat and ask:

The answer is the map you have been missing. And the places where the answer gets fuzzy? That is where your next bug is going to live.

That is it for this week. If something here was useful, hit reply and tell me which one. The next issue gets better because of Your feedback.

See you next Tuesday,

Aaron