Planet Cloudflare

A minimal, AI-agent-friendly starter for building full-stack apps on Cloudflare Workers with TanStack Start.

Built with Workers, D1, and R2.

GitHub

CopilotKit が提唱する Generative UI Spectrum の 3 バンド (Controlled / Declarative / Open-Ended) を、同一題材「レストラン提案」で並べて見せるデモ。

Built with Workers, Durable Objects, Workers AI, and Agents.

GitHub

Swarmflare is a Cloudflare-native demo of an AI chat agent that can split broad goals into a bounded swarm of specialist workers, run those workers in parallel, track progress live in the browser, and synthesize a final answer.

Built with Workers, Durable Objects, Workers AI, and Agents.

GitHub

Constituent Bridge is a multilingual smart inbox demo for Members of the European Parliament.

Built with Workers, Durable Objects, Workers AI, Email Workers, and Agents.

GitHub

The cloud backend for Screendrop, an open-source native macOS screenshot tool. This worker handles uploading, storing, and sharing screenshots and screen recordings via shareable links.

Built with Workers, D1, and R2.

GitHub

🧑‍🚀 Seasoned astronaut? Delete this file. Have fun!

Built with Workers.

GitHub

AI photo editing in your browser.

Built with Workers and Durable Objects.

GitHub

Lempicka is a Cloudflare Worker that turns uploaded photos into portraits inspired by Tamara de Lempicka. It serves a small web app, sends images to Replicate for image-to-image generation, and keeps a short-lived gallery of recent results in Cloudflare KV.

Built with Workers and KV.

GitHub

A personal, curated collection of skills — small, focused Markdown documents that describe how to do specific things with specific tools. Designed to be consumed by coding agents (Claude Code, Cursor, etc.) and by humans.

Built with Workers.

GitHub

Built with Workers.

GitHub

Studio-grade voice cleanup, in your browser.

Built with Workers, D1, R2, Queues, and Email Workers.

GitHub

Built with Workers and Cloudflare Images.

GitHub

Built with Workers, D1, KV, R2, Durable Objects, Workflows, Workers AI, Cloudflare Images, Email Workers, and Analytics Engine.

GitHub

Built with Workers, D1, KV, R2, Durable Objects, Workflows, Workers AI, Cloudflare Images, Email Workers, and Analytics Engine.

GitHub

This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.

Built with Workers.

GitHub

A minimal Cloudflare Worker built with FastAPI and Python. It greets you. That's it. No spam.

Built with Workers.

GitHub

A carnival water gun game built with Python Workers and Durable Objects on Cloudflare. Perfect for conference booths!

Built with Workers and Durable Objects.

GitHub

See your landing page through a first-time visitor's eyes. Paste a URL, describe what visitors should walk away knowing, and get an honest AI-generated read on whether the page actually delivers that message.

Built with Workers, KV, Workers AI, and Browser Run.

GitHub

MaintainerBot is a Flue project for daily maintenance of Adewale's open-source projects.

Built with Workers, R2, Email Workers, and Agents.

GitHub

The cloud backend for Screendrop, an open-source native macOS screenshot tool. This worker handles uploading, storing, and sharing screenshots and screen recordings via shareable links.

Built with Workers, D1, and R2.

GitHub

Python By Example is a Go By Example-inspired learning site for Python 3.13. It presents small literate examples with prose, source fragments, expected output, official Python documentation links, and an editable runner.

Built with Workers.

GitHub

A starter template for building AI chat agents on Cloudflare, powered by the Agents SDK.

Built with Workers, Durable Objects, Workers AI, Email Workers, and Agents.

GitHub

A Cloudflare Python Worker that turns photos into delightfully terrible MS Paint-style drawings using OpenAI's GPT-Image-2 via AI Gateway.

Built with Workers, KV, R2, Workflows, and Workers AI.

GitHub

A self-hosted morning dashboard for the GitHub work that needs your attention.

Built with Workers, D1, and Queues.

GitHub

A self-hosted morning dashboard for the GitHub work that needs your attention.

Built with Workers, D1, and Queues.

GitHub

A free, self-paced course for learning OpenCode, the open-source AI agent.

Built with Workers, KV, and R2.

GitHub

Turn boring company status pages into hilarious AI-generated songs.

Built with Workers, R2, Durable Objects, Workflows, Workers AI, Browser Run, and Agents.

GitHub

Welcome to the open-source repository for all Cloudflare Developer Documentation.

Built with Workers and R2.

GitHub · Live

Built with Workers and Durable Objects.

GitHub

A deep-research agent for Cloudflare Workers. Email a question or open the chat — it searches the web in a real headless Chrome, reads promising sources, captures structured data or screenshots, and replies with a cited Markdown / HTML report.

Built with Workers, Durable Objects, Workers AI, Browser Run, Email Workers, and Agents.

GitHub

Collaborative video review, built on Cloudflare. Upload up to 5GB, stack new versions, share a link, and collect timestamped feedback from your team or clients — no account required for reviewers.

Built with Workers, D1, Durable Objects, Workflows, Workers AI, and Email Workers.

GitHub

Welcome to your new TanStack Start app!

Built with Workers and D1.

GitHub

For generating/synchronizing types based on your Worker configuration run:

