"I definitely feel like I've lost control of the codebase." Nithin Bekal has a working language, a Wasm target, and 15,000 lines of Rust he doesn't fully understand. Now comes the hard part: taking it back.

His laptop died a few weeks into building a new programming language. So he kept going... from his phone. Nithin Bekal on what it's like to give an LLM complete control over how your language evolves, and why it was "scary."

Elixir would have made the event sourcing part easier. Ismael Celis picked Ruby anyway, specifically so it would be harder. The constraint was the point.

Optimistic locking is a proxy for the real question. Ismael Celis on Dynamic Consistency Boundaries and what it actually means for a decision to still be valid by the time you commit it.

Every time you update the cart, you throw away what the cart used to be. Ismael Celis makes the case that the temporal model isn't an alternative to the relational one. It's a superset of it.

"How was your day?" You don't answer with a schema. You answer with a sequence of events. Ismael Celis on why we model software in a mode we don't actually think in.

Event sourcing gets a reputation for being heavy. Ismael Celis says the core of it fits in a Ruby file and an array. Everything else (the eventual consistency, the runtime, the workflows) is an optional rabbit hole.

Hanami 3.0 is just the beginning. Tim Riley shares what’s next for the framework, from a richer extension API to a developer experience people will actually want to show off.

Ruby is a mature language, but the ecosystem is full of innovation. In this clip, Tim Riley makes the case for new ideas, different architectural approaches, and keeping the ecosystem open to experimentation.

What happens when companies sponsor open source? Sometimes it gives maintainers the freedom to build the things everyone benefits from. Tim Riley talks about how sponsorship made Hanakai, Hanami 3.0, and a year of steady progress possible.

Open source isn't just about access to code. Hanakai puts its values front and center. Tim explains why building an intentional, welcoming community is every bit as important as building great software.

Ruby isn't a one-framework language. Tim Riley explains why Hanakai brings Hanami, Dry, and ROM together under one roof and why giving developers more architectural choices makes the Ruby ecosystem stronger.

Ted M. Young’s biggest concern about AI isn’t that it will replace developers. It’s that developers may stop learning. In this clip, he explains why hands-on problem solving still matters and why he’s optimistic about the future of software craftsmanship.

A board game about test-driven development turned into a lesson about teamwork. Ted M. Young shares how players naturally discovered the benefits of pairing and mob programming once they saw how much faster they could solve problems together.

Most event sourcing conversations start with audit trails and time travel. Ted M. Young was convinced by something much simpler. In this clip, he explains why event sourcing changed the way he thinks about software architecture and persistence.

Software development gets safer when the steps get smaller. Ted M. Young explains how predictive TDD helps developers take “many more much smaller steps,” creating faster feedback loops and more opportunities to learn before mistakes become expensive.

Most developers expect a test to fail. Ted M. Young argues that the real value comes from predicting exactly how it will fail. When the result doesn’t match your expectation, you’ve uncovered a misunderstanding before it becomes a bug.

Maybe the problem isn’t vibe coding. Maybe the problem is spending all day watching everyone else "build". Joan Westenberg shares her thoughts on doomscrolling, comparison, and why creators should spend less time consuming social media and more time focusing on their own work.

What’s the best way to build something people care about? According to Joan Westenberg, it starts with creating something you genuinely want for yourself and the people around you, not chasing trends or trying to please everyone.

AI didn’t just change how software gets built. It changed how communities have to defend themselves. Joan Westenberg discusses how AI-generated spam is reshaping moderation and why many of the internet communities we remember fondly would be much harder to build today.

The biggest communities rarely start with a master plan. They start because someone finds a place they love, invites other people in, and slowly creates a home. Joan Westenberg explains why community can’t simply be designed into existence.

It doesn't even take a weekend to vibe code a Hacker News clone. What you can’t generate with a prompt is the reason people come back. Joan Westenberg on why community is harder to build than software.

Testing in Rails usually forces a tradeoff. Factories are flexible but slow. Fixtures are fast but messy. Kasper Timm Hansen built something that tries to fix both. Oaken is a different way of thinking about test data entirely.

What if your dependencies were so small… that you weren’t afraid of them? Kasper Timm Hansen talks about why he aggressively limits lines of code and keeps gems tiny on purpose. Smaller code is easier to trust, understand, and even take over.

One of the biggest challenges in Rails apps: your models never stop growing. User. Account. Order. They just keep expanding. Kasper Timm Hansen explains why the real job is breaking things apart before they get out of control.

What’s the difference between a concept and an abstraction? One has direction. The other can feel like loose parts. Kasper Timm Hansen uses a simple analogy to explain why most code feels harder than it should. Better modeling starts with clearer ideas.

After leaving Rails Core, Kasper Timm Hansen started building much smaller tools. Not bigger frameworks. Not complex systems. Small gems with very specific ideas behind them. He explains why those tiny projects can actually have more impact.

An entire CPU emulator. Written in CSS. Lyra explains how you can compile C code and run it without touching JavaScript at all.

What if the problem isn’t CSS… what if it’s how we think about CSS? Lyra talks about how treating it like a “not real language” limits what developers even try to build. That mindset leaves a lot of capability on the table.

A lot of the web runs on layers of JavaScript that don’t need to exist. Buttons. Hover states. Simple interactions. Lyra Rebane breaks down why CSS can handle more than most developers think and why that matters for performance.