Giant Robots Smashing Into Other Giant Robots

PII filtering for RubyLLM with Top Secret

2026-04-17T00:00:00+00:00

If you’re building LLM-powered features in a regulated industry, sending unfiltered PII to a third-party provider isn’t just risky, it may violate compliance requirements like HIPAA or GDPR.

That’s why we originally built Top Secret. However, when we first released it, RubyLLM was still in its early days, and I found I was working with provider APIs directly, such as Ruby OpenAI or OpenAI Ruby. This meant I needed to manually orchestrate the filtering and restoration process, which looked something like this:

require "openai"
require "top_secret"

openai = OpenAI::Client.new

original_messages = [
  "Ralph lives in Boston.",
  "You can reach them at ralph@thoughtbot.com or 877-976-2687"
]

# Filter all messages
result = TopSecret::Text.filter_all(original_messages)
user_messages = result.items.map { {role: "user", content: it.output} }

messages = [*user_messages]

chat_completion = openai.chat.completions.create(messages:, model: :"gpt-5")
response = chat_completion.choices.last.message.content

# Restore the response from the mapping
mapping = result.mapping
restored_response = TopSecret::FilteredText.restore(response, mapping:).output

Even with RubyLLM, there was no way to filter and restore conversation history, since Chat#ask handles the message life cycle internally.

Enter RubyLLM::TopSecret

The introduction of RubyLLM::TopSecret aims to make filtering sensitive information from RubyLLM chats as simple as possible. All you need to do is wrap your existing in-memory chats with RubyLLM::TopSecret.with_filtering:

RubyLLM::TopSecret.with_filtering do
  chat = RubyLLM.chat
  response = chat.ask("My name is Ralph and my email is ralph@thoughtbot.com")

  # The provider receives: "My name is [PERSON_1] and my email is [EMAIL_1]"
  # The response comes back with placeholders restored:
  puts response.content
  # => "Nice to meet you, Ralph!"
end

Working with ActiveRecord-backed chats is even easier. All you need to do is add the acts_as_filtered_chat class macro, and the gem will take care of the rest.

class Chat < ApplicationRecord
  acts_as_chat
  acts_as_filtered_chat
end

If you want more granular control, you can simply pass an if: condition. For example, you might only need to filter customer-facing chats that process health data, but not internal admin conversations. A simple way to model this would be to add a filtered boolean column to the chats table:

class Chat < ApplicationRecord
  acts_as_chat
  acts_as_filtered_chat if: :filtered?
end

In either case, the goal is to create an opt-in approach that just works. If you want to see it in action, check out this live demo.

If you’re interested in exploring the gem yourself, follow the installation guide and refer to the usage section for a more detailed overview.

Giant Robots Podcast Ep 608: Project Updates with Will, Chad and Sami

2026-04-16T00:00:00+00:00

Our hosts provide a peek behind the scenes as they discuss their work on recent thoughtbot projects.

The AI stack I developed to help me context switch

2026-04-16T00:00:00+00:00

As a product manager, my weeks are defined by context switching. Between working on a client project, internal initiatives, leadership meetings, 1:1s, investment time, or personal development, there’s a lot to hold at once. Each of those contexts has its own history, to-do lists, open questions, follow ups, and stakeholders.

The cognitive overhead of holding all of that while still being able to show up fully prepared used to be genuinely exhausting.

This is a quick guide to the system I’ve built to manage it. Of course this is a blog post about AI and I run the risk of sounding like a “996-vibe-codez-all-day” fanatic. But at the very least, it’s made a tangible difference in how present and prepared I feel day-to-day, and I hope some of the concepts or processes can be helpful to you too.

Also, remember, like anything in life (and especially in product development) it’s not perfect, it’s still evolving, and my naming schemes are definitely corny. Enjoy.

The three tools

The system runs on three tools working together:

Gemini Meeting Notes (or your AI meeting note taker of choice): auto-generates transcripts and structured summaries of every Google Meet call
Obsidian: local markdown note-taking app that serves as my personal knowledge base
Claude Projects: separate AI contexts I maintain for each area of my work

Each tool solves a distinct problem. The value is in how they connect.

Gemini Meeting Notes: staying present in meetings

The biggest benefit here is simple: I rarely ever take notes during meetings.

