RubyConf Africa

The Reviewable
Codebase

Architecture and performance gates in Ruby

Victor Turuthi · Finplus Group

turuthi.xyz

Scan to ask a question,
any time during the talk

1,300

pull requests merged per week

Stripe, "Minions" · human-reviewed, no human-written code

…in a Ruby
codebase

Plain Ruby, not Rails, with Sorbet · hundreds of millions of lines · over $1 trillion a year

How do they trust
that much?

The bottleneck moved

Producing code was the expensive part.
Review was the cheap thing you squeezed in
before standup.

Now producing is nearly free, and review is the constraint.

This is not
an AI talk

No agent demos. Nothing to sell you. An architecture talk that AI made urgent.

The goal is to claim the leverage from the use of agents but without any compromise on the quality of the software.

— Andrej Karpathy, February 2026

How do I keep my old
quality bar at this
new speed?

Spotify ranked their failure modes

1 No PR appears. A minor annoyance.
2 A PR that fails CI. Frustrating.
3 A PR that passes CI and is functionally wrong. Erodes trust. Hides in review. Breaks production.

Refactor billing and update dependencies 741 files changed +18,204 −9,613

agent

I have no idea why I deleted half the codebase and refactored the other half.

reviewer

I have no idea what I'm looking at. Anyway — merge.

Merge pull request + All checks have passed

Confident code and correct
code look identical

Excellent at the first 80% of a feature. Unreliable at the last 20% — edge cases, failure recovery, scaling assumptions. No tone of voice.

What's good for humans
is good for agents

Stripe, Part 1: "if it's good for humans, it's good for LLMs, too."

Four properties

Gates — checks nobody can skip, fast enough that nobody wants to
Budgets — performance as an assertion, not an aspiration
Boundaries — so reviewing one change means reading one thing
Blessed paths — so the default already carries the standard

Property one

Gates

A check that runs every time and cannot be skipped. Not by an agent, not by a contractor, not by me at five on a Friday.

Example 1 — the test that proves nothing


class DiscountCalculator
  def initialize(order)
    @order = order
  end

  def total
    subtotal = @order.items.sum(&:price)
    subtotal - (subtotal * rate)
  end

  private

  def rate
    return 0.20 if @order.customer.vip?
    return 0.10 if @order.items.count > 5
    0.0
  end
end

Example 1 — the test that proves nothing


class DiscountCalculator
  def initialize(order)
    @order = order
  end

  def total
    subtotal = @order.items.sum(&:price)
    subtotal - (subtotal * rate)
  end

  private

  def rate
    return 0.20 if @order.customer.vip?
    return 0.10 if @order.items.count > 5
    0.0
  end
end

The test it shipped with


it "applies the VIP discount" do
  order = build_order(customer: vip, prices: [100])

  expect(DiscountCalculator.new(order).total).to eq(80)
end

Green. 100% line coverage on that method.

Example 2 — the gate that catches it

$ bin/mutant-shipped def rate - if @order.customer.vip? + if true return 0.2 end if @order.items.count > 5 Mutations: 61 Kills: 20 Alive: 41 <- your suite never noticed Coverage: 32.78%

Mutation testing: a tool that tests your tests. It edits your source to deliberately break it — flips a condition, changes a number, deletes a line — then runs your suite against the broken version. If the suite still passes, that test never checked the thing being broken. It replaced the VIP check with the word true. Every test still passed. Line coverage said a hundred percent; mutation coverage says thirty-two. Forty-one ways to break this method that nothing in my suite would catch. Real output, from the repo I'll link at the end. The hardened suite scores 96.72% on the same subject. Head off the CI-time objection before Q&A: you cannot run this across a whole app on every commit. Point it at the twenty percent where being wrong costs money — pricing, auth, permissions, anything touching a ledger — and run it nightly. Stripe do exactly this. Their agent rules are almost never global, because the context window would fill with rules before any work started. Payments code gets payments rules. Narrow scope, hard gate. A gate on everything is a gate on nothing. The first time it's slow, someone adds a skip flag, and you never get it back.

Example 3 — the verifier pattern


module Verify
  Result = Struct.new(:ok, :summary, :details) do
    def self.pass(summary) = new(true, summary, [])

    def self.fail(details)
      new(false, "#{details.size} problems", details)
    end

    def ok? = ok
  end
end

