009 Joel Gaff, Jr. - AI Coding: Are We Shipping Faster and Learning Less?

Joel Gaff Jr. introduces himself as a Ruby on Rails developer with roughly five or six years of experience. Before software, he spent about 15 years in operations and race directing, most of it with the Ironman group. He managed events involving around 3,000 athletes, coordinating agencies, athletes, logistics, and the many small jobs required to make a race happen. He describes that work as project management in an intense, highly operational setting. Basti connects Joel’s endurance-sports background to his own short-lived attempt at triathlon. After badly injuring his shoulders while training in the gym around 2016, Basti was limited to cardio, despite previously disliking it. A friend introduced him to triathlon, and Basti bought a triathlon bike, began swimming, cycling, and running, and completed his first race—finishing last, even behind older competitors. He enjoyed it enough to continue training and was told at an Olympic-style sports center that, with a year of proper preparation, he could finish an Ironman within the cutoff. He eventually lost interest because the training consumed so much time, and after moving to Berlin he sold his bikes because of the city’s theft problem.

Asked for a memorable race story, Joel recalls an event earlier in the summer with approximately 3,000 athletes. A railway crossing appeared at several points on the bike course, and the organizers had written confirmation from the train company that no trains would run during the race. Despite that promise, athletes were already approaching the tracks when the team heard a train whistle. The organizers immediately used a contingency plan: they stopped athletes from crossing, allowed a relatively short freight train to pass, and relied on timing points so competitors would not lose time unfairly. For five or ten minutes, nobody knew how long the train would be, but the situation was resolved without disrupting the rest of the day. Joel says events like this explain why race directors need a Plan B and Plan C even when they have written assurances. The story also reinforces his view that endurance events resemble a part-time job for athletes: preparing for long races requires a major daily time commitment.

Joel says he began building software to solve his own operational problems and gradually shifted from race operations into Rails development. He is currently looking for his next role, whether as a full-time employee or through building and selling his own software. He has previously owned small triathlon and running events, and he is considering becoming a solo entrepreneur. His practical approach has been to build tools he personally needs, use himself as the first customer, and then decide whether they can become products. Both speakers describe learning Rails during a rapid change in AI-assisted development. Joel was preparing to look for software jobs when AI tools became prominent, forcing him to reconsider what it meant to be a developer. Basti began learning Ruby and Rails in 2025 after previously working with PHP and considering Laravel. Although AI could generate code, he chose to stop using it for most of his own Rails learning so he could understand the framework by writing it himself. He may ask an AI a question, but he does not want an agent to build the project for him. He argues that manually working through a product’s structure teaches why it needs to be built a certain way.

Joel says he faced a similar choice: either pause and learn software deeply or focus on making things quickly. Because he was still relatively new to software rather than a 20-year industry veteran, he felt the trade-off particularly strongly. He now builds more than he studies, while trying not to be ignorant of what happens underneath. He and Basti agree that AI can create distance between a developer and the codebase, even as it makes experimentation dramatically faster. They argue that individual-focused SaaS products are especially vulnerable. People who know how to use AI can recreate tools they previously paid for; Joel mentions building his own version of an online accounting product that had cost him $15 per month, and they discuss Adobe-style applications and Lightroom alternatives. Joel believes larger business software is temporarily more stable because companies care about security, established workflows, and organizational risk, and will not immediately replace products such as Salesforce with an employee’s quick clone. Basti raises the maintenance problem: an AI-generated copy may work, but who understands and maintains the large codebase over time? He also expects token prices to rise rather than fall, pointing to higher tiers and subscriptions that can cost hundreds of dollars per month. Joel is more optimistic that AI-built projects will remain maintainable because agents reduce the effort required, although he expects several competing clones to disappear or consolidate. If nobody maintains a project, he says, someone can always fork it and take responsibility.