For me, it changed the quality of my participation entirely. Not splitting my attention between listening and typing has allowed me to ask better follow-up questions, read the room, catch the things that don’t get said explicitly. Most importantly, I can actively listen.

Gemini runs in the background and handles the capture automatically. After each call, I get a structured summary and a full transcript. I don’t have to do anything during the meeting except show up and participate.

Obsidian: a local home for everything

Gemini notes are useful on their own, but raw meeting transcripts sitting in Google Drive aren’t a system and almost always end up in Google Drive purgatory. Obsidian is where I organize it all. If you’re not familiar with Obsidian, it’s basically an app that lets you organize and manage your files (mostly markdown) with a lot of bells and whistles.

My Obsidian vault is structured around three contexts that map directly to how I actually work:

Client Projects - one folder per engagement, each with a consistent set of files: project context, architecture notes, decision log, session notes, and a roadmap
Internal Projects - thoughtbot team work, PM strategy, team lead responsibilities
Personal - fun projects, personal development, and tracking progress on aspirational lifelong goals like folding the laundry before doing another load

On top of that sits a system layer: a file I called HIVEMIND.md that serves as a master operating index, and a set of contextual modules covering things like domain knowledge, process standards, documentation standards, and writing guidelines.

The structure is opinionated, but that’s the point. When every project folder looks the same, you spend zero time figuring out where to put something or where to look for it.

Claude: maintaining context across projects

The last piece is Claude Projects. On its own, Claude Projects is great if you keep all of the information and context within Claude. However, you start running into limitations once you have multiple projects because you’re essentially starting from scratch for every new project or chat. Also, the more you add to a Claude Project, the heavier every session becomes - burning through context limits faster over time.

Obsidian connects to Claude Desktop via an MCP plugin, so Claude can read my vault directly. When I start a session, it first loads my HIVEMIND.md which instructs Claude to only load whatever project files are relevant (this solves the issue of heavier Claude sessions). That handoff is what makes the whole system feel less like using a tool and more like working with someone who actually knows what’s going on.

The daily handoff: Gemini to Obsidian

I use a tool called Claude Cowork in conjunction with a free community plug-in (Local REST API for Obsidian - github repo or Obsidian page) that runs a daily job to pull new Gemini notes from Google Drive into a dedicated inbox folder in Obsidian. The notes land automatically and I just have to review/file them into the right project folder.

The best part is, even if I forgot to organize the meeting notes in Obsidian, the notes are still there and accessible for Claude to pull.

The part that actually matters

The system isn’t magic and I’m definitely not some jedi of the AI arts. Each tool is doing exactly one job and staying out of the way of the others. Gemini captures so I don’t have to. Obsidian organizes so nothing gets lost and context stays lean. Claude reads that context and picks up where we left off without me having to re-explain anything.

But honestly, the part that made the biggest difference wasn’t any individual tool. It was deciding that I can be the best version of myself when I can actually be present. And whether you’re a fan of AI or not, I think it’s safe to say a lot of the tools that are available today make it easier than ever to do just that.

Last bit of advice is if you want to try a version of this, don’t start with the whole stack. Start with whichever problem is loudest right now. Drowning in missed follow-ups from meetings? Try an AI note taker. Losing track of decisions across projects? Try Obsidian. Explaining the same context to Claude every session? Set up a Project with a HIVEMIND equivalent. Build the connections once each piece earns its place in your own workflow.

The age of snarky UI

2026-04-15T00:00:00+00:00

My husband and I recently leased a new car, a Hyundai IONIQ. This is my first time driving a fully electric vehicle and also my first time in a car with such a gigantic touchscreen dashboard display. It feels futuristic, a far cry from my 2010 Ford Taurus.

A few months into driving it, I encountered a notification on the dashboard. A big orange-outlined circle with a coffee cup icon and the words “Consider taking a break”. I had no idea what that meant. Had I been driving for too long and the car was suggesting I make a pit stop to stretch my legs? Was I going over the speed limit? Did I miss a turn? After a bit of research, I learned it was part of a driver attention system, detecting “irregular behavior” such as drifting out of your lane or not adjusting the steering wheel for a certain period of time. These behaviors may signify fatigue or distraction, thus the nudge (and the coffee cup).

I figured it would be hypocritical to try and snap a photo of this alert while driving, so here is an illustrated rendering of what it looks like and also what I look like when I see it.