Borrowed from Spotify's verifiers, and the strongest idea in the talk that isn't about performance. Their verifiers turn themselves on. A Maven verifier activates because it found a pom.xml — nobody configures it. And the agent has no idea what the verifier does internally; it only knows it must call it and must pass. The check decides when it applies, and the thing being checked has no say. LINE BY LINE — read it top to bottom, it is nine lines. "Struct.new(:ok, :summary, :details)" builds a small class with three readers: did it pass, one line describing the outcome, and the details a reader needs when it did not. "do ... end" after Struct.new adds methods to that class, which is how a Struct grows behaviour without a separate file. "def self.pass(summary)" is a constructor on the class itself, not on instances — Verify::Result.pass("rubocop clean"). The "= new(...)" form is an endless method: one expression, no end keyword, Ruby 3 and later. It returns a Result with ok true and no details. "def self.fail(details)" takes the lines that matter and builds the summary from them — "#{details.size} problems" — so no caller has to write both the count and the list. "def ok? = ok" gives it the question-mark name Ruby people expect. It reads the "ok" member and returns it, nothing more. Why this exists at all: every verifier returns this one type, so the runner never needs to know which verifier ran or what tool sits behind it. That is what makes the registry on the slide after next four lines long.

One verifier


class Rubocop
  # The verifier decides for itself whether it applies.
  def applies?(root)
    File.exist?(File.join(root, ".rubocop.yml"))
  end

  def call(root)
    report   = JSON.parse(`cd #{root} && rubocop --format json`)
    offenses = report["files"].flat_map { |f| f["offenses"] }

    return Result.pass("rubocop clean") if offenses.empty?

    # The few lines that matter, not the whole report.
    Result.fail(offenses.first(5).map { |o|
      "#{o.dig('location', 'line')}: #{o['message']}"
    })
  end
end

LINE BY LINE. Two methods: one decides whether this check has an opinion, the other runs it. "def applies?(root)" takes the repository root as a path and answers true or false. "File.join(root, ".rubocop.yml")" builds the path safely rather than gluing strings with a slash, and "File.exist?" asks the disk. That's the whole self-selection mechanism: the repository's own contents decide. Nobody passes a flag, nobody edits a config, and there is no argument about which checks a project has opted into. "def call(root)" runs the tool. The backticks run rubocop with the JSON formatter and hand back its output as a string — "cd #{root} &&" first, so it runs in the right repository. JSON.parse turns that into a hash. In the repo I use Open3 rather than backticks so the working directory and the arguments aren't going through a shell; on a slide the backticks read better. "report["files"]" is one entry per file rubocop looked at, each with its own list of offences. "flat_map" runs the block over every file and flattens the results into one array instead of an array of arrays — so you end up with every offence in the repository, in one list, rather than a list per file. "return Result.pass("rubocop clean") if offenses.empty?" — the happy path, one short line, and out. The last four lines are the ones people miss. "offenses.first(5)" takes at most five. "map" turns each into a string. "o.dig('location', 'line')" reaches two levels into the nested hash and returns nil instead of raising if the shape is different, which matters because you are parsing another program's output. Then Result.fail builds the failure. SAY THIS DELIBERATELY. Five lines, not five hundred. Spotify's verifiers do exactly this — extract only the relevant errors, and return a very short message on success. That was to protect the agent's context window. But it is the same reason your CI output should be short: nobody reads a two-thousand-line log, human or otherwise. If a gate's failure message is unreadable, the gate does not work. It just annoys people until somebody disables it.

One verifier


class Rubocop
  # The verifier decides for itself whether it applies.
  def applies?(root)
    File.exist?(File.join(root, ".rubocop.yml"))
  end

  def call(root)
    report   = JSON.parse(`cd #{root} && rubocop --format json`)
    offenses = report["files"].flat_map { |f| f["offenses"] }

    return Result.pass("rubocop clean") if offenses.empty?

    # The few lines that matter, not the whole report.
    Result.fail(offenses.first(5).map { |o|
      "#{o.dig('location', 'line')}: #{o['message']}"
    })
  end
end

…and why it's mandatory


module Verify
  ALL = [Rubocop, Brakeman, RSpec, QueryBudget,
         PendingMigrations].freeze

  def self.call(root)
    ALL.map(&:new)
       .select { |v| v.applies?(root) }
       .map    { |v| v.call(root) }
  end
end

# bin/verify
results = Verify.call(Dir.pwd)
results.each { |r| puts "#{r.ok? ? '+' : 'x'} #{r.summary}" }
exit(results.all?(&:ok?) ? 0 : 1)

