Giant Robots Smashing Into Other Giant Robots

Ship faster: How to unlock development speed in regulated industries

2026-04-20T00:00:00+00:00

A lot of teams assume moving faster means hiring more developers or adopting the latest framework. But in our experience, the biggest drag on development speed is usually upstream. It’s how decisions get made, the way priorities are set, and whether there’s alignment (or misalignment) across teams.

In heavily regulated industries like healthcare, the instinct is often to add more process when things slow down: more documentation, signoffs, and checkpoints. It makes sense on the surface, but what’s frequently missing is a shared way of working.

We saw this firsthand when one of our clients expanded their offerings into the healthcare services space. When we came on board, teams had been missing deadlines, cross-team alignment was breaking down, and a new product initiative was stalling. Here’s how we helped them navigate change to overhaul a waterfall process and increase speed.

The waterfall problem: More documentation, less speed

The most entrenched issue was waterfall culture. Before any coding could begin, product managers were producing lengthy, detailed product requirements documents (PRDs) that tried to anticipate every decision upfront. In regulated industries, there’s real cultural pressure to have everything documented and approved before moving. But those detailed docs become obsolete almost immediately, and they tend to become political artifacts. They’re things teams negotiate over rather than build from.

When we embedded with this client, we broke that pattern deliberately. Rather than exhaustive PRDs, we kept requirements lightweight and iterated. A brief requirement went to the design lead and technical lead first. This allowed them to poke holes and surface unknowns before a developer touched anything.

This was a political change as much as an operational one. Convincing stakeholders to adopt a lighter-touch approach required earning trust fast. To do this, we shipped early and visibly, and this success helped create buy-in around the process changes.

Start by getting the right people in the room

Before writing a single line of code, we typically run a design sprint) with our clients. The first goal is alignment: We identify the actual decision makers, clarifying who has the final call, and establish an executive sponsor. This clarity helps prevent political friction that can derail cross-team initiatives later.

With this client, there were multiple senior product managers overseeing their own roadmaps with little cross-team coordination. We met with the executive team and asked direct questions about who ultimately owned decisions. This helped us understand the management layers above where the work happened, so we knew who could help us move things forward.

From there, we facilitated a problem statement exercise). The goal was deceptively simple: define who has the problem, what the problem really is, and why it matters. We kept refining it until the group landed on something they could rally around.

That statement lived at the top of every FigJam board for the duration of the project. Whenever a new request surfaced, we’d ask: Does this address the problem we agreed to solve? It gave everyone a principled basis for saying no.

Make the big picture visible

One exercise that consistently generates cross-organizational buy-in is mapping the entire critical path, including every touchpoint, product team, and dependency, on a single board.

With this client, we mapped the entire operating picture: every product, every team, every place the new work would borrow resources or touch existing systems. Invisible interdependencies became suddenly obvious. PMs who’d been quietly absorbing off-roadmap requests suddenly had evidence to escalate.

Change management is part of the work

Transitioning away from waterfall in a regulated industry isn’t just a process problem; it’s a change management problem. The documentation, approval chains, and signoffs exist for many reasons. The goal isn’t to abandon rigor; it’s to be rigorous about the right things at the right time.

As an outside consulting team, we have a structural advantage. We’re not protecting our careers inside the organization. We can push back on scope, name the political dynamics slowing things down, and advocate for PMs getting squeezed between competing priorities. These are conversations internal teams often can’t have. We used that position deliberately with this client.

What we leave behind

We closed out this engagement by establishing a lightweight cross-team coordination structure. It was an as-needed touchpoint where all teams with a stake in a shared initiative could surface blockers, get decisions made, and flag dependencies before they became problems. It gave individual PMs a direct line to executive attention rather than things stalling at the manager level. While we modeled less process overall, we also left behind some techniques like this to help clear blocks as needed.

The goal of any engagement isn’t just to ship code. It’s to model a way of working that teams carry forward long after we’ve handed things off.

Ready to help your team move faster? Let’s design and develop great products while leveling up your team.

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.