But was I tired or distracted? No. I don’t always stay within my lane, especially during Spring season in New England, where I have to narrowly avoid potholes every ¼ mile. I’m less annoyed about it notifying me (and the irony of it needing me to look away from the road to tell me to pay attention). I’m annoyed because of the condescending tone and the fact that I had to do some digging to find out why my car was sending me this message. Can’t you just tell me “stay in your lane”? Why tiptoe around it, especially when coming from a car and not a person?

Condescending or snarky UI copy isn’t a new concept. And I get it – as a business you want to come across more human, which sometimes means adding in humor or culturally relevant conversation patterns. But if that language obfuscates my understanding of the user experience or how to proceed, I’m going to leave very annoyed and not very amused.

A few other examples I’ve encountered in the wild:

Confirmshaming

Confirmshaming aims to guilt you into opting in (or not opting out) of something. Instead of a “No thanks” or “Cancel” button in some type of upsell modal, you’ll get words like “I don’t want to save 20% on the world’s best mystery mayonnaise” or “No, I’m fine with losing customers”.

The undertone: You are naive about our offerings and are passing up something good.

Apologies to jorts lovers.

Paused reminders

Apps like Duolingo and MyFitnessPal engage users with streaks, goal setting, and overall regular logging of your activity. You’ll get reminders through a push notification saying “Hey do the thing you said you’d do” as a way to keep you accountable. Ignore it for long enough, however, and get a final notification telling you they don’t think these reminders are working out for you so they’ll stop sending them. On the surface it seems like a kind gesture, but wording like that was off-putting enough for me to rage delete both of those apps years ago (maybe they’ve changed their copy since!).

The undertone: You are lazy and we’ve given up on you.

Sometimes you have to show your apps who is the boss around here and remove them from existence when they get too snarky.

Over-encouragement

If you wear a smart watch and have notifications for various health trackers, you’ve probably been congratulated for simply walking around your house. Often they come through as encouraging, telling you how great you are for moving your body and taking 35% more steps than average. The reality is that unless you’re intentionally exercising, the messaging feels more like mockery. At that point, I’d prefer it to tell me I’m a disappointment.

The undertone: We are genuinely shocked you left the couch.

What? You don’t get notifications like this, too?

Logically I know the computers are not making a judgement about my opinions, behaviors, or abilities. But I do sometimes feel like my devices are snickering under their breath at what a dolt I am. And perhaps that is because I live in an area that is known for its candor and “kind but not nice” way of communicating. Brusk interactions like that can be off-putting or seemingly rude, but I much prefer it over polite sugar-coated messaging that lacks clarity.

AI in Focus: A new Claude Skill for Rails code audits

2026-04-13T00:00:00+00:00

AI in Focus is our ongoing livestream where we get hands on leveraging AI in real product development. In this episode, Chad flew solo and picked up a thread from our previous episode Claude Code skills for FDA-style documentation. We had touched on the idea of using Claude skills for code quality and auditing, and fellow thoughtbotter Jose Blanco ran with it to ship an experimental Claude skill rails-audit-thoughtbot.

In this stream, Chad installed Jose’s experimental Claude skill and put it though it’s paces auditing our internal operations platform, which is a 10+ year old Rails codebase, with plenty of legacy surface area. You can watch the full replay on YouTube or read on for what we learned about auditing Rails apps using Claude skills.

What are Claude Skills?

Agent Skills are an open, file-based format maintained by Anthropic and open to contributions from the community. At its most basic, a skill is a SKILL.md file with YAML front matter, and a markdown body of instructions. Anthropic has introduced skills across Claude, and Claude Code looks for them in your repo or on your local machine, usually under ~/.claude/skills/.

It’s a bit like human-authored tool calling: The short front matter stays lightweight, and the content only loads when the skill is relevant, or if you invoke it explicitly.

What goes into rails-audit-thoughtbot?

Jose’s new experimental skill encodes thoughtbot-flavored Rails best practice. Let’s allow the code to speak for itself. Here’s the YAML from matter at the top of rails-audit-thoughtbot’s SKILL.md:

---
name: rails-audit-thoughtbot
description: Perform comprehensive code audits of Ruby on Rails applications based on thoughtbot best practices. Use this skill when the user requests a code audit, code review, quality assessment, or analysis of a Rails application. The skill analyzes the entire codebase focusing on testing practices (RSpec), security vulnerabilities, code design (skinny controllers, domain models, PORO with ActiveModel), Rails conventions, database optimization, and Ruby best practices. Outputs a detailed markdown audit report grouped by category (Testing, Security, Models, Controllers, Code Design, Views) with severity levels (Critical, High, Medium, Low) within each category.
---

