I recently joined Errol Schmidt on his Tech for Humans podcast for a conversation about Ruby on Rails, AI, running a software consultancy, open source, and somehowā¦ punk rock.
We started by revisiting my recent Rails World keynote and why I think engineers should spend more time improving the environments they work in. From there, we wandered into what itās like running Planet Argon in an increasingly AI-assisted industry, why Rails upgrades keep getting postponed, and whether AI might change how we think about open source dependencies.
We also talked about my early days as an anarcho-punk kid experimenting with Linux, how that eventually led to starting a software consultancy, and why Iāve somehow come full circleā¦ selling stickers on the internet.
Oh, and apparentlyā¦ Iāve reached the age where Iād prefer punk shows to start a couple of hours earlier. How rebellious. š¤š»
Thanks to Errol for having me on and making room for all those tangents.
We talked about how Oh My Zsh went from a messy little config I shared with a few coworkers into one of the more widely used open source developer tools in the world. Which still feels a little absurd, especially when I look back at the original blog post where I announced it and remember how little grand strategy was involved.
The original goal was not world domination. There was no developer platform strategy. No roadmap. No monetization funnel wearing a fake mustache.
As I said in the conversation:
I literally wanted, like, eight of my coworkers to have this on their computer so that I could be lazy and not have to remember all these complex Git commands.
That was basically it.
A few of the things we covered:
why Oh My Zsh started in the first place
how themes and plugins came out of coworkers wanting to customize things
why Git felt so strange and useful in the late 2000s
designing developer tools for beginners instead of optimizing for the loudest experts in the room
why automatic updates ended up being one of the accidental ingredients that helped the project spread
what it feels like to ācreateā something that is probably more accurately described as something I curated
how AI-assisted pull requests are showing up in open source
why software consultancies might need to rethink what they actually sell
The fun part of revisiting this story is realizing how many of the āfeaturesā were really just small decisions made to keep a few coworkers from stepping on each otherās toes.
Themes happened because someone did not like my color choices. Rude, obviously.
Plugins happened because someone wanted Python and Django shortcuts without dragging along all my Ruby on Rails assumptions.
Automatic updates happened because nobody was going to remember to cd ~/.oh-my-zsh and run a Git pull on a regular basis. Which is fair. That is not a lifestyle anyone should aspire to.
A lot of Oh My Zsh grew out of trying to make the command line feel a little less intimidating for people who were still getting comfortable there. Not the person shaving milliseconds off shell startup time with a jewelerās loupe. The person who wanted their prompt to show the Git branch, make the terminal feel less hostile, and maybe feel slightly more like a hacker in a movie where nobody ever mistypes.
Anywayā¦ Jack and I got into all of that, along with open source maintenance, developer experience, AI-assisted contributions, software consulting, and the strange career consequences of accidentally starting a project that outlives your original intentions.
You can listen to the episode over on Scaling DevTools, or watch the interview above. And if you prefer the conference-talk version of the Oh My Zsh story, I gave one at SquiggleConf that lives on my speaking page.
Every two years, the team at Planet Argon runs the Rails Developer Survey. And every two years, I go through the same processā¦ a long list of questions, a hard look at how much time weāre asking of respondents, and a lot of cutting.
If youāve filled it out before, thank you. If this is new to you, hereās the short version: itās an open survey for Rails developers at all experience levels and across all kinds of organizations. We compile the results and share everything publicly. No paywalls. No vendor spin. Just a snapshot of what the community is actually doing.
We first ran this in 2009ā¦ back when āshould I use Rails?ā was still a serious questionā¦ and have been doing it every two years since 2012.
You gave a handful of your devs access to Claude Code Maxā¦ and things moved fast. Output went up. Then things started to drift. Not just formatting or naming. Structure. Approach. Assumptions. One developer builds guardrails around it. Another uses it like autocomplete. A third treats it like a thinking partner. Same tool, same codebaseā¦ different results. The code starts to reflect how each person uses the tool, not how the team builds software together.
Over the past few months, a few of us at Planet Argon have been experimenting with Claude Code on real client Ruby on Rails projects. Not demos or greenfield apps, but the kind of long-lived codebases where a backtrace can eat forty-five minutes before you even understand the call chain.
The part that surprised us is how often some of those debugging sessions now wrap up closer to ten minutes.
Weāre not ready to make big claims. But weāve developed enough of a feel for when to reach for it, which model to use, and how to keep it from making a mess of your codebase that it felt worth writing down.
The guide covers things like model selection (Sonnet vs Opus and when to switch mid-session), RSpec and Minitest workflows, debugging with error monitoring payloads, and how weāre structuring CLAUDE.md without turning it into a dumping ground. Itās written for developers who are skeptical of the hype but curious enough to run an experiment.
The engineers on your team whoāve already started experimenting with tools like this probably have a small head start. The gap closes quickly once you see where they actually help.
Iāve been running a few experiments to streamline our development workflow, and I keep talking with folks on teams who havenāt been granted the budget or access to this kind of tooling yet. So Iām writing some of these up to help demystify what the experience is actually like.
For this one.. I wanted to see if I could take an AppSignal error and go from alert ā fix ā deploy without leaving the terminal.
One of my priorities this quarter was running a few AI pilot experiments. This was one of them.
When I mentioned the project to a teammate, he said, āYou should write this up.ā So here we are.
Others on our team had already been exploring embeddings, vector databases, and RAG. Iād been watching from the sidelinesā¦ until it was time to roll up my sleeves and build something myself.
New repositories. Clean architecture diagrams. The excitement of choosing tools before real constraints show up. First commits get attention because they feel like authorship.
Most developers, though, donāt spend their careers starting from scratch. They spend them stepping into systems that already exist, already have users, and already have decisions embedded in them.
You open the repository and there are hundreds of thousands of lines of code waiting for you. Patterns layered over time. Workarounds that solved real problems in earlier moments. Comments that hint at context you werenāt there for. You didnāt choose the framework version. You didnāt pick the database. You didnāt design the way billing logic is structured.