LINE BY LINE, and there are only four lines of logic here. "ALL = [...]" is the registry: the list of verifier classes, not instances. ".freeze" makes the array immutable, so nothing can push onto it at runtime — the list of checks is decided in the source, where it can be reviewed, and nowhere else. "ALL.map(&:new)" calls .new on each class. "&:new" is shorthand for "{ |klass| klass.new }" — it turns the symbol into a block. So this line turns four classes into four instances. ".select { |v| v.applies?(root) }" keeps only the verifiers that say they have an opinion about this repository. This is the line that makes the whole thing self-configuring. ".map { |v| v.call(root) }" runs the survivors and collects their Results. Then bin/verify, three lines. Call it with the current directory. Print each result — "r.ok? ? '+' : 'x'" picks the marker, and string interpolation puts the summary next to it. Then "exit(results.all?(&:ok?) ? 0 : 1)": zero if everything passed, one otherwise, because that is the only thing CI actually reads. Four lines of real logic. Every verifier that applies, runs. Nobody picks. There is no skip flag because there is nowhere to put one. Add a class to that array and every repository it applies to is covered from that moment. And it is one command. That matters more than it sounds. The same command runs on your laptop, in CI, and in whatever agent you point at this repo next year. One definition of "is this okay" instead of three that quietly drift apart. Brakeman is in that list because it is the cheapest security gate in Rails: it reads the application rather than running it, finds SQL injection, mass assignment, unsafe redirects, and costs seconds. Its verifier applies when the repo is a Rails app whose Gemfile asks for it, and it only fails on the warnings Brakeman itself rates high or medium confidence — fail on every informational warning and somebody turns the gate off in week two.

Example 4 — move the gate earlier


#!/usr/bin/env ruby
# .git/hooks/pre-push   (chmod +x)

changed = `git diff --name-only --diff-filter=d origin/main...HEAD`
            .split("\n").grep(/\.rb\z/)

exit 0 if changed.empty?

# Fix what can be fixed, instead of only complaining.
system("rubocop --autocorrect-all #{changed.join(' ')}")

# Then fail on whatever is left.
exit 1 unless system("rubocop #{changed.join(' ')}")

Example 4 — move the gate earlier


#!/usr/bin/env ruby
# .git/hooks/pre-push   (chmod +x)

changed = `git diff --name-only --diff-filter=d origin/main...HEAD`
            .split("\n").grep(/\.rb\z/)

exit 0 if changed.empty?

# Fix what can be fixed, instead of only complaining.
system("rubocop --autocorrect-all #{changed.join(' ')}")

# Then fail on whatever is left.
exit 1 unless system("rubocop #{changed.join(' ')}")

Example 5 — types at the boundary


# sig/pricing/quote.rbs

module Pricing
  class Quote
    def initialize: (order: Order, currency: String) -> void
    def total_cents: () -> Integer
    def breakdown: () -> Array[LineItem]
  end
end

Second gate, quickly, because it's the one I get asked about most. Types. I'm not going to try to sell you on typing your whole application — that's a religious argument and I'd like us all to stay friends. But there's a narrow version I think is close to unarguable: put a signature on the boundary. This is plain Ruby with an RBS file alongside it. Seven lines. It says what the constructor takes, what total_cents returns, what breakdown returns. Nothing about the inside of the class. Sorbet if you want it enforced inline and gradually; RBS if you'd rather keep signatures out of your source. I genuinely don't mind which you pick. What I mind is that the boundary between two subsystems is currently described nowhere except in the head of whoever wrote it — and that person may have been a language model.

What the signature catches

$ bundle exec rspec spec/boundaries x Pricing::Quote matches its signature signature drift: Pricing::Quote#total_cents: declared in the signature, missing from the class Pricing::Quote#initialize: signature says keywords: order, class takes keywords: order_id

Gates — recap

Line coverage says what ran. Mutation coverage says what's verified.
Scope the expensive gates narrowly: money, auth, permissions.
Let the check decide when it applies. Remove the option to skip.
Short failure output, or the gate gets disabled.
Fix before you complain. Run before CI.

Property two

Generated code is good at
correct and bad at cheap

Example 6 — the invisible cost


class ReportsController < ApplicationController
  def monthly
    orders = Order.where(created_at: 1.month.ago..)

    @rows = orders.map do |order|
      {
        id:       order.id,
        customer: order.customer.name,
        country:  order.customer.address.country,
        total:    order.items.sum(&:price)
      }
    end
  end
end

Example 6 — the invisible cost