As you can see, the long description is what Claude Code uses to decide when the skill should be applied; the rest of the file stays unloaded until the skill runs.

In developing this skill, Jose drew on our free books Ruby Science (code smells and fixes), Testing Rails, as well as a security checklist (12 categories with detection patterns), and a report template so the audit output is structured and comparable between runs. Following the feedback from this livestream, he added references/rails_antipatterns.md, a reference drawn from Chad’s book Rails Antipatterns that extends the audit with external services, migrations, performance, and failure-handling patterns.

The skill is open-source and available at thoughtbot/rails-audit-thoughtbot. Feel free to clone or copy it into your skills directory and get ready to experiment.

Installing and running the skill

Chad started from a clean checkout of Hub: He created ~/.claude/skills, then cloned the rails-audit-thoughtbot skills repo into that directory. With a Claude Code session running in the terminal, after some debugging, Chad was able to call the skill using its name slash-command:

/rails-audit-thoughtbot

Tip from the stream: you do not have to audit the whole app on day one. The skill supports a targeted run inside a session, for example:

/rails-audit-thoughtbot audit controllers

Do a code review on my models

What the Hub run looked like

On a full-application pass, the skill took ~5 minutes to generate an audit report that summarized findings grouped by category (testing, security, models, controllers, code design, views) with assigned severities. Chad highlighted a few headline items:

Large Model: a textbook god class on Person which runs to hundreds of lines and many public methods, aligning with what the team already knew from past code reviews.
PORO: many service-style objects flagged for refactor toward ActiveModel-backed domain objects, per intentionally-opinionated PORO.
Missing model specs The skills treated “no _spec per model file” as a gap but Chad dug in and noted this was a bit of a false-positive as view-model style objects had integration coverage instead.
Positives: strong testing culture, good use of calculators, presenters, and query objects, no :focus tags in RSpec (Chad recommends against committing :focus: use line-number runs instead e.g. .\spec_name.rb:34).

Where human judgment still matters

The audit was promising but not perfect. A couple of areas where the skill could be improved included:

Composition vs. wider design: recommendations leaned on extracting small objects with composition, which aligns with Ruby Science. However, for real refactors, Chad reminded us to ask whether the leverage is alongside or above a hot spot before following the first suggested carve-out.
“Issues” that are really clean bills of health: for external API wrappers, the skill correctly said “no changes required,” yet still surfaced them under severity report styling meant for problems. Chad noted that for onboarding to a new codebase, calling out “we looked here and it’s fine” is valuable, but the skill’s report template could be updated separate passes from findings so readers are not misled.

Throughout, the audit was pretty consistent with how we begin client audits at thoughtbot: Move fast for orientation, then validate each area with deep domain knowledge.

How a thoughtbot services audit goes deeper

The stream’s run was overwhelmingly static analysis using Claude Code, which finished in ~5 minutes. Compared with 11–13 minutes for Hub’s full test suite alone, this was a fair tradeoff for a first pass. Chad contrasted the skill with what we typically do on client Rails audits: Run diagnostic tools like rails-flog, flay, Bullet for N+1s, execute the test suite, and attach real coverage metrics, folding all of that into the written recommendations. Following this stream, Jose picked up on Chad’s recommendations and added agentic support for running SimpleCov, and RubyCritic, which rolls-up rails-flog, flay and other analytics tools.

Chad also imagined CI hooks down the road: Not to block merges blindly, but to keep a living quality guide next to our style guide, maintain expert human oversight.

Test it out yourself

If you use Claude Code and maintain a Rails app, clone rails-audit-thoughtbot, run a full or targeted audit, and see how the report reads on your codebase. We would love reactions on the YouTube replay as well as issues and PRs on GitHub.

rails-audit-thoughtbot is experimental. It is a starting point, not a finished product. We actively encourage open-source contributions: Open an issue or fork the repo and open a pull requests with ways you think this Claude skill can work better for your team.

Get in touch

If your Claude Code skill audit surfaces more than your team has capacity for right now, get in touch with us. We have been auditing and reviewing Rails apps for a long time, and are excited to help prioritize what actually moves the needle for your business.