Built with Workers.

GitHub

A template for building interactive, agent-driven schools on any topic.

Built with Workers and KV.

GitHub

Built with Workers, Durable Objects, Workers AI, and Agents.

GitHub

A voice-powered customer support agent built on Cloudflare Workers using the experimental @cloudflare/voice SDK. Users speak to the agent in the browser and it responds with natural speech, backed by Workers AI for STT, LLM, and TTS.

Built with Workers, Durable Objects, Workers AI, Voice, and Agents.

GitHub

Internal tool for managing the Cloudflare for Startups credit program. Startups apply for Cloudflare credits through a multi-step wizard, and an automated verification pipeline scores and triages applications for the team.

Built with Workers, D1, Workers AI, and Email Workers.

GitHub

Workshop: Build an AI email agent with Cloudflare Agents SDK and Email Routing.

Built with Workers, Durable Objects, Workers AI, and Agents.

GitHub

This template provides a minimal setup for building a React application with TypeScript and Vite, designed to run on Cloudflare Workers. It features hot module replacement, ESLint integration, and the flexibility of Workers deployments.

Built with Workers and D1.

GitHub

demoscene is a Cloudflare Worker that scans a curated set of GitHub accounts and publishes a reverse-chronological feed of public Cloudflare projects from the Cloudflare DevRel team.

Built with Workers, D1, and Queues.

GitHub

A tiny Cloudflare Worker that takes user feedback over HTTP, drops it on a Cloudflare Queue, and uses the consumer batch to create a single Anthropic Message Batch job. A cron trigger polls Anthropic for results and writes them back to D1.

Built with Workers, D1, and Queues.

GitHub

A self-hosted email client with an AI agent, running entirely on Cloudflare Workers

Built with Workers, R2, Durable Objects, Workers AI, Email Workers, and Agents.

GitHub

Agent-first static website and skill repository for Cloudflare Workers-style design tokens, reference docs, and reusable UI guidance.

Built with Workers.

GitHub

Cloudflare booth demo built around the Agents Never Sleep sticker robot.

Built with Workers, D1, R2, Durable Objects, Workers AI, Voice, and Agents.

GitHub

A 3D endless-runner racing game built entirely on the Cloudflare developer platform. No origin servers, no external services -- Workers, AI, D1, Durable Objects, and Dynamic Workers running at the edge.

Built with Workers, D1, Durable Objects, and Workers AI.

GitHub

A self-hosted email client with an AI agent, running entirely on Cloudflare Workers

Built with Workers, R2, Durable Objects, Workers AI, Browser Run, Email Workers, and Agents.

GitHub

A self-hosted email client with an AI agent, running entirely on Cloudflare Workers

Built with Workers, R2, Durable Objects, Workers AI, Email Workers, and Agents.

GitHub

🧑‍🚀 Seasoned astronaut? Delete this file. Have fun!

Built with Workers, Workers AI, and Browser Run.

GitHub

A demo app built with React + Cloudflare Workers showing how to send and receive emails using Cloudflare Email Service, with Workers AI (Gemma 4) triaging inbound emails.

Built with Workers, Workers AI, and Email Workers.

GitHub

A personal knowledge base powered by AI with hybrid search capabilities. Built with Cloudflare Workers, AI Search, and the Agents SDK.

Built with Workers, Durable Objects, Workers AI, Voice, and Agents.

GitHub

A free, self-paced course for learning OpenCode, the open-source AI agent.

Built with Workers, KV, and R2.

GitHub

Built with Workers, Durable Objects, and Workers AI.

GitHub

BookWorm is an educational demo for Cloudflare's Think-style agents. Each reader enters their name on the home page, which opens a dedicated long-running agent instance with a durable bookshelf, reminder scheduling, Open Library metadata, and chat-installed Think extensions.

Built with Workers, R2, Durable Objects, Workers AI, Sandboxes, and Agents.

GitHub · Live

On April 13, 2026, I held "Cloudflare Workers Tech Talks in Tokyo #7". The event took place in the evening at the LayerX event space in Higashi-Ginza, Tokyo. About 70 people attended, making it one of the largest Workers Tech Talks events yet.

What is Cloudflare Workers Tech Talks?

Cloudflare Workers Tech Talks is an event where developers who are developing using Cloudflare Workers talk about Cloudflare Workers. It has been held multiple times in Tokyo, Osaka, Kyoto, Niigata, Hokkaido, and Fukuoka. At the end of last year, we also held the first event in Austin, Texas! The feature of this event is that the speakers are free to talk about whatever they want. I often tell the speakers, "Please don't give introductions like 'What is Cloudflare Workers?'". I ask them to talk about whatever they want to talk about.

• Cloudflare Workers Tech Talks in Tokyo #1
• Cloudflare Workers Tech Talks in Tokyo #2
• Cloudflare Workers Tech Talks in Osaka #1
• Cloudflare Workers Tech Talks in Tokyo #3
• Cloudflare Workers Tech Talks in Tokyo #4
• Cloudflare Workers Tech Talks in Osaka #2
• Cloudflare Workers Tech Talks in Tokyo #5
• Cloudflare Workers Tech Talks in Kyoto #1
• Cloudflare Workers Tech Talks in Niigata #1
• Cloudflare Workers Tech Talks in Hokkaido #1
• Cloudflare Workers Tech Talks in Fukuoka #1
• Cloudflare Workers Tech Talks in Tokyo #6
• Cloudflare Workers Tech Talks in Austin #1

