This week's video

Coding agents have made me more bullish on Rails, not less. I've been building inside a small TypeScript app on Vercel, and it reminded me what Rails gives you before you write a line of application code: agents make code cheap to generate, but they don't make the infrastructure it creates any cheaper to own.

Watch the video →

Resources mentioned:

• Railbed, an opinionated Rails template built to be agent-ready from day one

The feature that changed my mind

That TypeScript app is small: four separately deployed services in one monorepo, with modest product complexity. The architecture already feels hard to navigate anyway.

The feature that made this concrete: reliably generate a PDF and email it, without tying up a web request. A normal requirement. Without a background-job baseline already in the system, it became a project of its own: a job table, a workflow runner, a cron loop polling for pending work, handlers, and the failure semantics around all of it. An agent can draft every piece of that. It cannot remove the work of reviewing it, understanding its edge cases, securing it, and owning it once the next feature depends on it.

In Rails, the smallest credible version has a path everyone already knows: a controller enqueues the job, Active Job runs it in the background, Action Mailer sends the result. That's not the framework being lazy. It's a production-proven path with fewer decisions left for the agent to invent, and fewer decisions left for a reviewer to reconstruct.

That's the real claim in this week's video: agents make code cheap to generate. They don't make bespoke systems cheap to own. Convention over configuration isn't old-fashioned. It's agent infrastructure.

Why RuboCop, Sorbet, and RubyCritic matter more with an agent in the loop

The video mentions Railbed's quality gate in passing. Here's why each piece of it matters once an agent is writing the code.

RuboCop removes a whole category of things I no longer have to check by eye. When an agent writes a method, RuboCop enforces the same style a senior engineer on the team would expect: indentation, naming, method length. With Rails-aware cops enabled, that extends to preferred Rails patterns over raw Ruby. The value isn't cosmetic. An agent has no instinct for "how we do things here." Left alone, it will happily mix idioms from three different Rails eras in the same file. RuboCop turns that into a build failure instead of a review comment, which means my attention as a reviewer goes to logic and behavior, not to noticing that this method uses unless !x instead of if x. Custom cops go further: you can encode team-specific rules (no raw SQL outside a repository object, no controller logic past a certain line count) so the agent gets the same constraint every human on the team already works under.

Sorbet gives the agent a contract to read before it writes. This is the one that matters most for agent-generated code specifically. An LLM working on a Rails codebase often doesn't have the full picture of every caller and callee in its context window. Type signatures at method boundaries mean the agent doesn't have to infer what shape of data a method expects or returns. It can check. That collapses a common failure mode: an agent makes a locally plausible change to one method, but silently breaks an assumption three call sites away because nothing forced it to notice the mismatch. You don't need Sorbet everywhere. Typed boundaries at the seams where modules meet: service objects, external API clients, background job payloads, are where the ambiguity actually lives, and where a wrong assumption is expensive to discover in production instead of at typecheck time.

RubyCritic is the maintainability signal that "tests pass" doesn't give you. Wrapping Reek, Flog, and Flay, it scores complexity, flags code smells, and catches duplication. This matters specifically for agent-authored diffs because an agent can produce code that's functionally correct and still worse: more branching than the problem needs, a near-duplicate of a method that already exists elsewhere in the codebase, a class quietly picking up more responsibilities than it should. A passing test suite won't tell you that. A before/after RubyCritic score will. It's the difference between "does this work" and "did the codebase get harder to maintain in order for this to work," which is the question that actually predicts whether you'll regret merging it in six months.

None of these tools individually make agent-written code safe. What makes them useful together is that Railbed wires them into one bin/ci command, so there's a single shared definition of ready. The agent has one less toolchain to remember or lose track of in its context. The reviewer has one signal to check instead of four separate mental models. That shared gate is the actual infrastructure this video is arguing for. RuboCop, Sorbet, and RubyCritic are just what it looks like in practice.

Curated Links & Tools

Peter Steinberger's agentic engineering workflow — Peter walks through how he's building with agents day to day, and two details stood out. First, he's added an opt-in skill to OpenClaw that uploads the agent's full session to the PR, so maintainers reviewing the change get the reasoning trail behind it, not just the diff. Second, he covers Crabbox, his system for decoupling the resources an agent needs to run and debug from his local machine, plus an autoreview skill inside OpenClaw that runs a review pass before a human ever looks at it. It's the same thread as the Rails argument above from a different angle: the bottleneck isn't generating the change, it's giving the reviewer enough signal to trust it fast.

What's the last piece of custom infrastructure an agent helped you build that you're still the one who has to own? Reply and tell me.

If you're working through making an existing codebase agent-ready instead, here's how I help →

Damian