The conversation turns to Omarchy after Basti mentions meeting the creator of RawMachi at Euruko in Brno, Czech Republic. RawMachi is an Omarchy plugin that provides a Lightroom-like workflow, and its creator built it soon after moving to Omarchy. Basti sees the project as an example of how a developer with some technical understanding can use AI and Omarchy to make a tool they genuinely want. He also praises the community for helping contributors without competing over who is doing things the “right” way. Basti explains that he first approached Omarchy because he likes Linux, terminals, keyboard-first workflows, and tools connected to his security and penetration-testing background. At first, he mainly valued utilities such as finding and navigating code in the terminal; the agents came later. He now contributes to the project, describing it as his first open-source project. Joel agrees that the Omarchy community feels unusually welcoming and says he rarely sees the hostility or status competition found in other software communities. They speculate about Omarchy’s future, including its community funding—described as roughly $20–23 million—and how that money might be spent. They also discuss a possible mobile version. Rather than simply porting Arch Linux, Basti imagines an Android-based system with deeply integrated agents that could operate beyond a restrictive sandbox. Joel thinks such a platform is likely eventually, while noting that moving away from iOS is harder because family members and existing services are embedded in Apple’s ecosystem.

Basti describes switching from Apple hardware toward Linux-first devices, including a German Tuxedo computer and a Framework laptop. When he received a new US-layout input cover for the Framework, he decided reinstalling the system would be faster than trying to change every setting manually. He backed up his files, reinstalled Omarchy, restored his applications, and was ready within minutes. For him, the ability to reinstall and configure a machine quickly is one of the practical advantages of his current setup. Joel says agents have become equally useful for everyday computer administration. He created scripts for microphone and headphone settings that were not available natively, and he can ask an agent in his home directory to diagnose or fix a problem. He has also used OpenClaw for roughly two months on an older MacBook converted into an Omarchy machine. Connected to Telegram and a Basecamp project, the agent can communicate with him and perform work inside his applications. He is also experimenting with GrokBots, which he describes as a more refined but paid alternative requiring an X subscription of about $30 per month, whereas OpenClaw can use his existing Claude subscription. Basti says AI has made him more focused on one project instead of constantly jumping between ideas. He built personal screencasting software around his video hardware, adding a background-removal feature using Qv2—or “Qtor,” as heard in the conversation—that he could toggle with hotkeys. The agent implemented it in about five minutes, then helped him add livestreaming to YouTube and X and integrate chat. Both speakers conclude that it is sometimes now easier to build a narrowly tailored tool than to search for an existing one.

Joel explains that Rails Guild began as a place where Rails developers could showcase software they had actually shipped. A résumé, LinkedIn profile, or personal website can claim experience, but the Guild attempts to provide a modest form of verification. Developers can prove access to an application by adding a DNS record, placing a token in a file, or completing another check. Joel acknowledges that this is not an airtight system, but it is stronger than accepting unsupported claims. When Omarchy 4 generated significant momentum, Joel paused the Rails Guild and adapted the idea into Omarchy Guild. The new site focuses on contributions to Omarchy, including pull requests, plugins, themes, and applications. GitHub integration allows much of the information to be imported automatically. Joel says roughly 250 people joined before activity plateaued, after which he returned to the Rails Guild and launched it more fully shortly before RailsWorld in Austin. Joel describes RailsWorld as his first major Rails conference, with around 1,000 attendees. DHH’s keynote about the future direction of Rails, Rust, and related changes initially surprised people, and online observers who were not there interpreted the news as evidence that Rails or Ruby was disappearing. Joel says the in-person atmosphere was not despairing: the next two or three days were positive, and both the Rails and Omarchy communities made newcomers feel welcome. Basti shares a similar experience at Euruko, where he arrived as a Ruby and Rails beginner, made connections quickly, and even sat next to Matt—without recognizing him at first.

The final section shifts from software communities to personal confidence. Basti says he had considered making YouTube videos since around 2013, but delayed because he feared judgment, worried about not being a native English speaker, and assumed other technical creators were better. He eventually began posting after joining the Omarchy community and starting an X account. A simple video thanking his first 200 followers became a turning point: he recorded it in his car, published it, and saw that nothing bad happened and the world continued normally. Joel says the same principle applies to his podcast. He and Greg Molnar decided to start a show after meeting at RailsWorld. They had recorded only two episodes when this conversation took place, and the first suffered from poor audio because Joel’s microphone did not work. The second improved after he connected the microphone, and they plan to improve incrementally rather than wait for a perfect production. Joel says working from home can leave him eager to talk even with a delivery driver, so podcasting gives him a valuable way to connect with people. They describe video, podcasting, and public building as unusually vulnerable because people can hear a voice and see a face rather than just read text. Still, they argue that most people are not paying as much attention as creators fear; the relevant audience will find the work, while everyone else generally does not care. Joel cites the principle “done is better than perfect,” and both end by treating shipping the first imperfect version as the necessary way to learn, build a personal reputation, and improve.