Venue

The venue was LayerX event space, located at Ginza Shochiku Building 5F in Higashi-Ginza, Tokyo. Thank you to LayerX for providing the venue!

Attendees

We recruited attendees via the following connpass site.

https://workers-tech.connpass.com/event/387081/

We had 87 registrations with about 70 people attending the event.

Talks

We had seven talks covering a wide range of topics.

Why Was the "Introduction to Cloudflare Workers" Book Created?

syumai talked about the story behind the creation of "Web開発者のための［入門］Cloudflare Workers", a book he co-authored with Monica, おじさん, and one other author. Three of the four authors were speakers at this event! He shared not only what made it into the book, but also what he wanted to include but couldn't. We also did a janken (rock-paper-scissors) session and gave away the book to the winner. Congratulations to syumai and the other authors on completing the book!

The slides: https://speakerdeck.com/syumai/how-cloudflare-workers-book-written

Durable Objects 2026

Monica, one of the co-authors of the "Web開発者のための［入門］Cloudflare Workers" book, gave a definitive talk on Durable Objects. She traced the evolution of Durable Objects from its inception to the present day, covering all the features that have been added along the way. It was truly the ultimate guide to Durable Objects.

Why Choose Rust for Cloudflare Workers?

おじさん, also a co-author of the "Web開発者のための［入門］Cloudflare Workers" book, talked about the reasons for choosing Rust with Cloudflare Workers. He discussed how using Rust can speed up CPU-heavy processing, making a compelling case for when and why Rust is a good fit for Workers.

Publishing Lab Services with Cloudflare Workers

Taiki Nakaoka talked about building some of Hatena's Hatelabo services using Cloudflare Workers. It was interesting to hear how a well-known company like Hatena is adopting Workers for their lab services.

The Technology Behind the Aizu University School Festival

しゃけのきりみ。 came all the way from Aizu, which is far from Tokyo, to give this talk. As a university student, he built the systems for the Aizu University school festival entirely on the Cloudflare stack — including equipment management and a link management system for the festival. It was impressive to see how a student leveraged Cloudflare's full platform to power a real-world event.

Playing Pokemon Cards Remotely on Discord Led Me to Run Durable Objects for 25 Minutes

Kaito Udagawa talked about building a timer for Discord voice channels using Durable Objects, born out of his experience playing Pokemon card games remotely on Discord. He showed a video demo of the system in action.

The slides: https://speakerdeck.com/umireon/discordderimotopokekasitetara-nazekadowo25fen-jian-dong-kaseruyouninatutahua

AI Coding for Internal Tools at Cloudflare

Robert from Cloudflare presented about building various internal tools using AI coding — notably, he's not an engineer! He demoed a business card reading app that combines OCR and LLM for accurate results. It was inspiring to see how AI coding enables non-engineers to build practical applications on the Cloudflare stack.

Networking

After the talks, we had pizza and drinks. Thank you to LayerX for sponsoring the drinks!

Feedback

I asked the attendees to post on X with the hashtag #workers_tech. You can see the results below.

https://x.com/search?q=%23workers_tech

Summary

Workers Tech Talks in Tokyo #7 was the biggest Tokyo event yet with about 70 attendees. It's been about two and a half years since I started Workers Tech Talks, and I can definitely feel that the number of people who have experience using Workers has grown significantly since then.

Thank you to LayerX for providing the venue and sponsoring the drinks, all seven speakers for sharing their knowledge, and all the attendees who joined us. Thank you to everyone who made this event possible!

zeke/colorize

Cloudflare: Workers, R2

Colorize

A web app that colorizes black-and-white photos using the DDColor model on Replicate. Built on Cloudflare Workers with Hono.

Drop one or many images onto the browser and they get colorized in parallel. Results are stored in R2 and can be downloaded individually or as a zip.

GitHub · Live

Search every issue of The FLUX Review newsletter. Hybrid lexical + semantic search across all issues of The FLUX Review (published weekly since 2021), deployed as a single Cloudflare Worker.

Built with Workers, D1, Queues, Vectorize, and Workers AI.

GitHub · Live

A searchable, browsable archive of Alex Komoroske's Bits and Bobs weekly observations. Built on Cloudflare Workers.

Built with Workers, D1, Queues, Vectorize, and Workers AI.

GitHub · Live

This is a template for a new TanStack Start project with React, TypeScript, and shadcn/ui.

Built with Workers.

GitHub

Take a selfie, get four genuine compliments -- powered by Gemma 4 vision on Cloudflare Workers AI.

Built with Workers and Workers AI.

GitHub

The classic Windows Solitaire bouncing card win animation, recreated as a web page.

Built with Workers.

GitHub

Drop a product photo. Get a 30-second commercial jingle made with Google's Lyria 3 on Replicate, hosted entirely on Cloudflare.

Built with Workers, D1, KV, and R2.

GitHub

A demo app for the "Run Code That Writes Itself" video.

Built with Workers, KV, Durable Objects, and Workers AI.

GitHub