class ReportsController < ApplicationController
  def monthly
    orders = Order.where(created_at: 1.month.ago..)

    @rows = orders.map do |order|
      {
        id:       order.id,
        customer: order.customer.name,
        country:  order.customer.address.country,
        total:    order.items.sum(&:price)
      }
    end
  end
end

Three lines. That's the whole cost. THE PIVOT — this is the argument, not the example. Slow down. You caught it because it's eight lines on a slide and you're at a conference paying attention. You will not catch it in the fourteenth file of a nine-hundred-line pull request at half past four. And nothing will ever fail. It's correct. Tests pass. It ships. It costs four hundred queries, and you find out in six weeks when the report gets slow and nobody remembers why. That is Spotify's failure mode three. Human review is the wrong instrument for it — not because reviewers are careless, but because the cost is invisible at review time and only appears at scale. That's a machine's job.

Example 7 — make the cost assertable


RSpec::Matchers.define :stay_under_query_budget do |max|
  match do |block|
    @count = 0

    sub = ActiveSupport::Notifications
            .subscribe('sql.active_record') do |*, payload|
      @count += 1 unless payload[:name] =~ /SCHEMA|TRANSACTION/
    end

    block.call
    ActiveSupport::Notifications.unsubscribe(sub)

    @count <= max
  end

  failure_message do
    "expected at most #{max} queries, observed #{@count}"
  end

  supports_block_expectations
end

Example 7 — make the cost assertable


RSpec::Matchers.define :stay_under_query_budget do |max|
  match do |block|
    @count = 0

    sub = ActiveSupport::Notifications
            .subscribe('sql.active_record') do |*, payload|
      @count += 1 unless payload[:name] =~ /SCHEMA|TRANSACTION/
    end

    block.call
    ActiveSupport::Notifications.unsubscribe(sub)

    @count <= max
  end

  failure_message do
    "expected at most #{max} queries, observed #{@count}"
  end

  supports_block_expectations
end

Using it


it "renders the monthly report within budget" do
  create_list(:order, 25, :with_items)

  expect { get :monthly }.to stay_under_query_budget(6)
end

Twenty-five orders in the fixture. Not one.

+ rubocop 4s + brakeman 7s + rspec - 412 examples, 0 failures 1m 02s x query budget - reports#monthly 6s expected at most 6 queries, observed

412

./spec/controllers/reports_controller_spec.rb:14

You don't have to write the detector

prosopite or bullet — find the N+1 and name the line that raised it
the budget — stops the number creeping back afterwards
brakeman — the same idea for security, and it reads the app rather than running it

All three are gates. None of them is a code review.

Twenty seconds on tools, because I've just shown you twenty lines you could avoid writing. Prosopite and Bullet detect N+1s while your tests run. Bullet is the better known; Prosopite watches the queries themselves rather than hooking association loading, so it also catches the ones that come from raw SQL or a find_by in a loop. Set it to raise rather than log — a warning in a log file is a warning nobody reads — and the example that caused the N+1 is the example that fails. They do a different job from the budget, which is why I run both. The detector tells you where. The budget asserts a number, so it also catches the page that got expensive without repeating itself: a new join, a missing cache, a serializer that got chatty. And it stops the number creeping back once you've fixed it. Brakeman is the same trade for security: static analysis, so it costs seconds, and it goes in the verifier list next to RuboCop. It's already in the green output on that CI panel. Adoption note if someone asks: turn the threshold up on an existing app and walk it down. A detector that fails a hundred specs on day one gets reverted by lunchtime.

Example 8 — the cost nobody sees until 3am

$ kubectl logs -f web-7d4f [1] ! Terminating timed out worker: 12 [1] - Worker 0 (PID: 12) booted in 61.4s [1] ! Terminating timed out worker: 19 [1] - Worker 1 (PID: 19) booted in 63.1s [1] ! Worker 0 (PID: 26) failed to boot within 60 seconds

This one is mine. Not a case study — a Tuesday. Puma in cluster mode forks workers and waits for each one to say it has booted. Miss worker_boot_timeout and the master kills the worker and forks a replacement, which loads the same Gemfile and misses the same deadline. That's a boot loop. No worker ever serves a request. And notice what the log tells you: that a worker failed to boot. It does not tell you which gem. Nothing in that output names the pull request that did this. Nobody adds ten seconds. Everyone adds four hundred milliseconds — a gem in the Gemfile, a client built at load time, an initializer that dials out. Boot time is the canary for dependency bloat, and it is the slowest thing in your system to notice.

One require. Eight more libraries.

