Apple Fonts In Omarchy - Omarchy out of the box looks very good and teamed up with my recommended hi-dpi monitor showing at least 218ppi fonts are incredibly sharp. However as a Mac switcher they aren’t quite right - meaning I’m used to seeing system fonts be SF (the default Apple font) and whilst one day it won’t quite bother me that they aren’t there - for now I want to see web sites that are programmed to use -apple-system or -system-ui to show the SF font.

Doing this in Omarchy (or I guess any flavor or modern linux) is pretty straightforward but I wanted to lay it out here so its easy.

[read more...]

The Ground Your Agent Walks On - Every codebase is terrain. Some are smooth highways, where AI agents can move fast and confidently. Others are more like an obstacle course - still functional, but harder to navigate, even for experienced developers. For AI agents, the difference matters more than you might think.

Matt Pocock recently tweeted, “Know the ground your agent will walk on.” It’s a great metaphor. AI coding assistants aren’t just tools - they’re travelers trying to make sense of your landscape. The easier that terrain is to read, the better they perform.

The Terrain Metaphor

Think of your AI agent as a sharp, capable junior developer. Fast, tireless, and helpful - but very literal. They don’t infer intent. They follow cues.

When your codebase has clear structure with focussed models, controllers that follow consistent patterns, logic that lives in obvious places then AI agents can hit the ground running. They know where to go and what to do. But when logic is scattered across models, helpers, and controller actions - when responsibilities blur and patterns break - it’s harder. The AI has to guess, and that’s when bugs, duplication, or missed edge cases creep in.

You’ve likely seen it: in a clean, readable codebase, the AI knows where to add password reset logic. In a tangled one, it might reinvent validation from scratch, or break something that silently relied on old behavior.

The Productivity Multiplier

Well-structured code doesn’t just help AI a little. It can make them drastically more useful.

Clean abstractions give the model leverage. Instead of spitting out code you need to carefully review or fix, it can offer changes that fit right into your architecture. The AI stops being just a helpful autocomplete and starts being a real multiplier.

[read more...]

How can we use AI without getting dumber? - DHH’s recent observation about AI resonated:

“As soon as I’m tempted to let it drive, I learn nothing, retain nothing.”

When he lets AI take the wheel, his learning stops. Knowing how you learn best is crucial and I respect that. But his tweet reminded me of my first week with Rails many years ago. One command - rails generate scaffold Blog - and boom. Working blog. Complete with database migrations, controllers, views, the works. I felt like a god.

For about ten minutes.

Then came the client requests. “Can we add comments?” “What about tags?” “Why is it so slow with 10,000 posts?”

I had no idea. I’d built nothing. I’d learned nothing. The only thing that had happened was some code appeared on my screen.

I know what you’re thinking: “That’s different. Rails generators create 50 lines of boilerplate. AI writes entire features, algorithms, and architectural decisions. One removes tedium, the other removes thinking.”

Fair point. The scale has changed dramatically. But here’s what’s interesting - in the early days, those 50 lines of generated code felt just as magical and just as dangerous to understanding. I remember the debates about whether generators would make us worse developers, whether we’d lose touch with the fundamentals. Some of us worried we’d forget how to write SQL or understand HTTP.

Sound familiar?

We’re watching the same pattern repeat, just amplified. With Rails generators, with Stack Overflow, with Google, with IDE autocomplete, and now with AI. Each time, the community splits: those who see a shortcut to ship faster, and those who worry we’re shortcutting our way out of understanding anything.

Both groups are right. And both are missing the point.

[read more...]

That Weird AI Workflow Might Just Work - Kieran Klaassen and team mates shared their Claude Code workflow a few days ago. They broke down their process, showed what they built, and yesterday Kieran posted about the (potential) API costs a workflow like this has (or would have if not for Anthopic’s Max plan). The response? While some were curious, the critical voices dominated - calling it too expensive and claiming ‘these AI folks’ aren’t building anything real (check out Kieran’s X feed to see how absurd that is).

Here’s what bothers me: Kieran wasn’t bragging. They were sharing data. They were excited about their productivity gains and wanted to show others what worked for them. And instead of curiosity or questions, they got dismissal.