A game jam demo for showcasing Cloudflare Dynamic Workers as a primitive for running AI-generated code instantly in secure, isolated sandboxes.

Built with Workers, D1, Durable Objects, Workers AI, and Agents.

GitHub

A simple, self-hosted analytics dashboard for Cloudflare Web Analytics. Runs on Cloudflare Workers.

Built with Workers.

GitHub

A simple, self-hosted analytics dashboard for Cloudflare Web Analytics. Runs on Cloudflare Workers.

Built with Workers.

GitHub

A simple, self-hosted analytics dashboard for Cloudflare Web Analytics. Runs on Cloudflare Workers.

Built with Workers.

GitHub

A project management chat app where the LLM writes and executes code to orchestrate tools, instead of calling them one at a time. Built with @cloudflare/codemode and @cloudflare/ai-chat.

Built with Workers, Durable Objects, Workers AI, and Agents.

GitHub

Write, bundle, and run Cloudflare Worker code at runtime using @cloudflare/worker-bundler and Dynamic Worker Loaders.

Built with Workers, Durable Objects, and Agents.

GitHub

Write, bundle, and run Cloudflare Worker code at runtime using @cloudflare/worker-bundler and Dynamic Worker Loaders.

Built with Workers and Durable Objects.

GitHub

Small REST-first todo platform on Cloudflare Workers + D1 with Drizzle ORM and a lightweight TypeScript CLI.

Built with Workers and D1.

GitHub · Live

Planet Cloudflare is an old-fashioned RSS/Atom aggregator for blogs from Cloudflare employees and the wider Cloudflare community. It's motivated both by my love of Python and my nostalgia for the good old days of blogging.

But more importantly it's a long term demo of Python Workers. They are (as of March 2026) still in beta but this demonstrates their ability to integrate with the rest of the Cloudflare platform in a production environment. I'm also hoping this exemplifies how Python Workers can bring the advantages of the Cloudflare platform (low cost, high scalability and a wide variety of interesting services) to Python developers.

The implementation itself is relatively simple. It's an instance of Planet CF which is an open source RSS/Atom aggregator that supports all the usual features (responsible web fetching, liberal feedparsing via Feedparser and themes) people expect from Planet-style aggregators. It uses Cloudflare's Cron Trigger service to trigger the fetching of all the feeds once an hour. Since the number of feeds is potentially very large I enqueue each feed separately so that I have a separate worker to fetch each one. This has the benefit that I never have to worry about how many feeds are in the system.

The architecture is relatively simple. This simplicity supports a departure from the usual architecture of Planet-style aggregators. I store every blog post in D1 then provide both full-text search (using SQLite's BM25 algorithm) and vector search (based on Cloudflare's Vectorize). I then combine and re-rank the results so that you get a search engine that provides the results you expect when you type literal strings as well as handling synonyms. I'll be writing more in the future about how to combine indices to cheaply provide sophisticated search features.

Over time I expect to see this instance grow as I add more bloggers. Ideally this might even encourage more people to come back to blogging.

An MCP server built with Hono that provides search and retrieval of Hono documentation.

Built with Workers.

GitHub

Chat with your documents. Upload PDFs, ask questions, and get AI-generated answers grounded in your document content.

Built with Workers, R2, Durable Objects, Workers AI, Containers, Sandboxes, and Agents.

GitHub

For generating/synchronizing types based on your Worker configuration run:

Built with Workers, D1, and R2.

GitHub

I built Pika because, honestly, I wanted to build a Mac App, and it was the pandemic. An ocean of time and a laptop. I'm also a designer, and I liked the idea of doing something around accessibility. Picking a color off the screen should be dead simple.

So I built Pika.

The thing about tools

There's a version of this where I talk about Pika's features - the WCAG contrast checking, the color name lookup, the keyboard shortcuts, the Raycast integration. And those things are genuinely useful. But that's not the interesting part.

The interesting part is how painful making it was. I spent hours googling, reading documentation, and trying to figure out how to do things in SwiftUI and AppKit and XCodde that should be straightforward but weren't. The friction was exhausting.

When you stop thinking about how to do the thing, you start thinking about what you're doing. And that shift - from process to purpose - is where creativity lives.

Coding with AI, and what it changed

Shipping a macOS app has a lot of overhead. You build, you archive, you sign, you notarize, you wait, you create a DMG, you generate delta updates, you write release notes, you update the Sparkle feed, you push to GitHub, and then you do it all again for the Mac App Store target. It's not hard, exactly. It's just a lot of steps that aren't the interesting part.

I'd been using Claude Code for a while, and at some point I had this thought - what if I built a workspace that could handle all of that for me?

So I set up a monorepo that pulls together the Pika source, a release tool I built called releasecast, the marketing assets, and the website. Then I wrote Claude Code slash commands - /release, /screenshots, /setup - that orchestrate the whole thing.

The /release command handles the full pipeline. Build, notarize, create the DMG, generate the appcast, push to GitHub Releases, write the changelog, deploy the website. One command. What used to be an afternoon of careful copy-pasting and waiting for notarization emails turned into something I could kick off and walk away from.

But the screenshots were the thing that really surprised me.