You, too, can make a boilerplate

2026-04-10T00:00:00+00:00

Recently, we released Roux, a set of native CSS styles and architecture opinions. This was born from years of collecting CSS patterns, opinions, and general best practices that worked on virtually any project, no matter the framework or industry. And it’s something we continue to add to and adjust as CSS changes and our own use cases shift.

Roux is what we’d call a boilerplate – a generic and reusable piece of content (in this case, code), that can be used in any relevant project without much alteration. It serves as a solid foundation to build from, without having to start from scratch.

Do you have one or two patterns you’ve used from project to project? Great! You, too, can build a boilerplate.

What is a boilerplate?

Most of my favorite design terminology, like gutters, drop caps, pull quotes, come from newspapers and print journalism. Boilerplate is one of those…well, sort of.

Originally it’s a term from steamships in the 1800s. They were sheets of rolled steel to make boilers to heat water. These boilers generated steam for the ship’s engine.

By the late 1800s/early 1900s, some newspapers were using reclaimed steamship boilerplates for hot metal typesetting in their printing presses. Linotype machines (among a few others) allowed for this typesetting, pouring molten lead into a mold, and producing multiple typesets from that mold. Perhaps there was an article or an advertisement that you’d want to send out to multiple newspapers to set in their printing as they chose. These more widely became known as “boilerplates”, which were more conventional content that could be applied to a number of publications geographically.

A Linotype-set printing form, courtesy of the Science Museum Group.

The term has since grown from its newspaper beginnings, to being used in contract law with “boilerplate clauses” and now in code.

How it works in code

In development, boilerplates are generally defined as reusable bits of code, agnostic to the type of project. It’s something you can start a codebase with or insert along the way as needed. Some are extremely opinionated, some are looser. Some are very thorough, and some are sparse. What it all boils down to (heh) is having something that is useful to you that works in various contexts.

Boilerplates can be useful by:

Standardizing opinions, rules, and best practices by your team’s agreed-upon conventions into a reusable starting point
- Which in turn can ensure a consistent user experience with predictable and standardized interactions and patterns.
Reducing decision fatigue because foundational choices are made (like CSS architecture), freeing you up to focus on more impactful work
Minimizing human error by reducing or eliminating the risk of manual mistakes with repetitive setup tasks
Accelerating onboarding that allows you or your team to jump into a familiar structure rather than inferring conventions from scratch

How you might approach writing your own

You probably already have a handful of code bits or content that you’re writing in the same or similar way over and over again – you just haven’t documented it. Take a look at your own corpus of code and see what emerges.

Audit what you repeatedly build after looking at past projects and identifying a few patterns, structures, or sections you’re commonly recreating.
Capture the annoying or painful bits. Useful boilerplates can solve the setup steps you may dread the most.
Cherry pick from your best work with successful past projects. Sometimes that’s taking patterns in their entirety or frankensteining together bits from various projects.
- For example, I had a modal element where I liked the slide in transition I did in one project and another where I felt it had better accessibility support, so I mushed them together into one pattern.
Strip out the project-specific details for the parts you want to use and leave what’s universally useful.
Include comments, notes, or annotations that explain why things are set up the way they are. This may be useful not just for other people reading your boilerplate, but future you who has since forgotten why you decided on a specific structure or syntax, etc.
Treat it as a living document and update it as your opinions and standards evolve.

Most importantly, know that it doesn’t have to be complicated or involved. Your boilerplate can be just a few patterns that are helpful to just you. It doesn’t even have to be code – it can be designs or layouts that you build prototypes with; it could be structures for documentation that you commonly write out. And while we did just talk about iterating on your boilerplate, it can absolutely be something that you write once and never adjust.

Boilerplates in the age of AI

Why bother writing out a boilerplate if Claude or any other LLMs can do it for you? The output reflects patterns it’s trained on, which are not necessarily your patterns. It doesn’t know you or your team’s specific decisions you’ve made over the years. Articulating what good and useful looks like for you forces you to refine those standards and create a more solid source of truth.

Even if your boilerplate may only have a narrow use case for yourself, opening it up to feedback can sharpen your own thinking. Others might spot a gap or inconsistency you’ve been too close to notice. Sharing can also help others adopt your useful patterns in their own work. More broadly, it invites people to build, adapt, and improve it. You may surprise yourself at how novel your own workflows are to others!