$ bin/boot-profile $ bin/boot-profile boot: 0.007s boot: 0.057s libraries at boot: 2 libraries at boot: 10 digest x csv x date json x date_core x English x forwardable x stringio x strscan x time as it stands after one require "csv"

The gate: a manifest, not a stopwatch


# spec/boot_budget_spec.rb

it "loads exactly the libraries the manifest declares" do
  report = BootReport.call

  expect(report.libraries).to eq(manifest),
    "boot loaded libraries nothing declared: " \
    "#{(report.libraries - manifest).join(', ')}"
end

Here's the part I'd get wrong if I did it again in a hurry. The gate is not a stopwatch. Wall-clock boot time is noise — shared runners, cold caches, a colder morning. I measured seven milliseconds three times and three hundred and fifty-three once, same machine, same code. Assert on that and the gate flakes, and a flaky gate is disabled within three weeks. So the assertion is on the list: which libraries booting pulls in. That is deterministic. A gem arriving in the Gemfile without require: false now fails CI by name, on the pull request that added it, instead of eighteen months later at 3am. The manifest is a file with one library per line. Adding a line is the deliberate act — the cost is still allowed, it just cannot arrive by accident.

Then fix the boot

require: false, then require at the point of use
Never dial out at load time — memoize the client, let the first request pay
preload_app!, and reopen sockets in on_worker_boot
Then set worker_boot_timeout to something honest

In that order, and the order matters. require: false for anything not needed on every request. Most Gemfiles eagerly load gems that three files need. A constant assigned at load time — CLIENT = Sdk::Client.new — turns every boot into a network round trip, once per worker, usually against the service already having the bad day that caused the restart. Memoize it and boot pays nothing; the failure moves from "no worker came up" to "one request got a 503", which is a far better failure. preload_app! so the master boots once and workers fork from a booted image — with on_worker_boot reopening anything holding a socket, because a connection made before the fork is shared between processes and fails in ways you cannot reproduce. And raise the timeout last. Raising it first stops the loop and fixes nothing: the number is the symptom, and the release after next will pass it again.

Example 9 — the budget that doesn't flake


it "serializes without allocating wildly" do
  order = build(:order, items_count: 50)

  report = MemoryProfiler.report do
    OrderSerializer.new(order).to_json
  end

  expect(report.total_allocated).to be < 12_000
end

When a budget fails,
profile

A budget tells you something got worse. It doesn't tell you why. vernier rather than stackprof these days — it understands threads, and will show you a Ractor properly.

Property three

How much do I need to
know to say yes?

Example 10 — shape one


class SubscriptionsController < ApplicationController
  def upgrade
    sub = current_user.subscription

    if sub.trial? && params[:plan] == 'annual'
      sub.update!(plan: 'annual', trial_ends_at: nil)
      Billing.charge(current_user, AnnualPlan::PRICE)
      current_user.update!(onboarded: true)
      Slack.notify("#{current_user.email} upgraded")
      UpgradeMailer.confirm(current_user).deliver_later
    elsif sub.active?
      sub.update!(plan: params[:plan])
      Billing.prorate(current_user, params[:plan])
    else
      return redirect_to billing_path, alert: 'Cannot upgrade'
    end

    redirect_to account_path, notice: 'Upgraded'
  end
end

Shape two — same behaviour


class Subscriptions::Upgrade
  Result = Struct.new(:ok, :subscription, :error)

  def initialize(subscription:, plan:, clock: Time)
    @subscription = subscription
    @plan         = plan
    @clock        = clock
  end

  def call
    return failure(:not_upgradable) unless upgradable?

    ActiveRecord::Base.transaction do
      @subscription.update!(next_attributes)
      Billing.charge(@subscription, price)
    end

    success(@subscription)
  rescue Billing::Declined => e
    failure(:declined, e.message)
  end
end

Compact form for the slide; the repo nests it under module Subscriptions. Four things changed, each of them for the reviewer. Every input is named in the constructor. I know exactly what this touches without reading the body. Every outcome is a Result. I know the complete set of things that can happen — success, not upgradable, declined — from four lines. The side effects that aren't the money — the Slack ping, the email — are gone. They belong to the caller. Only the two operations that must succeed or fail together are inside the transaction. The clock is injected. Not for purity: the time-dependent branch is testable without stubbing global state. Untestable code is unverifiable code. CONCEDE SCOPE. I'm not telling you to do this everywhere. Wrap every controller in a service object and you've built a worse Rails with extra steps. Do it where being wrong costs money. The rest can stay in the controller and I won't tell anyone.

