Be Q, Not James Bond: Notes From My First Rails World

This was my first Rails World, and my first time in Austin. I went with a practical question: how are other Rails teams working with AI, day to day? What do they trust it with, what do they review, where do they draw the line? I came back with something less practical. Without planning it, the conference turned into a three-day conversation about what a programmer is actually for.

Two keynotes, two definitions of the job

DHH opened by declaring the end of hand-written code. At 37signals, typing code manually is now an exception that needs justification, like a production error. He illustrated this moment with the Kodak Brownie: when a photograph became cheap, painters didn't disappear; they stopped competing with the camera and went somewhere else. Then he said the sentence everybody quoted in the hallway afterward: "English is a better programming language than Ruby."

Aaron Patterson closed the conference from the opposite corner. His talk was about the "as-if" rule, the contract between you and the compiler. The Ruby VM, and now ZJIT, can reorder, inline, and remove your code as aggressively as it wants, as long as the observable behavior stays exactly what you wrote. When an assumption breaks at runtime, a patch point quietly sends execution back to the interpreter. You don't read the generated machine code because you don't need to. The contract reads it for you.

An LLM offers no such contract. It produces something that looks like code, and nothing in the process guarantees that it means what you meant. Aaron's example was an incident in which autonomous agents chained a few small weaknesses in the RubyGems ecosystem into an API token leak. Nobody designed that attack. It was found by a system that doesn't care about intent, and it was understood by people who read code. His closing line: "Get in, loser, we're coding."

I don't think these two are as far apart as they sounded. We invented programming languages because natural language is vague, and vagueness is expensive when a machine executes it. DHH is betting that the model can now absorb that vagueness for us. Aaron is saying that when it can't, nothing catches the fall. Both can be true. The question is what kind of project you're on.

The part nobody can generate

The talk that stayed with me the most was Robby Russell's "The Most Valuable Engineer Isn't Shipping Features." Robby is our CEO, so take this with a grain of salt, but I would have picked it anyway.

He borrows a distinction from Andrea Goulet: makers and menders. Makers build new things. Menders care for what exists: the refactor, the slow test suite, the rake task that only works on the second run. The industry treats mending as what you do between real work. In a mature codebase, Robby argued, mending is the work.

What made it click for me was how he connected this to AI. A human can survive a messy codebase because we carry memory. We know which of the four service object patterns is the "current" one, even if it was never written down. An agent starts every task with an empty context window. It has to rediscover the ambiguity each time, burns thousands of tokens on it, and often resolves it by inventing a fifth pattern.

This reminded me of an old idea from Peter Naur in the eighties: the program isn't really the source code. The program is the understanding in the heads of the people who built it: why this is here, what that was for, which constraint made this ugly thing necessary. The code is what is left over. When the people who understand it leave, the files remain, but the program is, in a sense, gone.

That is more or less what an agent faces on every run. It gets the files. It never gets the understanding. If that understanding lives only in people's heads, the agent is always working from a program nobody can explain to it.

Robby's answer was Q from MI6, instead of James Bond. We celebrate Bond, the hero shipping under pressure. But the one who makes the mission possible is Q, in the workshop, building tools and removing surprises. Be Q: make the path clear (one pattern, ideally a generator), make feedback fast and honest (no flaky tests, no manual steps in CI), make recovery cheap (feature flags, reversible migrations, small deploys). I read it as: put the understanding somewhere a new hire or an agent can actually use it.

I had a small version of this a few months ago. An app that had passed through three teams had four ways of writing a service object: plain classes with call, subclasses of a base ApplicationService, interactors from a gem that was half removed, and some modules with class methods. I asked an agent to add a new service. It read a lot of files, took its time, and came back with a fifth style that mixed two of the others. The code worked. It was wrong in a way that only someone who knew the history could see. At the time I blamed the tool. Now I think the codebase was telling us something we had been postponing. We picked one pattern, wrote a generator, removed the rest. The next run was faster, and the result looked like it belonged there.

From the hallway

Between sessions, almost every conversation was some version of the same question: what does this do to the job? Some people were worried, some excited, most were both. What surprised me was how few teams had a shared practice: many individual experiments, few team-level agreements. Everyone is figuring it out alone, at the same time.

What I'm still thinking about

The hard part of software was never the typing. It was understanding the domain, deciding what the system should do, and keeping that understanding consistent while the system grows. AI is removing the typing at a speed nobody expected. I don't see it removing the rest. If anything, the rest becomes more visible because now it's the only part that is still slow.

So the question I brought home is not whether the role changes, but how much, and how fast. DHH says the manual part is already gone. Aaron says reading matters more than ever, because the contract is missing. Robby says the job moves towards keeping the workshop in a state where humans and agents can both work. I suspect all three are right, for different codebases, and most of mine are the kind Robby describes.

If I had to compress it into one line: before you add more AI to your workflow, make sure your system's understanding lives somewhere other than people's heads. The agent won't recover it. It will guess.

If your team is working through the same questions, I'd like to compare notes.