I'd been putting off updating Pika's marketing assets for months. Taking screenshots of a color picker means getting the right colors on screen, the right window positions, the right appearance mode - light and dark - and then doing it all over again for the website, the README, and the App Store. It's fiddly, repetitive, and easy to get wrong.

I added a pika:// URL scheme to the app so it could be configured programmatically - set the foreground color, the background color, pick which window to show. Then I built a pipeline that launches Pika, triggers each shot configuration, captures the windows, and composites them into the layouts I need. Fan layouts for the website. Overlapping windows for the README. Clean PNGs for Figma.

The whole thing took a couple hours to build. And now updating the screenshots for a new release takes about thirty seconds, automatically.

That's the part that changed something for me. Not the time saved, exactly - although that's real. It's that the tedious stuff stopped being a reason not to ship. Every release used to come with this mental tax of all the boring work I'd need to do after the fun part was done. Now the boring part is automated, and I get to stay in the fun part longer.

Reigniting the thing

I've been making things since I was a kid. Side projects, experiments, things that have no business case and no roadmap. Pika is one of those.

But there's this thing that happens with side projects where the gap between what you want to build and what you can actually ship keeps growing. You get better at knowing what good looks like, and worse at finding the time to get there. The ideas don't stop, but the energy to push through the last 20% does.

What changed for me was the combination of AI and a willingness to experiment with how I work. Not just using AI to write code - although that's part of it - but using it to rethink which parts of the process need me and which parts don't. The color accuracy improvements, the OKLCH decimal precision, fixing Xcode build issues - I could describe the problem, work through it collaboratively, and ship the fix in a fraction of the time it would have taken me alone.

And that freed up space for the parts that actually need a human. The product decisions. The feel of the interactions. Whether a feature is worth adding at all.

There's a specific feeling when someone you've never met finds your little tool useful. A tweet you didn't ask for or an email from someone who uses Pika every day. Small tools accrue meaning over time in a way that's hard to predict and impossible to plan for.

That feeling is what keeps you making things. And anything that shortens the path from idea to shipped - anything that removes a reason to procrastinate - is worth its weight in gold.

What's next

Pika does a lot. It also doesn't do some things I want it to do yet.

Palettes just landed in beta - saving and organizing groups of colors, not just individual picks. There's more coming after that. I'm not sure exactly what shape it'll take, but that's the fun part.

It's a lot easier to be excited about what's next when shipping doesn't feel like a chore.

The tools we build reflect how we want to work. I want to work fast, stay focused, and spend more time on the parts that require a human.

So yeah, that's it. That's the automation manifesto, I guess.

A Cloudflare Worker that acts as a transparent reverse proxy with payment-gated access using the Machine Payments Protocol and stateless cookie-based authentication.

Built with Workers.

GitHub

A slide deck for Cloudflare Workers training, built with React and deployed on Cloudflare Workers.

Built with Workers.

GitHub

Render Mermaid diagrams as beautiful SVGs or ASCII art

Built with Workers and Pages.

GitHub · Live

See what dates the sunset aligns with any street grid on Earth.

Built with Workers.

GitHub · Live

Slop creep is the slow, invisible enshittification of a codebase through an accumulation of individually reasonable but collectively destructive decisions, each one too small to flag, too numerous to track, and too deeply buried to unwind by the time you notice.

Picture a codebase six months from now. Every feature shipped on time, every PR passed review. But the team is slower than ever, and constantly firefighting.

Every new feature touches 10s of files. There are six different ways to do the same thing. The data models have fields that exist purely to work around a limitation that was introduced earlier and never revisited. The on-call rotation is a nightmare because nobody can trace the flow of a request through the system anymore.

I've done this to myself. When building Baselime, I made every mistake in the books: premature microservices, poor and impossible to extend schemas, leaky abstraction, etc. I shipped fast, made "pragmatic" architectural calls, and watched the codebase calcify around them. That used to take months of compounding mistakes to reach crisis point.

Last year I got a coding agent, and my side project reached crisis point in days.

Every change is fine, but the codebase is not

This is the insidious thing about slop creep. No single commit is the problem. The agent didn't introduce a bug, it introduced a slightly wrong abstraction, then built on top of it, then built on top of that.

graph TD
    A[Feature Request] --> B[Agent writes solution]
    B --> C[Looks fine in isolation]
    C --> D[Ships]
    D --> E[Next feature request]
    E --> B
    D --> F[💀 Codebase decays]
    style F fill:#fee2e2,stroke:#fca5a5,color:#991b1b

Two weeks later, unwinding it means fiddling with databases in production and rewriting three services. That's slop creep: death by a thousand reasonable decisions.

The old world had a circuit breaker

Bad architectural decisions used to come one at the time. A junior developer with bad instincts had a natural speed limit: they couldn't build fast enough to bury the codebase before someone noticed. The pain was loud and unavoidable, so you fixed it or you died.

graph TD
    A[Bad abstraction] --> B[Slows everything down]
    B --> C[Team feels the pain]
    C --> D[Forced to fix it]
    style C fill:#fee2e2,stroke:#fca5a5,color:#991b1b
    style D fill:#d1fae5,stroke:#6ee7b7,color:#065f46

Coding agents removed the circuit breaker.

