Video: DHH Opening Keynote at Rails World

YOUTUBE.COM

David Heinemeier Hansson (DHH) is the flamboyant creator of the hugely successful Ruby on Rails framework, and has been a vocal advocate for Ruby for many years. This is his keynote from the annual Rails World conference last week, where he all but declared the death of human coding, and chucked Ruby (and Rails) into the same grave.

His keynote started in familiar territory: the late 2025 inflection point, increased agent autonomy and the massive productivity boost that is now possible. He takes it a step further by challenging whether principles such as DRY and clean code will matter in the future, arguing that the optimal architecture for agent-produced software may be materially different from the optimal architecture for human-produced software. Nothing too radical yet.

Then came the bombshell: Hey, his company’s flagship application, is moving away from Rails, having been rewritten in Rust, a language DHH has long and loudly disliked, and still does. Amusingly, he states that Rust is horrible for humans but that he doesn’t mind subjecting agents to its ugliness!

“I don’t need to enjoy writing Rust if I don’t write it”

Ruby was very carefully designed to be an expressive language that is pleasant for humans to use. What is the role of Ruby in a world where we no longer write the code?

DHH makes the weak argument that the ergonomics of Ruby make it agent-friendly, but he undermines it throughout the talk by repeatedly reaching for Rust and C++ instead of Rails.

I can only imagine the hallway conversations among the ~1,000 attendees, hearing the creator of Rails all but abandon it in his keynote.

There is more to code review than (automatable) detection

ADAPTIVECAPACITYLABS.COM

This blog post is a rebuttal to a paper titled “The End of Code Review: Coding Agents Supersede Human Inspection”, which I haven’t read, but you don’t need to have read it to enjoy this post. The paper claims that “every stated goal of code review can be served by agents at lower cost and higher throughput”. In other words, humans don’t need to review code anymore. I don’t agree, but articulating why isn’t easy. Thankfully, that is where this blog post helps out.

I won’t repeat their reasoning here, as it is a brief post, but the arguments are quite compelling.

If we do not stop to help each other, what do we become?

CODINGHORROR.COM

First, a bit of context. Coding Horror is the personal blog of Jeff Atwood, one of the co-founders of Stack Overflow, a Q&A site for programmers that was the go-to site for software engineers for well over a decade. I used that site on a daily basis, and was quite proud of my profile. Yes, the gamification aspect worked on me, and I was quite happy to be the top-ranked user for answering questions with the WebAssembly tag!

Sadly, Stack Overflow has suffered a rapid decline, with traffic falling to a fraction of its peak, resulting in the site being declared almost dead.

This post isn’t directly about Stack Overflow, but the connection is quite clear. Jeff has published a letter from someone who wanted to share a very personal note of thanks for the help that Stack Overflow had provided throughout their career. But what the letter highlights is not the value of the technical content or the answers themselves; it’s the value of the community, something that LLMs cannot replace. That special feeling you get when someone invests time in you.

You Said No MCP!

EARENDIL.COM

Pi is a popular and lightweight open-source coding agent. The team behind Pi previously rejected MCP because they saw it as an inefficient way for agents to use tools, favouring lightweight alternatives. Giving an agent hundreds of individual tool definitions consumes valuable context, while complex tasks can require long chains of tool calls, with every intermediate result passing back through the model. They preferred command-line tools, where an agent can write a small script to compose multiple operations without repeatedly involving the LLM.

What changed wasn’t so much MCP itself as the architecture around it. Deferred tool loading means agents no longer need every tool definition in context, while Pi’s new “Codemode” lets an agent write JavaScript that discovers and invokes MCP tools programmatically. A single program can make hundreds of calls, filter and combine the results, and return only what the model needs. MCP therefore becomes less of a cumbersome tool-calling mechanism and more of a standard API layer that agents can discover and program against.

I must admit, I’m still not sure why Codemode benefits from using an MCP server rather than a regular API!