Building with AI, keeping it human

I’m using Cloudflare Workers to host this new blog, and I’ve started reaching for it more and more for small personal projects too. Not because I’m trying to be an edge maximalist, and not because I think every app should be serverless. It’s simpler than that.

Workers makes shipping little things feel lightweight again.

For my blog, I wanted something that was fast everywhere, easy to deploy, and basically impossible to accidentally overcomplicate. For personal projects, I wanted the opposite of a "real infrastructure decision." I wanted a place where I could write some code, hook up a couple of primitives, and hit deploy without turning it into a weekend of setup, security patching, and vague anxiety about future scaling.

If you're interested in looking at the source code for this blog, check it out on GitHub: https://github.com/brucehart/bhart-org

Developing this with AI agents make this all very simple. In about the time it would take me to set up a Wordpress blog on another host, I have a fully featured custom blog platform running on Cloudflare Workers. It includes all of the features I want and none that I don't. I also don't have to deal with Wordpress updates and worrying about someone posting a Wordpress CVE that I didn't respond to fast enough. The great thing about running my own platform is that I can constantly tinker and add features. It usually just takes one or two good prompts to Codex and a "wrangler deploy" command.

One thing that surprised me is how much the pricing changes my behavior. When it’s cheap enough that experiments don’t feel like commitments, I build more. I try weirder ideas. I ship sooner. I don’t treat every endpoint like it needs a finance review. And that, more than anything, is why I’m planning to use Workers more often.

It makes web coding fun again.

Workers as boring infrastructure and that is the compliment

Every platform says it removes server management. Most still leave you thinking in terms of machines, regions, and capacity planning.

Workers does something different. The mental model is not "I am running code on a computer." It’s "I am attaching logic to a global network."

That distinction sounds subtle but it leaks into everything. You stop asking how many instances you need. You stop worrying about regional failover. You stop planning a future CDN migration because the platform already assumes the world is distributed.

It is not that everything is fast. It is that proximity becomes the default rather than an optimization project.

The pricing removes fear, not just cost

Workers pricing is not just cheap. It is psychologically cheap.

I rarely find myself asking "will this endpoint be expensive" before building it. That is unusual. Most infrastructure nudges you toward defensive design early. Cache aggressively. Batch requests. Avoid experimentation.

With Workers, the bill grows slowly enough that you can learn first and optimize later. CPU based billing helps here because waiting on I/O does not punish you. Bandwidth not being metered removes an entire class of anxiety. Subrequests being free changes how you compose systems.

The result is not just lower cost. It is fewer premature constraints.

Performance as a sane default, not a miracle

Running at the edge does not make bad designs fast. It does make good designs easier to arrive at.

What I like is how performance debugging becomes more honest. If something is slow, it is usually because your code is slow, your storage choice is wrong, or your upstream dependency is the bottleneck. You are not fighting the platform just to get baseline responsiveness.

That clarity keeps performance work focused. You fix the actual problem instead of adding layers.

Workers stopped feeling like "functions" a while ago

The moment Workers clicked for me was when it stopped feeling like serverless functions and started feeling like an application platform.

R2, Durable Objects, and D1 are the reason. Together they cover storage, coordination, and persistence without forcing you into a traditional server shaped architecture.

This matters because the hardest parts of applications are not stateless request handlers. They are state, contention, and coordination.

Durable Objects are a cheat code for real time systems

Durable Objects are opinionated in a way that saves you from yourself. Single threaded. Globally unique. Strongly consistent.

Those constraints remove entire categories of bugs. You do not accidentally build distributed consensus. You do not debug race conditions across regions. You get one place where truth lives.

If you are building anything collaborative, live, or session oriented, this is enormous. Chat rooms. Multiplayer state. Presence. Shared documents. You can focus on product behavior instead of infrastructure gymnastics.

WebSockets fit naturally here too. You open a connection and keep it. You stop hammering your backend with polls because there is no incentive to.

R2 changes how you think about storage costs

R2 looks familiar if you have used object storage before. The difference is how relaxed it lets you be.

No egress fees removes a constant background worry. You do not design around "what if users download too much." You do not hesitate to serve files directly. You do not need a separate mental model for cost avoidance.

The tradeoff is latency, especially at the tail. Cold objects can be slow. That is real. But it is also predictable. Cache hot things. Prewarm what matters. Do not pretend object storage is a database.

Once you accept that, R2 becomes a very comfortable building block.

D1 is SQLite and that is exactly why it works

D1 being SQLite is not a limitation. It is the feature.

SQLite is simple, well understood, and surprisingly powerful. It fits small and medium apps incredibly well. It also plays nicely with AI coding tools because those tools have deep prior knowledge of SQLite patterns.

I have found myself writing fewer layers around the database because the database itself can handle more than I expect. Full text search. JSON queries. Small relational models that just work.

For many projects, D1 lets you skip the "pick a real database later" phase entirely.

Frameworks matter less when your agent can write the glue

I like Hono. It is clean and pleasant.

But my relationship with frameworks has changed. When an AI agent can generate a router that matches my endpoints exactly, the value of a framework shifts.

Frameworks now earn their keep through conventions, readability, and long term maintenance. Not because they are required to get started.

That makes Workers feel lighter. You can stay close to the platform without giving up structure when you want it.

The dashboard is fine, but shipping speed is the real interface

Cloudflare’s dashboard works. It keeps getting better.

What I notice more is how my expectations have shifted. I now expect platforms to evolve as quickly as the tools I use to write code. When something takes weeks to land, it feels slow even if it is objectively reasonable.

This is less a complaint and more a signal. Workers has the gravity to be a default backend for a lot of builders. The faster the surrounding experience evolves, the more that gravity compounds.

Workers plus models is where things get interesting

Using Workers as the edge layer in front of AI models feels natural. It handles auth, routing, and fan out cleanly. It is fast enough to sit in the request path without becoming the bottleneck.

As model access becomes more commoditized, the value shifts to how quickly you can integrate, experiment, and ship. Workers is very good at that part.

Where things get tricky is dependency chains. When your app depends on a model provider behind another platform, clarity matters. Status matters. Error surfaces matter. As this space matures, the platforms that communicate clearly during failure will earn trust faster than the ones that just optimize for the happy path.

Where Workers fits for me

I reach for Workers when I want to ship something globally without turning infrastructure into a project. When I want costs that do not spike unexpectedly. When I want stateful real time features without inventing distributed systems. When I want storage and a database that are good enough to get real users.

I reach for something else when I need long running heavy compute, strict regional residency constraints, or a deep ecosystem in a language that does not map well yet.

The real win is reduced decision fatigue

The best thing Workers does is make the default path good.

You do not argue with yourself about regions. You do not overthink scaling. You do not delay shipping because the infrastructure plan feels incomplete.

You build. You deploy. You learn.

That sounds simple. It is rare in practice.

And once you experience that feeling, it is hard to go back to babysitting servers at 2 a.m.