The agent can keep piling crap on top of more crap, indefinitely, and stay productive the entire time. You don't slow down. You build a bigger pile. The reckoning is deferred, compounded, and much more painful when it finally arrives.

Coding agents can't think about systems holistically

The core problem is simple: coding agents are not able to find the right level of abstraction when building software. They don't see the system, they see the prompt.

Ask an agent to add an endpoint and it adds an endpoint. It doesn't know there are four other endpoints that should have been abstracted into a shared handler, or that the data model it's extending was already a mistake. It doesn't know any of that because no one told it.

graph TD
    A[Agent sees: the prompt] --> B[Agent builds: the solution]
    B --> C[Correct in isolation]
    B --> D[Wrong for the system]
    style C fill:#d1fae5,stroke:#6ee7b7,color:#065f46
    style D fill:#fee2e2,stroke:#fca5a5,color:#991b1b

The agent is confidently, competently wrong. You must specifically tell it the important decisions in your codebase.

Will this get better?

Maybe. Context windows are growing, models are getting smarter, and the answer is probably more context. The agent that can read the entire codebase, understand the history of every decision, and anticipate where the system is heading in six months will make far fewer wrong calls.

But today's agents don't do that. They see the prompt, the files they're told to read, and nothing else. They have no foresight about where the system needs to go, and no memory of how it got here. Until that changes, the gap between "correct in isolation" and "right for the system" is yours to fill.

The agent should fill the gaps, not make the calls

A coding agent can turn a 10x engineer into a 100x engineer, but that doesn't mean the engineer disappears. It means the engineer stops typing and starts thinking.

It's unfortunate we're collectively using these tools very wrong. Outputting slop daily, turning our brains off because the computer "can do our job for us".

Data models, service boundaries, key abstractions, etc. These are one-way doors, decisions that are hard or impossible to reverse once they're in production. The agent should never be the one walking through a one-way door alone. That's where you come in.

This doesn't mean you dictate every schema and interface upfront. The agent's first draft of a plan is a starting point, and it's usually terrible. Wrong cardinality, missing constraints, boolean fields where you need an enum, no thought given to how the data will be queried six months from now. But that first draft is incredibly useful as something to react to. You read it, tear it apart, annotate it with corrections, and send the agent back to revise. After two or three rounds of this, you end up with abstractions that are better than what either of you would have produced alone, because you're combining the agent's breadth of knowledge with your understanding of the system and the product.

I wrote about how I use Claude Code with a research-plan-implement workflow built around exactly this kind of iterative refinement.

graph TD
    A[Engineer defines intent] --> B[Agent drafts plan with code snippets]
    B --> C[First draft is usually wrong]
    C --> D[Engineer reviews and annotates]
    D --> E[Agent revises]
    E --> F{Good enough?}
    F -->|No| D
    F -->|Yes| G[Agent implements]
    style C fill:#fee2e2,stroke:#fca5a5,color:#991b1b
    style D fill:#ede9fe,stroke:#c4b5fd,color:#5b21b6
    style G fill:#d1fae5,stroke:#6ee7b7,color:#065f46

I don't write code anymore, but I read pretty much every single line my agent writes. Every time I have let the agent loose without a tight plan, I have regretted it a couple of weeks later, always the same things: bad database schemas, boolean fields everywhere, lack of analytics, and don't get me started on observability.

The answer is not to stop using agents

Slop creep is real, but it is not a reason to stop using coding agents. They're the best thing that has happened to software development in years, and I can now build things I didn't know I had in me to build. I have no intention of going back to typing every character of my codebase myself.

But the planning phase deserves ten times more attention than most people give it. Not a vague description of the feature. Actual code snippets for the key data models. Actual interfaces for the key abstractions. Enough that the agent can't get the important stuff wrong, because there's no ambiguity left to fill with slop.

graph TD
    A[Vague plan] --> B[Agent makes architectural decisions]
    B --> C[Slop creep]
    D[Tight plan with code snippets] --> E[Agent executes within constraints]
    E --> F[Clean codebase]
    style C fill:#fee2e2,stroke:#fca5a5,color:#991b1b
    style F fill:#d1fae5,stroke:#6ee7b7,color:#065f46

Spend more time in the plan. Write the code snippets for the decisions that matter. Then let the agent cook.

"Code is the new assembly"

There's a popular counterargument: none of this matters. Code is the new assembly language. Nobody reads it. The agent writes it, the tests pass, the feature works, who cares if the internals are ugly?

This misunderstands what a compiler does. The role of a compiler is to translate higher-level languages into efficient, performant machine code. A compiler that produced bloated, redundant, subtly incorrect machine code would not be used by anyone serious about building software.

If your agent is the compiler, and the output is slop, you don't have a compiler. You have a liability.

graph TD
    E[Good agent workflow] --> F[Clean, maintainable code]
    G[Vibe coding] --> H[Slop that ships]
    style F fill:#d1fae5,stroke:#6ee7b7,color:#065f46
    style H fill:#fee2e2,stroke:#fca5a5,color:#991b1b

And the enshittification doesn't stay in the code, it spills into the user experience. Every vibe-coded app has the same telltale signs, a plethora of tiny cuts that make the whole thing feel off:

• An app that hogs all the available resources on your computer
• A button that doesn't quite disable when it should
• A loading state that flickers
• A form that loses your input on navigation
• An error message that says "something went wrong" because nobody modelled the failure modes

