Reading Roundup: Just Build It

Why starting is cheaper than you think, and why the best process is often no process at all.

Hey there,

There’s a thread this week about stripping things back. Not in a minimalist-for-the-sake-of-it way, but in a practical one: use less process, fewer dependencies, simpler tools, and trust that you know enough to start. Whether that’s managing AI agents, handling inbound email, or prototyping a feature from a napkin sketch, the message is the same. Stop waiting. Start building.

Don’t Let AI Burn You Out
Karol Bąk on managing yourself when working with AI agents: start with one, scale slowly, plan your context switches, and turn off the notifications that turn async work into sync interruptions.
https://kukicola.io/posts/dont-let-ai-burn-you-out/

It’s About Time I Tried to Explain What Progressive Enhancement Actually Is
Andy Bell makes the case for progressive enhancement as a mental model, not a technique: build in layers from a minimum viable experience, let the browser do the work, and stop treating JavaScript as a prerequisite.
https://piccalil.li/blog/its-about-time-i-tried-to-explain-what-progressive-enhancement-actually-is/

Inbound Email in Rails Apps with Fuik
Rails Designer shows how to process inbound emails using Fuik’s webhook engine rather than Action Mailbox, skipping the ActiveStorage and ActionMailer dependencies you might not need.
https://railsdesigner.com/actionmailbox-fuik/

One Year of Ruby on Rails Configuration
Ben Sheldon (GoodJob author) opens up the /config directory of a year-old Rails app and walks through every monkeypatch, extension, and custom type that accumulated along the way.
https://island94.org/2026/05/one-year-of-ruby-on-rails-configuration

How Soon Is Now in PostgreSQL?
Oskar Dudycz on a subtle PostgreSQL bug: now() returns the transaction start time and stays frozen within a transaction, which broke a retry-based distributed lock. The fix was one line, but finding it took hours.
https://event-driven.io/en/how-soon-is-now-in-postgresql/

Quick notes and actionables

• The burnout article picks up where last week’s Evil Martians piece left off: where Evil Martians named the problem (AI makes you work harder, not less), Karol Bąk offers a practical playbook for managing it. The strongest advice is the simplest: every time your agent makes a mistake, add a rule that prevents it from happening again. That’s how you build trust with the tool over time rather than babysitting it. His point about not turning async into sync is worth repeating. Agent pings, PR comments, CI failures: none of these need to interrupt you in real time. The kitchen analogy is good. You don’t stop chopping vegetables because someone asks you to peel a potato, unless the kitchen is on fire.

• Andy Bell’s progressive enhancement post is from 2024, but the argument has aged well: the core idea is that progressive enhancement is not anti-JavaScript, it just places JavaScript as a nice-to-have rather than a prerequisite. The CSS example is the clearest illustration: set a sensible default, then override it with the newer feature on the next line. The cascade handles the rest. His point about designer-developer collaboration is the part most teams skip. The final deliverable of a web-based design is on the web, not in Figma. Working in the actual medium, in cycles and prototypes, produces simpler UIs and smaller codebases.

• The Fuik approach to inbound email is a good example of reaching for the smaller tool: Action Mailbox requires ActiveStorage and ActionMailer. If you already use those, great. If you don’t, Fuik lets you handle inbound email as plain webhook payloads, route them with a case statement, and see everything at /webhooks. The pattern is provider-agnostic: generate a provider class, map payload fields to private methods, add your business logic, and mark the event as processed. Worth considering if your inbound email needs are simple and you don’t want to pull in storage infrastructure you won’t use elsewhere.

• Ben Sheldon’s config tour is the kind of post I wish more experienced Rails developers wrote: it’s a year of real decisions in a production app, not a tutorial. The highlights for me: the i18n verification patch that raises on missing translations across all locales (not just the current one), the Markdown i18n extension that converts keys ending in _md from markdown to html-safe HTML, and the Git worktree support that uses deterministic integers to prevent port and database collisions across worktrees. The dom_target helper he upstreamed into Rails 8.1 is worth knowing about if you write a lot of Turbo.

• The PostgreSQL now() vs clock_timestamp() post is one of those bugs that makes you wince: now() returns the time the transaction started, not the current moment. Inside a transaction, it never changes. If you wrap a retry loop around a function that uses now() in a WHERE clause, and the retries all run inside one transaction, the predicate is frozen and the retries do nothing. The fix is clock_timestamp(), which reads the wall clock each time it’s called. The testing lesson is equally valuable: the bug lived at the seam between unit tests (which called the function once per transaction) and end-to-end tests (which exercised the retry path but never combined all three failure conditions at once).

From the week

I saw a headline on a YouTube short this week that said “Just Build It” and got very excited. Turned out the video had nothing to do with what I thought it was. But the phrase stuck with me, because it’s something I genuinely believe in, especially as a Rails developer.

So many times I’ve come across companies hesitant to start building because of the perceived cost. I think nowadays the cost of developing a prototype is very small and you can move very quickly. Rails is completely geared up for this. It’s ready to go. I think we should spend more time taking what I call napkin ideas and turning them into features. Not necessarily going through the full user research process, the full design process. Your app is probably at a big enough stage that you’ve got user research already. You’ve got designs based on what’s there, what works. Use your intuition, your past learnings, and your past research to build prototypes quickly. By all means, take those prototypes into user research afterwards and check they meet expectations. But get the thing off the ground first. Don’t wait. Just build it.

Plenty to chew on this week. If you end up building something off the back of any of these, I want to hear about it. P.S. You can see everything I’ve been reading at dcyoung.dev/bookmarks.