Example 11 — did it stay where it said?


# spec/architecture/scope_spec.rb

it "keeps pricing changes inside pricing" do
  touched = `git diff --name-only origin/main...HEAD`.split("\n")
  allowed = %r{\A(app/services/pricing/|spec/services/pricing/)}

  strays = touched.reject { |path| path.match?(allowed) }

  expect(strays).to be_empty,
    "pricing-only change also touched:\n#{strays.join("\n")}"
end

The plain-Ruby cousin of Spotify's LLM judge. They found their agents got ambitious — refactoring things nobody asked about, disabling flaky tests. So they added a judge: an LLM that compares the diff against the original request and vetoes anything out of scope. It rejects about a quarter of all sessions, and the most common trigger is exactly that. You don't need an LLM for the useful ninety percent of it. Ask git which files this branch changed. Define where a pricing change is allowed to live. Anything outside that is a stray. Fail with the list, so the message tells you what to do next. Nine lines, no AI, and it catches the most common way an unattended change goes wrong: it did the thing you asked, and also three things you didn't. It works just as well on humans, which is the theme of this entire talk.

Property four

One obvious way to do
the common thing

$ bin/rails generate service Billing::RefundOrder create app/services/billing/refund_order.rb create spec/services/billing/refund_order_spec.rb create spec/architecture/billing_scope_spec.rb

Four properties

Gates — what a machine can prove without a human
Budgets — cost as an assertion
Boundaries — so review is local
Blessed paths — so the default carries the standard

None of this
is process

Process is what you reach for when you don't trust the code. These make the code trustworthy, so you need less process, not more.

One gate.
This quarter.

Slow endpoint? Write the query budget matcher. Twenty lines.
Code that touches money? Run mutant against it once. See the number.
Gates in three configs? Write bin/verify. Make it the only command.
No ARCHITECTURE.md? Write it. One afternoon.

Neither answer was
a better model.
Both were a better environment.

turuthi.xyz
github.com/turuthivic/reviewable-codebase
stripe.dev · engineering.atspotify.com

Victor Turuthi

Software engineer, Finplus Group · Nairobi

site turuthi.xyz
repo github.com/turuthivic/reviewable-codebase
talks concurrency · FFI · this one
github @turuthivic
x @turuthi_vick

One gate left

$ bin/verify --audience + gates nobody can skip them 8s + budgets asserted, not hoped for 6s + boundaries one change, one thing 4s + blessed paths the default carries it 2s x questions audience#curiosity ∞ expected at most 0 questions, observed

Q&A

Scope check disabled for the next five minutes. Ask me anything — strays are welcome.👀

No mic needed

Corny on purpose, and it buys you the room's goodwill for the awkward first-question silence. The code is back, larger. If the room has been quiet, say it out loud again: scan, type, no mic, no standing up. Anonymous questions are how you hear from the people who would never queue at a microphone. Read the four green lines fast — they are the talk in four words each — then land on the red one. The line to say out loud: "Everything a machine can check is green. The only gate left is you." Then the scope-check callback: strays welcome. If the first question is off-topic, that joke has already given them permission, which is usually what unsticks a quiet room. Q&A discipline: two sentences per answer, then stop. Long answers read as defensive and eat the queue. The prepared answers are in the brief — CI time, "we don't use AI", small teams, Sorbet vs RBS, gaming the gates. If nobody asks anything: "Then the one thing I'd like you to take with you is — add one gate this quarter. Pick the one you already have a bad feeling about."

The ReviewableCodebase

Architecture and performance gates in Ruby

pull requests merged per week

…in a Rubycodebase

How do they trustthat much?

The bottleneck moved

This is notan AI talk

How do I keep my oldquality bar at thisnew speed?

Confident code and correctcode look identical

What's good for humansis good for agents

Four properties

Gates

Generated code is good atcorrect and bad at cheap

When a budget fails,profile

How much do I need toknow to say yes?

One obvious way to dothe common thing

Four properties

None of thisis process

One gate.This quarter.

Neither answer wasa better model. Both were a better environment.

Victor Turuthi

The Reviewable
Codebase

…in a Ruby
codebase

How do they trust
that much?

This is not
an AI talk

How do I keep my old
quality bar at this
new speed?

Confident code and correct
code look identical

What's good for humans
is good for agents

Generated code is good at
correct and bad at cheap

When a budget fails,
profile

How much do I need to
know to say yes?

One obvious way to do
the common thing

None of this
is process

One gate.
This quarter.

Neither answer was
a better model.
Both were a better environment.