None of these show up in a demo. All of them are bugs your users feel every single day. Slop creep in the codebase becomes slop creep in the product, and your users will not read your code to figure out why the experience is bad. They'll just leave.

The job has changed, not disappeared

Honestly, everything in this post could be obsolete with the next major model release. An agent that truly understands systems holistically, that has the foresight to see where a codebase is heading and the context to know why it got here, would change the equation entirely.

But that's not what we have today. And in the next 6 to 12 months, the engineer who makes the difference is the one who can look at an agent's output and say "this is wrong for reasons you can't see from where you're standing." The one who knows which doors are one-way, which abstractions will calcify, and which corners will cost you later.

Until the models catch up, fight slop creep. The enshittification of software is quiet, entirely preventable, and happening everywhere right now.

Built with Workers, KV, Durable Objects, Workflows, and Browser Run.

GitHub

A slide deck for Cloudflare Workers training, built with React and deployed on Cloudflare Workers.

Built with Workers.

GitHub

AI-generated portrait photos of people from every country.

Built with Workers and Cloudflare Images.

GitHub

Astro 6 just dropped and I couldn't resist upgrading my blog right away. I've been running on Astro 5.16 for a while and the release notes had a few features that caught my eye immediately. Let me walk you through the migration, what stood out, and the features I'm most excited about.

TL;DR

• Migrated from Astro 5.16 to Astro 6 in about an hour.
• The biggest wins for me: first-class Cloudflare support (migrated from Pages to Workers and consolidated a standalone likes API into the main codebase) and the built-in Fonts API (goodbye render-blocking Google Fonts imports).
• Live Content Collections are now stable, bringing request-time content fetching to Astro's content layer.
• Zod now imports from astro/zod instead of astro:content.
• Enabled experimental queued rendering for faster builds.
• Zero errors on the first build. Smoothest major version upgrade I've done with Astro.

The Features I'm Loving

First-Class Cloudflare Support

This is the big one for me. I was previously deploying my blog to Cloudflare Pages with the old @astrojs/cloudflare adapter. It worked, but the dev experience had rough edges: the adapter didn't run workerd locally, so I was always testing against Node.js and hoping nothing broke in production. I also had a per-post like counter running as a separate Worker with its own wrangler config and deployment pipeline. It was a small API, but maintaining it as a standalone project just to increment a number felt like overkill.

With Astro 6, the rebuilt adapter now runs workerd at every stage: dev, prerender, and production. That gave me the confidence to migrate the blog from Pages to Workers. I consolidated that standalone likes API directly into the Astro project. One codebase, one deployment, full access to bindings during development. It's the setup I always wanted.

Built-in Fonts API

This is the other feature I was really excited about. Before Astro 6, I was loading Inter and JetBrains Mono via Google Fonts @import in my CSS. This is render-blocking, sends user data to Google, and honestly just feels wrong for a static site that cares about performance.

Now I just configure fonts directly in astro.config.ts:

	fonts: [
		{
			provider: fontProviders.google(),
			name: "Inter",
			cssVariable: "--font-inter",
			weights: [400, 500, 600, 700],
			styles: ["normal"],
			fallbacks: ["sans-serif"],
		},
		{
			provider: fontProviders.google(),
			name: "JetBrains Mono",
			cssVariable: "--font-jetbrains-mono",
			weights: [400, 500],
			styles: ["normal"],
			fallbacks: ["monospace"],
		},
	],
});

Then add a `` component in my layout's <head>:

---

---

<head>
	
	
</head>

Astro downloads the fonts at build time, generates optimized fallbacks, and serves them from my domain. No more third-party requests. No more render-blocking imports. The fonts are just there, and they're fast.

Experimental Queued Rendering

My blog has 25+ posts with OG image generation for each one, so build performance matters. The new queued rendering replaces Astro's recursive rendering with a two-pass approach: first traverse the component tree, then render it in order. Early benchmarks show up to 2x faster rendering.

Enabling it is just a config flag:

	experimental: {
		queuedRendering: {
			enabled: true,
		},
	},
});

I've enabled this and I'm curious to see how it performs as I add more content.

Live Content Collections

Live Content Collections are now stable in Astro 6. Content collections have always required a rebuild when content changed. Live collections flip that: they fetch content at request time using defineLiveCollection() and getLiveEntry(), with no rebuild needed. Your content updates the moment it's published.

You define a live collection in src/live.config.ts:

const updates = defineLiveCollection({
	loader: cmsLoader({ apiKey: process.env.MY_API_KEY }),
	schema: z.object({
		slug: z.string(),
		title: z.string(),
		excerpt: z.string(),
		publishedAt: z.coerce.date(),
	}),
});

Then query it in your page with built-in error handling:

---


const { entry: update, error } = await getLiveEntry("updates", Astro.params.slug);

if (error || !update) {
	return Astro.redirect("/404");
}
---

<h1>{update.data.title}</h1>
<p>{update.data.excerpt}</p>
<time>{update.data.publishedAt.toDateString()}</time>