The Real Problem

We all know AI is transformative. Nobody’s arguing that anymore. But there’s this weird gatekeeping happening around how people use these tools.

Someone posts about using Claude to write tests? “That’s not real testing.” Someone shares their Cursor workflow? “You’re just racking up API bills.” Someone shows how they built an app in a weekend with AI assistance? “But is it production quality?”

The critics are missing the point entirely. These developers aren’t saying their way is the only way. They’re experimenting. They’re pushing boundaries. They’re figuring out what works.

Why This Matters

Every breakthrough in development workflows started with someone trying something different and sharing it. Remember when people mocked developers for using Rails? “It doesn’t scale.” “It’s just a toy framework.” “Real developers use Java.”

Those early Rails developers weren’t wrong for sharing their excitement. They were pioneering new ways of building web apps. Some of their approaches failed. Others became industry standard.

Sure, not every experiment will pan out, and healthy skepticism has its place. But there’s a difference between thoughtful critique and reflexive dismissal.

Same thing is happening now with AI workflows.

[read more...]

Your Code Works? Prove It. - I recently opened a pull request on a new project and, along with the usual details, included a short demo screencast. I do these often because they’re low-effort but high-impact.

The code in the PR might be clean. The tests might be thorough. But nothing proves your code works better than running through it like a real customer would. Here’s the blank state, here’s the error state, here’s the working state.

As I record these short screencasts, I often spot issues, or I get a flurry of ideas worth capturing for future cycles, and the feature usually ends up better just from going through the recording process. Sometimes things pass unnoticed during development and only show up when you step back and watch it play out.

Most web developers are already clicking around constantly, refreshing the browser to test what they’re building. But just working is the baseline. How does it feel? Can you explain it? Did you need five clicks when three would’ve done?

I think reviewers appreciate the video too. It shows care. It can save them from pulling the branch just to see it in action. When a PR has beautiful code, solid tests, and a short demo, it’s a pleasure to review. Next time you open a PR, try narrating a 60-second walkthrough. You might be surprised what you catch, or how much smoother the review goes.

Upgrading Rails applications to Tailwind 4 - With the TailwindCSS 4 beta out, I decided to upgrade my Rails applications. Here are the steps I took to do the upgrade^*:

[read more...]

Beware Tailwind Color Changes - Let’s talk about the humble HTML button. Let’s imagine you have a beautiful button that you styled in the classic green style made famous by all the scientific research that showed that a green button converts better.

[read more...]

(How I) Deploy Solid Queue with Capistrano - I manage a small number of Rails apps that haven’t yet migrated to Kamal for deployment but I wanted to migrate to solid_queue asap to reduce the service burden of running redis.

These applications are deployed with Capistrano on Ubuntu LTS servers and the solid_queue is managed by linux’s systemd. There isn’t much information out there on how to deploy solid_queue with Capistrano so hopefully this helps those of you that still use this popular way of deploying Rails applications.

The systemd service is defined in a file located in your deploy users home folder

[read more...]

Daily backups and diffs of ONCE Campfile source code - When you purchase Campfire from 37Signals, you will be able to download the source code. This download is a ZIP file and includes no git information. You do need to include your purchase token in the url of the download and if valid the source zip will download.

You are permitted of course to push that code to your own private git repository. By adding the Github Action workflow file below to your PRIVATE Campfire repo, Github Actions will download the ONCE Campfire code, unzip it, and then push a commit with todays date. You will then have nice diffs of changes made to the source. If there is no changes then no action will be taken.

[read more...]

Developing with Browser Guards in Rails 8 - As part of the Rails 8 milestones, DHH added a browser guard which he explains thus:

To take full advantage of our #nobuild defaults, we need to ensure that developers have easy control over which versions of the major evergreen browsers they intend to support, and guard their application from being accessed by unsupported versions.

In the pull request that followed we can see that by default, the browser minimums have been set to:

• Safari 17.2
• Chrome 119
• Firefox 121
• Opera 104
• and well, no IE at all.

What this means in practice is that if you visit a newly generated Rails site with a browser below these versions, you will get this 426 error page:

[read more...]