I'm not using this yet since my blog posts are all Markdown files in the repo, but now that I'm running on Workers with full binding access, I can see pairing this with a CMS or D1-backed content source down the line. The fact that live and build-time collections use the same APIs (getCollection(), getEntry(), schemas, loaders) makes it easy to adopt incrementally.

Zod 4

The Zod upgrade is mostly invisible if your schemas are straightforward. The main change is where you import it from. Instead of importing z from astro:content, you now import it from astro/zod:

If you're using .default() with .transform(), check the Zod 4 changelog because the behavior around default values changed.

How I Migrated

The actual migration took about an hour. Here's the rough process:

1. Created a branch. Always migrate on a separate branch.
2. Ran pnpm dlx @astrojs/upgrade. This handles the package version bumps automatically.
3. Updated Zod imports. z from astro/zod instead of astro:content.
4. Migrated fonts. Removed Google Fonts @import, configured the new Fonts API, added `` to my layout.
5. Migrated from Pages to Workers. Switched to the rebuilt @astrojs/cloudflare adapter and consolidated my standalone likes API Worker into the Astro project.
6. Enabled experimental features. Queued rendering for faster builds.
7. Built and tested. pnpm build + pnpm check, zero errors on the first try.

What I'm Planning Next

Now that I'm on Astro 6, there are a few things I want to explore:

• Live Content Collections with a CMS. Now that I'm on Workers with full binding access, I want to pair live collections with a headless CMS so content updates go live without a rebuild.
• Responsive images. Astro's image handling keeps getting better and I'm not using srcset/sizes anywhere yet.
• View Transitions. I've been putting this off, but Astro's `` has matured a lot since it was introduced.
• Tailwind v4. The @astrojs/tailwind integration works fine for now, but Tailwind v4 with its native Vite plugin is the future.

If you're still on Astro 5, I'd recommend giving the upgrade a try. The migration path is smooth and the new features are worth it. Have you upgraded yet? I'd love to hear how it went.

Resources

• Astro 6 announcement
• Astro 6 upgrade guide
• Fonts guide
• Content collections guide
• Zod 4 changelog

An AI agent that controls a real web browser using Playwright, running on Cloudflare Workers. Ask it to browse the web, fill forms, extract information, and more — all through a chat interface with a live browser view.

Built with Workers, Durable Objects, Workers AI, Browser Run, and Agents.

GitHub

A token-efficient MCP server for the entire Cloudflare API. 2500 endpoints in 1k tokens, powered by Code Mode.

Built with Workers, KV, and R2.

GitHub

Ready to Talk is a phone-first web app for starting in-person conversations when two people are already in the same place and ready right now.

Built with Workers, D1, Durable Objects, and Agents.

GitHub

Setting up a new Mac used to take me days. I'd install Homebrew, configure my shell, set up Git with SSH keys, install Node, download my editor extensions, and inevitably realize at some point that I'd forgotten to copy over some config file.

I came across Matt Silverlock's dotfiles and realized this could be automated. The idea is simple - version control your configuration so one command reproduces your entire environment on a new machine.

My dotfiles now handle everything from Xcode Command Line Tools to VS Code extensions. What used to take hours now happens while I make a crisp beverage.

What it does

1. Checks prerequisites - Verifies macOS and internet connection
2. Installs Xcode CLT - The foundation for everything else
3. Installs Homebrew - Package manager
4. Installs packages - From a Brewfile with CLI tools and apps
5. Sets up mise - Manages Node, Bun, pnpm, Python versions
6. Configures zsh - oh-my-zsh with plugins and theme
7. Generates SSH keys - Ed25519 keys with commit signing
8. Symlinks dotfiles - GNU Stow links configs into place
9. Sets up secrets - API token configuration
10. Installs editor extensions - VS Code and Cursor
11. Imports Raycast settings - Window management and shortcuts

The script is idempotent - safe to run multiple times, skipping what's already installed.

Work mode

The --work flag separates personal from work setups, given I don't need certain tools or apps on a work laptop, but I want a consistent environment for non-sensitive configurations.

Running sh install.sh --work swaps the Brewfile:

• Brewfile - Core tools for everyone
• Brewfile.personal - Personal stuff
• Brewfile.work - Work-specific stuff

CLI tools that make a difference

These tools fundamentally change how I work in the terminal:

• bat - Syntax-highlighting cat
• delta - Beautiful git diffs
• fd - Intuitive find replacement
• fzf - Fuzzy finder bound to Ctrl+T and Ctrl+R
• ripgrep - Fast search respecting .gitignore
• zoxide - Smarter cd that learns your directories

Managing configuration with Stow

GNU Stow manages the dotfiles by creating symlinks from ~ back to the repo. Edit ~/.zshrc and the change is immediately in version control.

Stow has a .stow-local-ignore file that prevents certain files from being linked. I use it to skip the README, install scripts, and anything else that shouldn't live in ~:

\.git
\.gitignore
README.md
install.sh
Brewfile

My .zshrc configures fzf with custom previews, integrates zoxide, and activates mise. Everything is configured exactly how I like it, on every machine.

Should you do this?

If you set up more than one Mac every couple of years, yes. The investment pays for itself quickly. It's also very comforting.

Start small - fork my repo or Matt's, and edit it to your liking. You could just use Homebrew, your shell, and your editor, and add more as you find repetitive tasks.