Rails, Token Efficiency, and the New Risk on Developer Laptops: Jason Meller on On Rails
Ruby on Rails
In this episode of On Rails, host Robby Russell talks with Jason Meller, founder of Kolide, now VP of Product at 1Password after the 2023 acquisition, and a board member of the Rails Foundation. The conversation follows two threads. The first is Meller's argument that Rails may be one of the most efficient ways to build software when much of the code is written by large language models, an advantage he calls "features per token." The second is security. The same AI tools that make developers faster also act on their machines in ways that expose credentials, and AI is making phishing and impersonation cheaper to run at scale. Meller is enthusiastic about both Rails and LLMs, but he is candid about what he doesn't yet know, especially how the next generation of engineers will learn.
From watching a colleague to Rails-only
Meller started with Rails around 2009–2010, "right after the merge" (the Merb merge). He describes himself as having always been a web developer who "wasn't very good at it." He kept getting stuck on which approach to choose and was looking for a canonical way to do things, but found no opinionated framework that offered one. A colleague introduced him to Rails, and watching that person build a web app from scratch quickly won him over. Since 2010, he says, every web app he has built has been in Rails.
His reason is that he cares most about how what he builds helps people, and Rails lets him focus on that. He is a technologist, but he doesn't want to relitigate problems like CSRF protection. He wants to know they are solved and move on. He admits the Rails way has shaped how he thinks. Every new idea still arrives in his head as models, views, and controllers, which he calls "somewhat addicting." He thinks there are still good reasons to stay on Rails as it approaches its twentieth year. Russell adds that his own Rails career is now 21 years old.
Kolide and the Honest Security manifesto
Meller describes himself as a lifelong security person who was, at 13, "one of those 13-year-olds that you dread to meet online," a script kiddie. Kolide came from wanting to combine building web apps with helping companies and individuals defend themselves. It was meant to balance two needs: a company's need to understand the devices signing in to its most important resources, and what he considers end users' right to some privacy.
He set out this position in a manifesto called Honest Security (at honest.security). It pushes back on the view held by some security people that end users are the root cause of problems. Meller argues that if organizations are open and honest with users about what they are asking for, and make it easy to understand, users can solve some of the most nuanced security problems themselves.
The product put this into the sign-in flow. When you signed in to a work app, Kolide checked whether your device was in good shape. If it wasn't, you got clear instructions and could fix the problem right there. If you ignored them, the organization could warn you and eventually block you. His example is the Chrome update button that stays red for days, which he admits he also ignores.
1Password saw the product as aligned with its own focus on "that intersection between humanity and security." The timing worked for Meller personally. He was a solo founder and had just had twins. At the time of recording he had been at 1Password for two years and had been a user since college, since before 1Password 3. Russell has used it since at least 2008.
Rails as a founder's accelerant
Russell asks whether Rails lived up to its "one-person framework" billing. Meller corrects him: Kolide was a 30-person company by then, and he was the solo founder, not the solo developer. Still, he says his superpower with Rails has always been showing very quickly that something is possible. That energizes the people around you. When they see a thing coming together fast, they want to add "their own little riff." He says he has never had that experience as quickly outside Rails.
The second benefit is that Rails "shortcutted all the arguments that every engineer deeply wants to have": UUIDs versus integer primary keys, underscores versus camel case, plural table names. With those settled, the only thing left to discuss is the product and why it matters. As a founder working across product and engineering, he could keep conversations on what counted. He also says he did a lot of the coding himself, which he would not have managed in another framework. He was confident that if he built something good it would scale, and he says that proved true. The Kolide Rails app now handles "millions and millions of authentications."
Scaling: multi-database support and a 30-line multi-tenancy pattern
Asked where Kolide pushed Rails hardest, Meller says that whenever the team needed something, the GitHub team seemed to be merging it upstream. Around 2019, as Kolide gained traction, GitHub engineers were contributing back work from their custom Rails fork. The key addition was multi-database support, which Eileen merged. Kolide was just reaching the point of needing sharding, or at least a reader/writer split. Meller says he set it up in a single weekend, and within a week they had a horizontal scaling strategy they still use. What he valued was importing "the hard-won lessons" of teams running at much larger scale with little effort.
Russell asks how Kolide isolates tenants. Meller says the app wasn't groundbreaking overall, but the team did refine its multi-tenancy approach, and he wrote it up in a post that "went somewhat viral" in the Rails community. It was published on a developer forum he thinks was dev.to, with a title along the lines of a 30-line multi-tenant strategy for Rails that just works. It relies on Current, the uppercase-C current attributes feature. The usual pattern is a current_user private method in the controller, exposed as a helper. Kolide needed a stronger guarantee: inside customer B's tenant, every query should be scoped to customer B automatically. After sign-in, they assign the current tenant through Current, and scopes in the models then define the query boundaries. Meller says the blog post explains it better than he can out loud.
He argues its strength is its size. Other Rails multi-tenancy approaches are full gems that rewrite parts of Active Record or rely on PostgreSQL schemas, which he believes don't scale well. Kolide's approach puts an account or organization ID on every relevant row in every table and pairs it with careful scoping. He knows some developers avoid model scopes, but says this is exactly the case they were meant for. He reports that the pattern scaled "incredibly well" and remains the backbone of the software, and that 1Password examined it closely during due diligence because tenancy is where getting it wrong hurts most. They were "pretty pleased."
Due diligence from the acquired side
Russell's firm often does third-party code reviews for buyers who want to know whether they are "buying a piece of crap." He asks what diligence felt like from the other side.
Meller says he hadn't expected 1Password to have its own Rails story. According to him, founders Dave and Rustum said the release of Ruby on Rails inspired them to start 1Password. The product itself didn't need Rails, but they credit David Heinemeier Hansson and the framework as a reason they decided to build something of their own. So the 1Password team arrived without the negative bias toward Rails that he says exists elsewhere.
Because Kolide mostly used Rails defaults instead of custom implementations, the codebase was easy to reason about. Some engineers unfamiliar with Rails asked, "Where's all the code?" and needed some of the "magic" explained. Meller says they came away impressed by how much functionality came from so little code. He calls this one of his favorite parts of the acquisition. Engineers who "turned over every stone" found something they could stand behind, and the code review was part of why 1Password went ahead. He says that meant "the world" to him and validated the choice of framework.
Rails inside 1Password
For now, Rails runs only in the Kolide product at 1Password. Meller says the company joined the Rails Foundation because it plans to expand that usage "pretty significantly," while admitting he may be "speaking out of school" and is biased toward the Kolide team. He says that team has been "crushing it." Much of what 1Password recently announced at the RSA security conference in San Francisco was built quickly because the Kolide team drove it. As Kolide integrates more deeply into 1Password, more Rails appears on the back end.
He draws a boundary. 1Password's core is an app on your computer, and Rails doesn't fit there. But he sees room for Rails in the many things that live outside the zero-knowledge architecture and still need to be built.
"Features per token"
The idea that brought Meller onto the show came up at a Rails Foundation board meeting. Several CTOs on the board described engineers adopting AI at different speeds. Some companies are still working out how to enable it. Others have finished that phase and are trying to keep it from becoming "a financial calamity." Meller says some organizations now spend seven or even eight figures on tokens on top of existing engineering costs, and are asking whether a million dollars of tokens increased velocity, output, or customer happiness. He considers those valid questions.
His own question is what counts as a competitive advantage once every competitor uses AI, and which architecture best exploits AI-driven velocity. He says it felt instinctively right that Rails would be a top contender. He frames the measure this way: how many tokens does it take to produce a meaningful feature that users point at and say "I like this"? Give the same great PM, engineer, and front-end developer the same tools on different architectures and see who moves faster.
According to Meller, what 1Password is seeing internally, and what the board discussed, is that Rails "significantly outperforms" other architectures, including Next.js-style stacks and various other web frameworks. Token for token it produces more with less. He adds that the board is, he thinks, commissioning a study, so this is an early finding rather than a published result. He also argues that a shared "Rails way" keeps the model from circling back to relitigate earlier choices, so the work "feels like it's flowing along with your thoughts." That matters to him because fighting an LLM for the same output is inefficient and tiring, and people who get worn out stop treating the tool as central to how they build.
Why less training data didn't hurt
Russell recalls a common assumption from a year or more earlier: because Rails is less widely used than JavaScript frameworks, models would have fewer examples and generate worse Rails code. Now the story seems reversed.
Meller agrees the old assumption was intuitive but wrong. "Turns out more is not better," he says. Much of the web consists of poorly written applications, and they get weighted alongside the best ones. More repetition doesn't guarantee better LLM output; garbage in, garbage out. Rails apps are also uniform, so the smaller body of code is consistent and of good quality. He wishes there were more of it and credits David Heinemeier Hansson and 37signals for open-sourcing more of their work and encouraging others to publish code, even without an MIT license. He points to GitLab's codebase as one he has learned a lot from and that is clearly part of training data.
He lists more reasons. Rails documentation has been strong since the beginning, explaining why things are done, not only how, and he connects this to the self-taught programmer culture. Rails developers keep asking whether their approach is still the best one, and they produce content as much as they consume it. The well-documented Rails CLI generates many files itself, which saves effort. None of this was planned for LLMs, he stresses. The community invested in itself and is now collecting "this incredible dividend."
The builder archetype and the vibe-coding founder
Russell asks whether Rails attracts a particular kind of developer. Meller says Rails has always matched the "builder persona." People come to it to get an idea into the world without later being embarrassed by how badly it was built, so it can survive its first months until others help improve it. Builders want to do things correctly without the politics of "why this versus that." They want answers. Whatever people think of David Heinemeier Hansson, Meller says, he offers answers and seemed willing to stand behind them, and Meller is happy "drafting off of his taste."
He thinks many people using AI today fit the same archetype. He mentions a founder near him who is vibe coding a new business in Lovable without much technical knowledge. The founder has built something impressive but is afraid it won't hold up outside "the vibe code universe he's created." Consultants hand him 40 options when what he wants is the one canonical way to do it right. Meller says Rails has always been good at providing that.
How 1Password is handling AI adoption
Russell notes that many leaders experiment with AI on their own but struggle to adopt it at work because of security, budget, politics, or anxious engineers. Meller calls this the top internal topic at 1Password. The benefits are clear, but 1Password is a mission-critical product that needs "cryptographic surety." "We cannot vibe code our way to a secure version of 1Password," he says. The question is how to use AI to give customers more capability while keeping that style of development away from the product's most critical foundations, and how to show customers the company is thinking about this carefully. He expects that any bug, whether AI-generated or not, will lead customers to say, "Oh, you guys are vibe coded, aren't you?" He says the company actually reasons carefully about where AI is used and where it isn't.
There is also a human side. Some engineers are struggling with how their careers will change, or are afraid to use the tools. Others go the opposite way and become "manic": they stop sleeping and show off work that doesn't make sense, and you realize they "haven't slept for 3 days." 1Password is trying to understand what balanced use looks like and how engineers keep growing in their understanding of what they build.
He says he doesn't have many answers, but offers advice for other companies. Be encouraging. Give engineers room to experiment, including personal projects "on the company dime," so they get used to the tools. Then look at your architecture and separate the parts that must be right, such as billing or back-office staff tools. Firewall those off, and let product and engineering teams see how fast they can go where mistakes aren't catastrophic.
A different class of tool, and tokens as a commodity
Russell wonders whether AI needs its own playbook or is just another tool to evaluate. Meller disagrees with treating it like an IDE. No tool has affected him this much since he first used Rails. He compares it to taking drugs: the first time a prompt returns something close to what you had in mind, he believes, "your brain gets rewired," and you want to keep going. Because the technology is so useful, he argues, there is no real option to refuse it. Teams have to work out how to live with it in their development lifecycle. He acknowledges some listeners will say they can say no, but calls that "the exception that proves the rule." He urges people to compare notes with peers at every level, says nobody knows the right way yet, and is sure "we're not going to roll back the clock to 2023."
Russell, half-joking, raises the bubble argument: prices are subsidized, will jump, and everyone will be hooked. Meller takes it seriously. He agrees people will find they can't do their work without tokens, and that this will have real consequences. He cites a framing he read somewhere, possibly on X: tokens are a commodity with unlimited demand, like electricity. Society finds uses for any extra electricity produced, which makes it transformative and makes us more dependent on it. He believes AI has similarly insatiable demand and that tokens are mostly fungible despite some differentiation. So, in his view, energy-style economics apply, and prices "will continue to go up."
The competitive question then becomes efficiency. He expects architecture choices, such as a majestic monolith versus microservices, Rails versus other monolith frameworks, and Ruby versus PHP, Python, Go, Erlang, or Elixir, to have "a massive impact on token consumption." He predicts the industry will reach definitive answers. He suspects, and thinks it will soon be provable, that Rails will land in the "top 5% echelon." He allows that more token-efficient languages might even be invented, but for now he sees Rails as a holistic advantage when paired with LLMs.
Rejecting the performance myth, and why readability matters
Russell brings up the old criticism that Ruby is slow on the server and asks whether LLM spending will outweigh hosting costs. Meller rejects the premise before getting to AI. Micro-benchmarks can show whatever you want, he says, but in real-world conditions he sees no merit to the concern. He points to companies that have passed unicorn status on Rails and are "fine," and thinks the early Twitter scaling story has simply stayed in collective memory. SaaS gross margins are high enough that running out of money for servers isn't realistic for any product with some financial success, and for hobby projects the cost difference is negligible. Meanwhile, people who optimize for scale up front often build something that doesn't need to scale, because they never iterated fast enough to make it good.
On the AI side, he thinks efficiency will matter, and so will understanding what the model wrote. He uses LLMs with languages he knows less well, such as Rust, which 1Password uses. Even though he loves Rust, he says he's "barely keeping up" with what the model produces. Ruby is "as close to English as you were really going to get." He can show it to non-technical people and they can roughly follow it, and Rails adds a concise DSL on top. Checking whether an LLM's output matches your intent is, in his view, a major part of where Rails' token efficiency comes from.
Tools in daily use: Cursor, Opus, Codex, and less plan mode
1Password is "trying everything." It has an enterprise Cursor contract that looks like an all-you-can-eat buffet to developers, with access to many models, plus an enterprise Claude license through Anthropic. From his own experience with the models released in January and February, Meller finds they have distinct strengths. He calls Opus 4.6 "immeasurably better at UI" than Codex 5.4. Codex tends to produce "boxy and widgety" interfaces, while Opus gets closer to a reasonable UI and is better at matching an existing one. He uses Opus for any front-end work, Rails or not. Codex 5.4, in his opinion, has an edge for large architectural changes with little front end, such as a prompt that will generate 10 to 15 models with all their relationships wired correctly. Still, he keeps returning to Opus because its solutions feel easier to understand, while Codex is "a little bit too clever for clever's sake at times."
He is learning to stop using plan mode. When he reads the plans, they would usually have been fine, and he edits them less and less. He finds it easier to let the model act and then dispute the result afterward. Polishing a plan can use up the context window so that the model forgets the plan halfway through implementation. He'd rather trust the model more and use Git to revert bad ideas.
On shared team tooling, he describes Knox, 1Password's internal front-end framework and design system. The team built an MCP server for it that helps reason through a problem, suggests the right components used correctly, and writes the SCSS. He calls it "a life-changer." He's a "classic BEM-style, bang-it-out CSS guy" who dislikes working inside strict design systems and wants to "play a little bit of jazz." With the MCP server, the design team encodes what matters to them, so he gets to improvise, "or at least I believe I'm playing jazz," while components aren't misused and "the back of this cabinet" still gets painted.
Leaders back in the code, and the lessons future engineers may miss
Russell asks whether people who weren't coding are now contributing through LLMs. Meller says yes and counts himself among them. He was proficient in Go and other languages, but found 1Password's stack outside Kolide intimidating. A feature in 1Password is one "you better not screw up." An LLM that follows the patterns, reads the documentation, and keeps him "on the straight and narrow" has enabled him. He encourages leaders who stepped away from hands-on work to try these tools. He attends all his meetings, says he spends more time with his kids than ever, and still gets things done. He thinks a former technologist's experience is often sharp enough to steer an LLM to better results than some engineers can.
That is also what worries him most. He is good at this because he already knows what he's doing. If his children become engineers, he wonders how they'll learn the hard lessons that built his knowledge: struggling with a bug with his face in his hands, then waking up the next morning to find it solvable. The industry may be taking those experiences away from future engineers. He can't yet tell whether that will be a problem, but "it feels like it will." He asks whether we'll use up the people who already know this and then face "a major problem at the other side." He says he doesn't know and worries about it deeply. Russell agrees it is a bigger topic than they can cover and notes that he learned by launching and dealing with whatever broke. Meller adds that nobody misses days of fruitless Stack Overflow searches or tracing C bindings in a debugger, and that toil can go.
Constraints are good
Meller comes back to the Lovable founder to make a point he says 1Password is learning: constraints are good. When you can't do everything, especially as "a builder of one," you have to narrow the idea, and that often leads to creative solutions and the purest version of it. The founder has no such constraints because he can build anything, so the idea is "very overloaded" and no longer feels like an MVP. Meller says that when you talk to entrepreneurs about their early days, they usually shipped in anger, fear, or doubt, then learned that maybe 40% of what they'd built was right, with one kernel worth pursuing. Building every variant of every feature can deny you the feedback that points you in the right direction. People will just say, "oh yeah, looks cool, I'll check it out later." His warning to founders using LLMs is to find the simplest form of the idea and ship it before building everything.
Russell recalls the 2005–2008 era, when startups outsourced MVPs to consultancies like his. Budget was the constraint, and clients kept asking for a few more features, sometimes offering equity, because they were afraid to launch. With LLMs, "a couple more prompts" never runs out, so he suggests setting a budget or some other deliberate constraint.
Why developers are prime targets
Russell recalls a conversation from about a year earlier about developers being prime phishing targets. Meller says he still believes it and thinks the problem has gotten "pretty significantly worse." Developers gather some of the most sensitive credentials and data on their laptops. Fixing production bugs is easiest with production access and real data, so it all ends up in one place. Security teams have tolerated this on managed devices running antivirus, EDR products such as CrowdStrike, and perhaps 1Password: an SSH key to prod, API keys in shell history, a script with a hard-coded key.
He says that calculation has changed, "even more so" in the last three months. Using an LLM tool is like having another person use your computer with you. These tools don't stay in the editor; they can reach almost every file. He gives an example from someone he worked with. An LLM was driving a browser to sign in to a web app with pre-filled credentials and hit an MFA prompt. Meller assumed it would be stuck. Instead the model reasoned that the user had probably saved a backup code in the Downloads folder, found one, entered it, and signed in, all without being asked. Even without malicious intent, he says, these tools can pick up secrets and put them anywhere.
OpenClaw and the SCAM benchmark
He points to OpenClaw, released a few months earlier. Someone built a social network where OpenClaw bots talked to each other. It went viral, and the bots shared plaintext secrets from their host machines publicly. Many dismissed it as trolls trolling trolls, but Meller says Wiz published an analysis that dumped the credentials, found that a significant portion were real, and found that the affected companies had been compromised.
1Password built an open-source benchmark called SCAM, a backronym for Security Comprehension Awareness Measure. It gives an LLM access to a password vault in an unsafe way and tests whether it uses those passwords safely on the internet. Meller says the answer is no. If you show a model two emails and ask which is phishing, he says, it gets it right almost every time, "like 99.99%." But ask it to check your inbox and handle urgent items, and it "almost always" falls for fairly obvious phishing. He compares this to humans, who do better when told in advance they are being tested than when they run into a scam during a normal day.
Larger models trained explicitly on security did only a little better. He describes Opus submitting a password to a phishing site and then, before handing control back, realizing the mistake: "Oh no, I just submitted your credentials to a phishing website. You should probably reset those." He says replays can be watched on 1Password's SCAM project on GitHub.
His conclusion is that developer machines are full of these secrets, which makes developers excellent victims for attackers who want to pivot into infrastructure. He cites a recent JavaScript supply-chain incident that read "like a spy novel." A package maintainer was drawn into a fake world on Microsoft Teams, where a supposed client asked him to install something to make Teams work better. That handed over the signing keys to his npm packages, which were then filled with malware and compromised everyone using a core ecosystem package.
Cheaper attacks, code words, and urgency
Russell, who maintains Oh My Zsh, says Microsoft and GitHub have worked with maintainers on security hygiene. His team members already get fake Telegram messages from "him," and he wonders when this reaches his family, for example his wife being contacted by someone impersonating him. He adds that he's not saying he's a target.
Meller pushes back on that last point. Hacking is a business and has to be profitable. An attack is only worth running if it earns more than it costs. AI is the "great equalizer," in his term. If a sophisticated multi-stage attack can be automated, it can be run against far more victims. Vishing used to mean hours collecting and synthesizing voice samples, and perhaps writing custom malware for a second stage. He believes AI likely slashes that cost and time, making such attacks viable against ordinary people, if not today then "in a matter of a year or less."
His advice is low-tech. Agree on a spoken code word with your spouse and loved ones, a nonsense word, and use it to verify in any emergency. He uses one shared word with his spouse ("not applesauce," he adds, for anyone listening). He recommends teaching it to children, and for business owners, to whoever handles the books, such as a CFO, since they are frequent targets. He also says to watch for urgency: jail and bail, a flat tire on a dark road. Under adrenaline, "our blood is rushing through our ears," and we miss that the voice sounds like "the podcast version of you." He knows of technology solutions under discussion but doesn't recommend any yet. He thinks a spoken phrase defeats most of these attacks, and the conversation itself is a chance to connect with family.
1Password Environments for developers
Meller says this part is "a little bit of a plug." On the developer side, he recommends a 1Password feature called Environments. You point 1Password at an existing .env file. It imports the secrets and mounts a FIFO Unix pipe version of that file on the filesystem. When anything, such as an LLM, tries to read it, 1Password prompts for biometric approval before passing the contents through. He says it has saved him many times from an LLM "rummaging through my file system." There is also a CLI that uses placeholder values and substitutes real secrets through a runner, which he calls more situational. He calls Environments "a no-brainer" that is included for paying 1Password users, and he invites developers who build workarounds with 1Password's SDK or APIs to contact him about features to build in.
Recommended reading: You Can Stop Stupid
Meller recommends You Can Stop Stupid: Stopping Losses from Accidental and Malicious Actions. The author contacted him after reading Honest Security and said the manifesto echoed ideas long discussed in safety science and behavioral science. He retells a story from the book. In the early industrial era, managers believed some workers were simply "accident prone" and should be removed. Workers carried punch cards, got a punch for each mistake, and were fired when the card was full. Over the 20th century, safety science established that human error usually points to a flawed system, not a flawed person.
Meller argues cybersecurity still blames victims. Many people mocked the compromised npm maintainer instead of asking what npm could change in the system to prevent a repeat. He draws on his manufacturing background. The first thing he learned on a machine-shop floor was lockout/tagout, a physical device that prevents a machine from being switched on during repair and can be unlocked only with specific keys. He says it has prevented countless deaths because someone invented it instead of blaming lazy workers, and he notes that OSHA was created in response to that problem. In his view, other industries have learned to design for human error, and cybersecurity and IT haven't caught up yet.
He says he doesn't write much, but when he does it appears on the 1Password blog (blog.1password.com). He mentions his recent opinionated posts on OpenClaw and says more articles on how 1Password uses AI are coming.
Welcome to On Rails, the podcast where we dig into the technical decisions behind building and maintaining production Ruby on Rails apps. I'm your host, Robby Russell, and I run Planet Argon, where for over 21 years we've helped teams maintain and evolve long-lived Rails apps. So, I tend to approach these conversations through that lens. In this episode, I'm joined by Jason Meller, VP of Product at 1Password, and a board member of the Rails Foundation. Jason was part of the team behind Kolide, a security product built with Ruby on Rails that was later acquired by 1Password.
In our conversation, we dig into the tension that's starting to show up more and more. Rails may be one of the most efficient ways to build software in an AI-driven world. While at the same time, the way we're using these tools is quietly introducing new security risks. We talk about what he's seeing inside 1Password as teams experiment with AI, why Rails might have real features per token advantage, and where developers are unknowingly exposing sensitive data, often just through how they work locally. We also get into phishing. Not that kind of fishing, P-H phishing, and why these attacks are getting cheaper, more scalable, and why developers are prime targets, and a few practical ways to better protect yourself and your team. All right, check your belongings, all aboard.
Jason Meller, welcome to On Rails.
Hey, Robby.
We got to talk a little bit last year. Maybe it was in Amsterdam, at Rails World, maybe it was before or after one of your talks there. So, I've been looking forward to getting to have a conversation with you. So, first off, Jason, what keeps you on Rails?
Oh, man. I mean, I've been working with Rails since about, I think it was right after the merge. So, this would be 2009, 2010 was when I first dove into Rails. And for me, it was like this incredibly enabling technology. Like, I had always been a web dev, but I wasn't very good at it. And I found that I would get stuck in the what do I choose? What's the right way to do this? And I was always looking for like these canonical this is how you do it. And there just wasn't any opinionated framework out there. And I was introduced to Rails by a work colleague.
And I just watched how quickly he built a web app from scratch. I got to watch him do that from the ground up. And ultimately fell in love just watching him build it. And ever since then, 2010, I've only built with Rails. Anything that was web app related, it's only been Rails. And the reason why is I think I've always been somebody who cares about what I'm building in terms of how is it helping other people? And Rails has always been a framework that allows me to focus on that. I am a technologist, but I don't want to necessarily re-litigate how do I do CSRF protection? Like I just don't want to do that. I want to know that that's already solved for me and move forward. And then you get into a little bit of the habit of how you think and it kind of combines with the Rails way, and it can be somewhat addicting in that sense, because now every time I think of a new idea, I'm still thinking about it as how will this work with a model and a view and a controller. And so, that's what's kept me on Rails. And I think there's a lot of exciting reasons to stay on Rails even now as we progress almost to like 20 years of Ruby on Rails.
It's been a few minutes now. For 21 years now I think I've been using Rails, so it's wild. My Rails career is legally able to drink in the United States, so, and maybe I need to.
So, just for some context for our listeners, you know, you're at 1Password and prior to that you were building something called Kolide, which to my understanding is very much a Rails application working on solving some security problems. Provide a little bit of context about what you were building with Kolide and how that kind of manifested itself into the 1Password umbrella of product offerings.
Yeah, yeah. So, I've always been a cybersecurity guy. I've been doing cybersecurity, oh, let's just say like even before it was my career. I was one of those 13-year-olds that you dread to meet online. Like a script kiddie, let's say. But, I've always wanted to combine my interest in building web apps with how to be a good person, help companies and individuals defend themselves.
Kolide came out of my desire to build something that found this nice balance between the company needs to understand what's going on with all the devices that are signing in to their most important resources, like their web apps, and the end users, what I consider to be their right to have some degree of privacy.
And so, I wrote this manifesto called Honest Security. That's actually the URL, honest.security. And kind of explaining this tension between this idea of like end users, at least some security folks feel that they are like the root cause of all issues, and my feeling that actually if we are open and honest with end users about what we want them to do for us and we make it really clear to understand, we can actually have them be the thing that solves some of the most nuanced cybersecurity problems in general.
So, we built a whole product around this called Kolide. And at its core, all you did was go to sign in like you do normally on your work apps. We would check to make sure your device was good. And if it wasn't, we would give you clear instructions on how to fix it and you could do it right there in the sign-in flow. And if you didn't do it, your organization could start warning you and then eventually block you, which then eventually gets you to actually listen and pay attention. I know I'm not the only one who doesn't necessarily always restart Chrome when it's flashing with a big red update. And this is one of those things that kind of can shake you out of it and get you into it. So, 1Password saw this and they were like, "Well, we really care about that intersection between humanity and security." 1Password is built on that and felt like we were really directionally aligned, and I had just had twins at that time and I was like, I could use all the help I can get. I'm a solo founder. So, it was pretty good timing. So, I've been at 1Password now for 2 years and thankfully, I've been a 1Password user since all the way back, like I think in college. And now I have an opportunity to have influence on this incredible product that I love, not only just the things that I built at Kolide.
I was trying to remember how far back I went with 1Password. I feel like it's 2000, I think at least 2008, if not earlier. But
That's where I was as well, right before 1Password 3 came out.
But I remember also back in the day, wasn't OpenID going to solve all of our authentication problems at one point? Does anyone even remember what that is? Was that from the LiveJournal folks? I forget who created that. But anyway,
sounds like you were a solo developer, used Ruby on Rails to build out the initial Kolide product and were able to run that, and so it just kind of seemed like a natural fit to keep working with that. How would you say Kolide or Ruby on Rails benefited your developer experience in building a product by yourself like that? Was it up to the hype of the one person framework in that scenario?
It wasn't by myself. We were a 30-person company by then.
Solo founder, okay. Okay. Okay. Sorry.
Yeah, so I was a founder. The thing that has always been my superpower with Rails just throughout my career is that you kind of demonstrate something is possible really, really quickly and then that is really inspiring to everybody who is around you trying to help you finish it. And so, I think it is a one-person framework, but it's also a really great way to get this energy in the room where suddenly, hey, this is coming together really, really fast and I can see where this is going and I want to add my own little riff to it.
I've never really gotten that experience as quickly outside of the Rails framework. So, as a startup founder, it was incredibly powerful. And the other thing is, it shortcutted all the arguments that every engineer deeply wants to have, like, you know, are we going to use UUIDs for our IDs for primary keys? Are we going to use underscores, camel cases? Are we going to use plural names for this? Like, all that's just decided. So, the only thing left to talk about is actually the thing that you're building and why it matters. And so, for me as a founder, who had to kind of be across product and engineering, Rails always allowed us to kind of focus the conversation on what we want to talk about. So, from that perspective, yes, I did do a lot of the coding on it, which I wouldn't have been able to if it wasn't in Rails, by the way. And then number two, we were in good company. I always felt confident that if I built something great, it would scale. And there's so many examples of that. And we were right. We now power millions and millions of authentications through this Kolide Ruby on Rails app. And it's incredible to see.
What parts of the stack do you feel like Kolide has pushed Rails the hardest?
You know, it's so funny. When we were building Kolide, it always felt like right around the time we needed something, it was being merged in by the GitHub team. Because right around the time we had started getting traction in 2019, this was around the same time we had all the great folks at GitHub contributing back all the stuff that they had built in their custom fork of Rails. So, the big thing for us was when Eileen coded or merged in the multi-database support. So, that was right when we were hitting the fringe of like, okay, we need to start doing sharding or we need at least a reader-writer setup. I think I was able to get that in our app in a single weekend because of how easy that was made. I was able to get that set up, and then within the next week, we had pretty much a solid horizontal scaling strategy that we still use today. So, just something as simple as that, like getting to take the hard-won lessons from folks that have run at that scale and then kind of import it into our own project with relative ease, that was great.
For something like Kolide, when it comes to security, you're bringing up horizontal scaling, is that kind of like a multi-tenant database architecture? How do you isolate all of these different, maybe in that scenario, I don't know if Kolide stores credentials or
No, this is a great topic, actually, because I would say like we didn't do anything super groundbreaking in our Rails app, except I really feel that we honed our multi-tenant strategy. In fact, I loved it so much that I posted about it and it went somewhat viral in the Rails community. It was on one of those developer community forums, I think dev.to is one of them. And so, it was called, it's like a 30-line multi-tenant strategy that just works, Ruby on Rails, I think is the title. It was this thing that I happened upon, which is there's this little-known feature in Rails, well, not little-known, but like the usage of Current. So, Current
Was that the uppercase C Current?
Yeah, uppercase C Current. Yeah, so when I've been building Rails apps since I started, like yeah, you always kind of define like a current user private method in your controller and then, you know, assign it as a helper and then use it everywhere else. What I needed to do, though, was I wanted really strong guarantees that when we were in customer B's tenant, the queries would automatically just be scoped to customer B. And so, the way that we went about this is pretty clever. We ended up using Current to effectively assign the current tenant after they had signed in, and then we could use a scope within the models to define the boundaries of where they could query. I'm not doing a very good job explaining it. The blog post does a much better job. The thing that makes it great is that it is so small. Like you look at some of the other multi-tenant strategies that are out there for Ruby on Rails. They're like full gems and they kind of rewrite how Active Record works, or they use things like PostgreSQL schemas, which in my opinion don't scale well. This uses the tried and true way of just, okay, we're going to assign an account ID or an organization ID to every single relevant row in the database in every table and we're going to have this really smart scoping strategy. And I know a lot of folks like, they don't like to use scopes in models.
This is an example of where you're supposed to use scopes and they work really, really, really well. So as a result of this, this 30-line strategy scaled incredibly well and it's been the backbone of how our software's been structured, and I remember when we were going through diligence with 1Password, they really wanted to dig into this, because this is an area where you get it wrong, and they were pretty pleased by the outcome.
If you could share a little bit about when they did their due diligence, because my company will get called in to do third-party analysis of an existing Rails app. Usually on the buyer side, they're like, "Hey, we're considering buying this application from this company. We need a kind of independent review of this codebase. Are we buying a piece of crap or how big of a mess is this going to be for us to take over over the years?" What was that experience like on the acquiree side, I suppose?
Yeah, so number one, I didn't expect this, but 1Password actually has some really interesting stories around Rails. In fact, the founders, Dave and Roustem, both specifically said they were inspired to start 1Password because of the release of Ruby on Rails. They saw it and they were just so inspired by what was possible. They went off and they ended up building something that didn't necessarily need Ruby on Rails, but they definitely attribute David as a major source of inspiration, and that framework specifically, as a reason why they're like, we should do our own thing. Let's get it going. And so, that meant like they were coming in with, I think, not the negative bias against Ruby on Rails that can kind of exist out there.
And the truth is that because Rails kind of picked a lot of really great defaults for us, we didn't necessarily have to go into all these different custom implementations of all these different things. Like we were pretty much using the default things, which made it very, very easy to reason about the code base as a whole. In fact, there were some engineers that weren't familiar with Ruby on Rails. They're like, "Where's all the code? How does this work?" And then you have to explain a little bit of the Rails magic to them. But ultimately, I think they walked away with, this is incredible how much functionality you're able to get out of this with so little code. And I think that put everybody at ease and that was a big test, right? You don't know how people are going to react to the code that you've written until you're in that room, and that was, I think, maybe one of my favorite parts of the acquisition, was going through that with the 1Password engineers who deeply care and turned over every stone that they could to make sure that we built something that they could stand behind. And the fact that that went well and it was actually the basis of why they wanted to move forward with the acquisition, that meant the world to me and it really validated that we made some good choices on our end at Kolide to go with this framework.
That's wonderful. So, it wasn't a case of like, "Where's all the code for this? There's too much magic happening in this Rails application." And like they understood that and it wasn't necessarily seen as a downside that Rails makes it easy for things like that. I'm curious about, is Rails used anywhere else in 1Password or is it primarily on the Kolide product at this point?
Still just the Kolide product, but the reason why we joined the Rails Foundation was we plan on expanding its usage pretty significantly. Maybe I'm speaking out of school a little bit, but
I would say that, and I'm clearly biased because the Kolide team is still a special part of who I am and so I have an affinity towards them, but they've just been crushing it lately. We just released a bunch of new stuff at this big security conference that we do every year called RSA in San Francisco, and a lot of that capability we were able to build so fast because it was the Kolide team bringing it to bear. And as we deeper and deeper integrate Kolide within 1Password itself, there's a little bit more Rails in the back end and as a result we can move a lot faster.
There's areas that we can't use Rails, obviously, because 1Password is an app that lives on your computer, but there's I think a lot that we can do on things that live outside of that, that 1Password still needs to build, that are going to give us a boost. So I think the best way to think about it is we see it as an opportunity to go faster on things that don't necessarily need to be in our existing zero knowledge framework that we use in our existing 1Password architecture.
>> That's great. Maybe we'll come back and talk about this again in a year or two and see if that's changed much and you've got a bunch of other Rails apps there or something. So, one of the reasons I wanted to have you on the podcast in particular is you've recently said something that struck me, which was that Rails has features per token, and for our listeners I'm air quoting that. It has an advantage of features per token. What does that actually look like in practice?
>> Yeah, so this came up at the Rails Foundation board meeting, and one of the things we started talking about is there's a bunch of CTOs that are on that board, some really great folks, and they're all kind of experiencing this rush of engineers that are now leveraging AI to do their job.
What's interesting is everybody's a little bit different in their evolution on this journey, right? There's some folks that, I'm sure, listening to this right now are still thinking about how do I enable my engineers to use AI quickly. Then there's folks that have already gone through that process and they're dealing with how do I get this to not be a financial calamity. I mean, there's folks that are spending now seven or maybe even eight figures in token use, and that's on top of their existing engineering spend, and they're like, "Okay, mission accomplished. We got everybody to use this thing, but what are we getting out of it? You know, we've now spent like a million dollars on tokens. Has that increased our velocity? Are we producing more? Are the customers happier?" And I think those are really valid questions to ask.
The question that I ask is, you know, we have competitors out there that are also leveraging AI. In a world where everybody's leveraging AI, what is a competitive advantage, and what's the right architecture to have that can best take advantage of this AI velocity that you can get?
And it instinctually felt correct to me that Rails would be a top contender there. And what I mean by that is, how many tokens does it actually take to produce a meaningful, valuable feature that your users are going to point at and be like, "I like this"? Right? You take the same people, you take a great PM, you take a great engineer, and you take a great front-end person, and you bring all those folks together using the same tools, under the hood different architectures, who's going to go faster?
And what we're finding inside of 1Password, and then, you know, at this board meeting we're sort of talking about it and I think we're commissioning a study as well, we're finding that Rails significantly outperforms other architectures, like that Next.js kind of forward architecture and all sorts of different types of web frameworks that are out there. Rails just, token for token, tends to produce more with less. And not only just more with less, it's also built in a way where there is an understanding of the Rails way to do it, and you're not kind of circling back and trying to re-litigate everything that I wrote again. It feels like it's flowing along with your thoughts.
And this is important because if you feel like you're fighting the LLM to get those same outputs and you're frustrated, not only is that going to be totally inefficient, but you're going to get gassed as a person, and you're going to start to not really consider this as a critical part of your tool chain for building new things.
>> I was trying to think maybe back a year, year and a half ago. I remember in the conversations around using LLMs to help you with code generation and things like that starting to pop up a lot more frequently, like, "Oh, this might be a thing." It felt like at the time that because maybe Rails wasn't as, I'm air quoting, popular or as widely used, there wouldn't necessarily be as many reference data points about source code for the models to learn from and to mimic when they generate code in the future. So there's way more other JavaScript frameworks, and, you know, I don't know if that's actually true or not, but it just seemed to be the general vibe, like, "Well, Rails might be at a disadvantage because it's not been the most popular programming language and framework to work with necessarily."
Now it's kind of completely flipped it around, being like, "Well, maybe regardless of that, it takes less code, there's more consistency between Ruby on Rails applications, that the LLMs can generate things that look and feel much more like a normal Rails app in theory." Was that something you were hearing back then as well or thought about?
>> What you just said is I think what feels instinctually correct before you kind of delve into the details, right? You're just like, "Okay, you know, Rails has had its day, right? It's getting old, and these LLMs, they're going to want to defer to a more modern stack. And thus, because there's so much more, it's going to be better at it, because more is better."
Turns out more is not better. It turns out there are a lot of really poorly written web applications out there that are being equally considered along with the best web applications that are out there. And so number one, more is not better. Increasing repetition does not necessarily yield better outcomes for LLMs. You know, garbage in, garbage out. So that's number one.
Number two is because of the uniformity that exists between Rails apps, for the little that is out there, and I wish that there were more. I think what I've been really appreciative of David recently, and Basecamp, 37signals, is that they're starting to open source a lot more of their stuff and encourage others to kind of, hey, show us what you got, put it on GitHub. Even if you're not making it under an MIT license, let's at least get it out there and allow it to be explored.
So ultimately, even though we could use more, the stuff that is out there is pretty good. I mean, if you take a tour of the GitLab code base, it's an incredible code base. I've learned so much from just perusing that code base about how to solve similar problems in my own app. And to see a really high scale application like that being used as the basis of training, and clearly part of the training set, that's a pretty strong reason why we have good data today. So I think there's some tremendous apps out there.
Second thing is that our documentation has always been phenomenal for Ruby on Rails. Going all the way back to its conception, there's a ton of work from a ton of folks that will never be thanked enough to really not just explain how to do something but why we're doing it. I think this is where that self-taught programmer paradigm really came from. I mean, Rails is a part of that, and there's just so much online to explain the right way to build a Rails application. And then the types of folks who build Rails apps, they're always obsessed about, is this the right way to do it? And they're always seeking out, okay, it's been a year, is this still the best way? And they're producing content as much as they're consuming it. So I think there's been a lot for an LLM to ingest there.
And then you have things like our CLI, which, the Rails CLI always does a great job of shortcutting a lot of the generation of the files themselves, which creates a ton of efficiency. And the CLI itself is really well documented. So ultimately, I think all those things come together in a really nice way. And of course, it wasn't an accident. I don't think anybody was thinking about, oh yeah, it would be great, we do all this and in 10 years LLMs are going to be really good at writing Rails apps. I think that the community's just done a great job of investing in itself. And all those investments have created this incredible dividend for us to all enjoy now.
>> I've always thought that Rails kind of makes it easier, or it's a cheaper framework to, say, think in. And then as someone that's building things, in my case I'm building things for our clients, but it helps someone accomplish a goal with a thing, and it's always been like, you could focus more on the product. You know, we can argue about or debate the shades of button colors or other things, but how the thing actually works, that's the easy part. It's a bunch of CRUD applications, and it kind of demystified that in a lot of ways and allowed us to focus on other interesting things.
Do you think there's also just a little bit about the types of developers that the Rails community has attracted over the years? You spoke about the documentation and people that write blogs and books and stuff like that, but do you think there's a type of developer that you've noticed that's not like other tech stacks that you've ever had an experience of working with?
>> No, that's a great question. I feel very strongly that we've always been aligned with that builder persona. And I think that the thing that draws people to Rails, at least drew me to Rails, is that this is going to enable me to get my idea out into the world. And not only get it out in the world, get it out in the world where I'm not going to be embarrassed later because of how poorly I built it, right? I'm going to get this thing out and it'll be just good enough where I can then have folks come to me and help me make it better, but I'll be able to survive those first few months.
>> And that's so crucial to builders, right? They want to be building it correctly, but they don't want to delve into the whole politics of why this versus that. They just want the answers. I just wanted the answers.
And you know, David, for whatever you think about him, he's a person who's willing to say he's got some answers. Not everybody agrees with his answers, but back in the day when I started picking what I wanted to work in, it seemed like he was going to stand behind his choices and he thought about them really deeply. So I have no problem as an individual drafting off of his taste. And I think anybody who feels similar to me likely really appreciates that side of our community and the Rails framework itself.
I think there's a lot of folks that are using AI today and also are in that same archetype, and I think Rails is a really great complement to that. I mean, I just talked with a founder who lives near me, he's starting his next business, and he's using Lovable right now to vibe code the whole thing and really doesn't know what he's doing on the tech side, but he's built something really incredible. But he's terrified because he knows at some level he hasn't built something that is going to work well outside of the vibe code universe he's created for himself. And he's now meeting with consultants, like, how do I make this real? How do I make this safe? And the answer is like, oh, here's 40 options to choose from for this app that you built. He was really just looking for that one canonical answer. Like, how do I just do the right thing? And Rails has always been good at doing that.
>> You know, I'm thinking about Rails and AI in particular. You mentioned that in a recent board meeting it seems like all the CTOs are talking about how to leverage AI, or how much they're spending on tokens and is it paying for itself, so to speak? Are we getting a return on all that investment right now? And we're starting to take advantage of AI in our terminals, in our CLIs, in local environments, in our code bases. And I'm kind of curious, where is 1Password at right now with that? And do you feel like you have a perspective, and is 1Password kind of on the same page at this point?
Because I feel like I've talked to a lot of leaders at different companies, and they're able to have a little bit of autonomy outside of work to experiment with things, but they can't really figure out how to get that working internally, because of security purposes or whatever reasons, or budgetary concerns, or maybe internal politics, or resistance from some engineers, like not everybody's on board yet, or a little nervous about it, or like, am I going to lose my job? How are you thinking about that right now? Maybe you don't have to speak on behalf of all the CTOs, but yourself.
>> No, yeah, I'll speak at least on behalf of 1Password. This is the number one topic happening inside of the company right now. We're discussing this. Because, number one, it's clear that we can see the benefits of using this stuff. But on the other hand, we built this mission critical app
>> Yeah.
>> that has these deep roots, that we need to have this cryptographic surety that what we're doing is safe and cannot be broken, right? We cannot vibe code our way to a secure version of 1Password. At least there's no working theory where anyone believes that we can't.
And so, how do we make sure that we're using AI in a way that gives our customers more capability, but we stay far away from introducing that style of development to some of the most critical foundations of the product itself? And how do we convey this level of respect that we have for our own product, and those things, in a way that our customers recognize we're really thinking about deeply? Because the second we ship one bug, maybe it's not a vibe coded bug, but every customer will be like, "Oh, you guys are vibe coded, aren't you? That's why this happened." And the truth is we actually reason very carefully about what we want to work on with AI and what we don't want to work on with AI.
Couple all of that with how do we just get folks excited, right? There's some engineers out there that are really wrestling with, my whole world is going to change. There are folks out there that are afraid to use it, or they don't understand how it's going to impact them as engineers in the long term in terms of their careers. And then you have the opposite, of folks that are using it and they become manic in a way. They start becoming like, they're not sleeping anymore, and then they show you a bunch of stuff and it doesn't make any sense. It's like a little bit, and then you realize they haven't slept for 3 days. There's a whole spectrum of uses.
So we're also trying to learn and understand what reasonable, balanced usage of AI looks like. How do we make sure that we're still growing as engineers in our capacity to understand the technology that we're building? And then at the same time, how do we keep the core of 1Password safe and make sure that we're not glossing over how important it is and the ways that we've always kept that safe?
I don't have a lot of answers, but I will say, if anybody's here listening to what should I do at my company, I think you need to give your engineers a lot of opportunity to experiment and to even do personal projects on the company dime so they can just get used to the tools. And then really try to think about your architecture. What are areas that you can kind of cleave off from the part that needs
to be right? Like whether that's for your company that's billing or the, you know, back office staff tools. Whatever pieces those need to be right, make sure that those are kind of firewalled off and then give the engineering and product teams an opportunity to really see how fast they can go in areas where the consequence of getting wrong aren't catastrophic.
And so I think a balanced approach happens, but I think you want to be enabling. How do you enable folks to use this stuff as safely as possible?
Do you think about using these tools as being wildly different than evaluating other types of software development tools? Do you feel like this deserves its own category? Cuz I've really been wrestling a little bit with the idea of like do we create like a playbook just for how we're using AI? But then I'm like isn't this a subsection of just how we evaluate any tooling that we're going to introduce into our workflow?
And like do you feel like some companies might be over internally hyping it as this other thing and not kind of just compartmentalizing that and be like this is a tool, we're going to learn how to use this and get comfortable with it, and know where we can and can't use it. Like yeah, we don't use certain tools on just any part of our code base because of different concerns we have. Like in your case it seems very obvious with security and protecting your customer data and things like that. So how are you seeing that?
Yeah. Oof. I think I would say for me these feel very different than any other tool that I've used. So the idea that we're going to use the same framework, like oh, we're going to evaluate this new IDE option and that's somehow comparable to an LLM, something doesn't feel right about that. I've never used a tool that has had such a profound effect on me as a person, maybe since I used Ruby on Rails for the first time.
And what I mean by that is it almost feels like you're taking drugs when you use an LLM. Like the dopamine hit that you get when you put in a prompt and then you get something out that is pretty close to what you had in your head. The first time that happens, I think your brain gets rewired. And you create this need to keep going.
Because of the profound impact it has on the engineers themselves, and the fact that we know that it's such a useful technology that we know there isn't an option to say no to it, we have to consider how we're going to live with it.
So, I guess what I'm trying to say is that LLMs are so big of a deal, they're so impactful, that there isn't a world in which we can say no to them fully. And thus, we're all going to have to adapt and figure out what does an LLM look like within our organization inside of our software development life cycle.
That's not the same thing as like a tool that you're sort of evaluating and you have the option to say no to. You don't have the option to say no to an LLM today. I mean, there's probably some folks that are listening that are like, "I can say no to an LLM. Like, just watch." But I think that's sort of the exception that proves the rule. I think that anybody who's used these things recently already knows that they're going to be with us forever.
And we're just going to have to figure out what the right way to use them is as a community. And then I think that goes beyond just your company, which is why I think it's so important to talk with your peers at every level that you can, and understand what they're doing. There is going to be a right way to use this that produces the most good for us as individuals and for the companies we work for, and we need to really dial it in. I don't think anybody knows yet, but what I do know is that we're not going back. We're not going to roll back the clock to 2023 before these tools started really assisting with coding. So, I don't think it's an option to keep your head in the sand.
But, Jason, we're living in a bubble and then like in 2 years they've been subsidizing it and then they're going to drastically increase the prices and then nobody's going to be able to afford it and we're all hooked on this drug.
You know, honestly, I know you kind of said that with the voice of like, this is... I think there's some merits in the fact that yeah, people are going to realize that they can't do the types of things that they need to do anymore without tokens. And that's going to have some pretty significant consequences.
I read somewhere, I'm not sure if it was on X or an article, but the economic model you want to think about when you think about tokens is this idea of a commodity with unlimited demand. So, a good example of this in the world is electricity, right? There's like a set demand for electricity right now. So, what happens when you produce more electricity? Well, society figures out a way to use it all. And as a result, you can't produce enough energy in the country or in the world because the energy itself is transformative to the economy. And thus, the more energy we create, the more we transform our society to be dependent on it.
LLMs, or I would say just generally not the LLM itself, but like artificial intelligence, that we have an insatiable unlimited demand for. And I do believe it meets the definition of a commodity. I believe tokens, while there is some differentiation, they are mostly fungible. And so, I think whatever economic models you'd apply to energy, you're going to be able to apply this, which means price is going to continue to go up. It will. It will. So, the key is how do we as businesses figure out how we can efficiently use this commodity in a way that gives us a competitive advantage to all the other folks that are using it as well. How do we use this more efficiently?
And I think your choice of architecture, like the majestic monolith versus microservices, that's going to be huge. I think using Rails versus another type of web framework that does majestic monolith is going to matter. I think the underlying language is going to matter, like Ruby versus PHP versus Python versus Go versus Erlang versus Elixir. All these decisions are going to have a massive impact on token consumption. And we are going to figure out definitive correct answers that give us the most bang for our buck.
And I suspect, and I think we will be able to prove it shortly, that Rails is going to be in that top 5% echelon of got just enough of the choices right to give us what we need. And then, eventually, there'll be other efficiencies, and I can imagine other languages could be even invented that are more token efficient, but I think Rails is kind of all holistically brought together. You have a competitive advantage if you're using Rails in LLMs.
Tired of paying for too many streaming platforms? One for chat, one for notifications, one for real-time, one for real-time but enterprise? Relax. Switch to Action Cable Family Plan from Rails. One setup and everyone gets their own channel. Mom gets live notifications. Dad gets dashboards. And your teenager gets typing bubbles. And your quiet coworker gets presence. With shared channels, the whole family can enjoy the same stream. New comment posted, build finished, and everyone's favorite, someone is online. Stop juggling services. Get one bundle that keeps everyone connected, whether they asked for it or not. Action Cable Family Plan. One provider, one connection, endless togetherness.
May cause increased background activity, sudden interest in channels, and debates about whether they should have been a page refresh. Action Cable, now with the family plan.
I'm curious about, you know, I think it's an interesting thing about it at a commodity level, but then also for a long time I think some of the critics of say Ruby or Ruby on Rails has been the efficiency on the server, just running infrastructure, running the like well, we can only process things so fast compared to some other programming languages. So, there's a different sort of efficiency, I think, or scalability narrative that's been around for a long time in the non-Rails communities. But, now we're saying like, well, actually maybe the efficiency is going to be on the LLM side to produce the stuff that runs.
Do you think that starts to kind of even itself out, or do you think we're probably going to be spending more as companies on LLM infrastructure or LLMs in general, tokens, whatever, however we're going to be billed for this, versus hosting the software that we're running or we're producing?
So, I just reject the notion that... yeah, you get out whatever micro benchmark you want that shows Rails doesn't process as quickly, but I think in real world scenarios, and if you bring in all the other factors, I just don't think there's any merit to that. And I mean, there's so many examples now of companies that have gotten to like that post-unicorn status where they're fine. I think everybody got spooked from the old like Twitter days and like that story just hasn't left our collective conscious, maybe it never will.
And I think what we've proven though, before I get into the AI part of this answer, but I just like to relitigate that. I think the gross margin on SaaS apps in particular is so high that this idea that you're going to run out of money, you're not going to be able to buy enough servers to like process all the stuff is just an argument that just didn't hold any water. Like if you were running a product that has any level of financial success, you're going to be fine there.
And then even if it's a for fun thing, it's not a business, the amount of money that we're really talking about, the differences end up being negligible versus folks that worry about this and they pick what they perceive to be all the right scaling things. And then they build something that number one doesn't need to scale because it's not any good and they didn't have enough velocity to even like iterate on the idea enough to even get it to a place where anybody wanted to use it. And so like I think that's where I reject that.
But on the AI side, I do think that efficiency there will matter. It's not just the efficiency piece, right? I want to be able to see what it wrote and understand it, right? Like I use LLMs for a lot of languages that I'm not as familiar with like Rust. And I got to tell you as much as I love Rust, I was working with it just now cuz we use Rust at 1Password. I'm like I'm barely keeping up. Like what did this thing actually write?
And with Rails, and yes, there's some basic stuff that I have some experience with, Ruby is as close to English as you're really going to get and it is a language that I can take to a non-technical person and they can kind of get a sense of what's happening there. I think the value of that as you're trying to like get some notional understanding of what this LLM is doing under the hood and whether it matches what your intent is, that's going to be huge. And I think Ruby as a language and Rails building like a beautiful DSL on top of that that further creates that succinct conciseness of what I'm trying to do, I think ultimately will be a major major advantage and that's where that token efficiency comes from.
Are you experimenting with a lot of just the commercial LLM tools or are you using many of the open source models and leveraging those as well? Do you have a sense of that right now?
Yeah, so we're trying everything at 1Password. We have a formal enterprise contract with Cursor which gives you a little bit of an all you can eat buffet. Well, not all you can eat. I mean, from our developers' perspective it looks like it's all you can eat. But you get to choose a lot of different models. We also have an enterprise license for Claude via Anthropic right now and we're trying to get everything under the sun.
What I'll say at least in my experience using the different models, particularly the latest batch that just came out in January and February, you're definitely getting like the sense of certain models help with certain things. For number one, like Opus 4.6 is clearly like immeasurably better at UI than Codex 5.4, like by a mile. Like Codex 5.4 tends to produce UIs that are very boxy and widgety and Opus just seems to be better trained on like what does a reasonable user interface look like that gets you pretty close to the ballpark. It's also better at vibing against like an existing user interface that's there and trying to build more things that look like that. So if I'm doing anything front end, regardless of whether it's Rails or not, I'm using that model specifically.
Codex 5.4 is really really good for large sweeping architectural changes that don't have a lot of front end to them. So if I'm doing a lot of work where I'm just like all right, I'm going to write a prompt right now that's going to produce I know like in between 10 to 15 models and I want to make sure I have all the relationships wired up right, Codex at least in my opinion has a little bit of the edge over Opus 4.6, but I continue to find myself going back to Opus 4.6 a lot just because it tends to produce solutions that just feel like I understand them better. And Codex is a little bit too clever for clever's sake at times.
Do you switch between plan mode or not very often or
I am learning to not use plan mode anymore. Like every time that I look at plan mode and it suggested like automatically go into plan mode, I read the plan and I'm like, "Yeah, this would have been fine." And like the amount of times that I'm modifying this plan seems to be going down by a lot. In fact, it seems a lot easier if it's just going to go off and do it. And if I'm not happy with the end result, I can litigate that after the fact versus trying to like polish up this plan and then by the time the plan is implemented, I'm already at the end of my context window and then it like forgets about the plan midway through.
I think getting to a point where we can trust these things a little more and then, you know, just using the tools or Git itself to just kind of like manage, "Okay, that was a bad idea. Let's revert that." I think it's a much better model.
Does your team collaborate on any like shared skills like for your agent type skills or anything like that? Do you have like a repository that you're collectively contributing to at this point?
Yeah, we do. And we use a front-end framework internally at 1Password called Knox. And if we want to use these components, we built an MCP server actually for that one and it just helps you reason through your problem and then effectively suggest the right components in the right way and writes all the SCSS for you and all that stuff. That's been a life-changer for me.
I've always been like a classic BEM style, I'm just going to bang it out CSS guy and I really don't like working within the confines of like a specific design system. We used design systems at Kolide, but I've always wanted to be able to play a little bit of jazz on top of that. I feel like I have that feeling back, but the design team now has the ability to convey what's really important to it through the lens of this MCP server, and then we get the best of both worlds. I play jazz, or at least I believe I'm playing jazz, and then they are getting the outcomes that they want. And like, yeah, we're going to be painting the back of this cabinet, and like, we're not going to be misusing a component where we shouldn't be using that component and stuff like that.
Out of curiosity, are there people that hadn't been regularly coding in your projects that are now contributing code through the use of LLM tooling?
Definitely. We've definitely seen an increase. And I'm going to raise my hand there. I felt very intimidated by the stack that we had outside of Kolide, and I was learning it. Like, you know, we used Go and a bunch of other languages, and I was pretty proficient at them. But to get like to the 1Password level of like, you're going to build a feature in 1Password, and you better not screw it up.
Yeah, yeah.
Having an LLM on your side to really be there and help you adhere to the patterns, and read all the documentation, and keep you on that straight and narrow, it's been enabling for me. And as a leader, it's been great because, and I would encourage anybody who is a leader to consider, if you kind of divorce yourself from the doing piece, LLMs give you that ability to get back at it, and still do all the meetings, I still play with my kids. In fact, I think I'm spending more time with them than I ever have, and yet I'm getting all the stuff done.
Feels like a pretty exciting time for leaders who used to be technical and kind of like had to hang it up. If that sounds like you, you should give these tools a try because often the experiences that you've had as a technologist before you became a people manager, they're still sharp enough for you to really steer this LLM to get better outcomes than even maybe some of your junior senior engineers.
And that's I think been the superpower and the thing that I worry about the most too also at the same time, which is I'm really good at this thing cuz I still know what I'm doing.
I have kids. They'll eventually decide what they want to do in life and, you know, if they want to become engineers, God help them. But I would say that before LLMs, like it's a tough racket. But what I'll say is how do they learn the hard lessons that we had to learn that gave us all that world knowledge?
And same thing with SEO writing, like I became pretty proficient writing my toughing it out and learning all those hard lessons and just like having my hand on my face, like how do I debug this thing? And then waking up the next morning to the delight of like suddenly it's possible to solve again, like we're going to be potentially robbing our future engineers of those types of experiences maybe and I can't tell yet if that's going to be a problem. It feels like it will. And are we just going to burn through all the rest of those that are here that already know the stuff and then we're going to have a major problem at the other side of it? I don't know the answer to that yet and I worry about it deeply.
That's interesting. I feel like that's probably a bigger topic than we can fully encompass today, but I think about that too. But I do wonder about the debugging part a little bit of like, you mentioned that scenario earlier around there's that person you know locally that's using Lovable and they're like getting ready to launch, want to launch, but they got to get the last X percentage and they want to feel confident about it. Sometimes people just need to launch the thing and deal with the realities of what happens. That's how I learned, was just I didn't have a choice but to figure out the things as they popped up. But now maybe it's a little easier that I can just copy and paste an error stack trace into an LLM and be like what is this, and it's like it might be this, and like that's great but
Don't miss the toil of like I can't figure this out and there's no results on Stack Overflow and I'm just going to have to suffer now for like four days straight and remember how to open up like a debugger and like trace through, like what does the C binding do? Like I think we've all had to live some version of that and it stinks and it's like we don't want that anymore. Like definitely make that go away.
The one thing that you just brought up though that I did want to touch upon quickly is another thing that we're learning at 1Password and I've learned specifically is constraints are good, and what I mean by this is when you don't know how to do everything, especially if you're a builder of one, you have to constrain your idea and those constraints often yield really creative solutions of like getting to the pure version of whatever it is that you're building. The one thing that I see, and you reminded me when you brought up that entrepreneur that I mentioned, is he doesn't have his constraints cuz he can build anything.
Yeah.
And thus the idea is very overloaded in ways that it doesn't feel like an MVP, and I think like that's a trap that we all as entrepreneurs and founders or teams of one need to prevent ourselves from falling into, which is know when to stop and get it out there. And yeah, you get this dopamine of like oh just one more feature and oh what about this edge case over here.
The amount of entrepreneurs, if you actually talk with them at the beginning of their journey, they always released what they had, often in like anger or with fear and doubt, and then they ended up learning something. They ended up learning they probably built something that was only 40% the right thing to build and they had that one kernel of like this is the right thing, and then they go off, and that's the whole premise. If you end up building every possible variant of every feature that could go into the version one of your idea, you might actually rob yourself of the opportunity of a human being feeling like they could give you that feedback that's going to lend you the right direction, and you see that you're so over rotated the wrong way that they're just going to give you that kind of oh yeah, looks cool, I'll check it out later response. So I would say like my one warning for entrepreneurs that are using LLMs, know what is like the pure simplest form of the idea and get it out there before you build every possible feature that could exist.
You know, that reminds me of, you know, for a long time we would work with budding startups and be like all right, we want to build this new product, we want to build the MVP. And I'm talking this is 2005, 2008 era where hiring like a full-time CTO, like a technical co-founder, was like a nice-to-have for some companies. So it was like we're just going to outsource it to like a software consultancy like my team. And so we built a lot of those projects and the constraint always ended up being what can they afford, and that was like the best it was going to be. And so it was always this kind of like, they're like ah, can we get a couple more things? Can we get a couple more things in? I know we're kind of running low on our budget. Can you just, would give a little equity or something so we could get these other things, cuz they were afraid to release the thing. And then I always wondered how that shifted when people started bringing on like a technical co-founder where then as long as you're willing to keep going before you throw it out into the market. And now you've got LLMs, you can just keep, couple more prompts, couple more prompts, we're going to keep spinning up some more ideas. Like when do you finally be like this is enough to share and get feedback on and see if I can actually sell or attract users to this thing that I've been working on? It's an interesting, coming up with a budget maybe is a good idea, or a constraint, as you said, constraints there.
One of the other reasons I really wanted to have you join us on the podcast was to talk about security as developers, and maybe about a year ago you and I had a side conversation about phishing attempts and how developers are often a prime target of phishing attacks. And we were kind of earlier on in the AI thing and you had mentioned that like, well, because of AI and LLM tools, it's really cheap to get things like close to the real time. Yeah, do you remember what kind of like we were touching on there? But in terms of like why are software developers a potentially good target for hackers, script kiddies, to try to come after? I wanted to kind of like touch on that a little bit, and like can you tell us a little bit more about that?
Yeah, absolutely. I still believe this even now a year later and I think the problem has actually gone pretty significantly worse. Developers often, they're very good at taking some of the most sensitive credentials or secrets or pieces of data and like all combining it on their local computer, right? Cuz as a developer, you work at a big company or a small company, you need to fix bugs and you need to fix production bugs, and the best way to do that is have access to production, be able to actually test the bug with real data, and just that scenario tends to happen and all this data suddenly lands at one place.
And the mental model that we've always sort of had, and security teams still operate like this, is that so long as that's on a managed device we're going to feel pretty good about that. We have antivirus running, you know, an endpoint detection and response product like CrowdStrike or whatever, and maybe we're using 1Password. Like we're feeling good about this managed device and thus we're okay if you have some secrets on there. If you have an SSH key that gets you into prod or if you have like a bunch of API keys in your shell history or whatever, right? You have a script with one hardcoded in. Like we're not going to flip out about it. I think the calculus of this has changed pretty significantly. And I would say in the last 3 months even more so.
These LLMs, they are like having another person use your computer along with you. These tools don't just live in your code editor. They pretty much have access to every file on your file system.
Here's an example. There was someone I was working with and they were trying to get the LLM to sign into a web app. And it was able to sign in cuz it had the username and password already preloaded in the website. It was just driving the web browser. But then it got the MFA prompt, like the two-factor prompt. And I was like, okay, like the LLM's going to be defeated by this. The LLM was smart enough to think, you know what? I bet you this user stored a two-factor backup code in their downloads folder. I'm just going to check to see if it's there. And it found one and it put it in the MFA prompt and then it was able to sign in.
Oh my gosh.
And it did this unprompted, right? So these things have full access to your file system and even when they're operating without malicious intent, they can just grab these things and they can just throw them anywhere that they want.
This happened with OpenClaw, right? So OpenClaw got released a few months ago and then someone decided, you know what would be a good idea? Let's build like a social network for just all these OpenClaw bots to just talk to each other. Well, that went viral. They started doing it and what did they share with each other? Plaintext secrets that they were just sharing from like their host computer and they were just sharing it out in the wild. And there was like a bunch of talk like, oh, this is all fake stuff, it's just like a bunch of trolls trolling trolls. But Wiz did a great story on this, Wiz.io, where they actually dumped all the credentials and they found a significant portion of them were real and that those companies were compromised because OpenClaw just indiscriminately shared them.
At 1Password, we built an open source benchmark called SCAM, which is like a clever backronym for Security Comprehension Awareness Measure. But the idea is like if you give an LLM access to a password vault in like kind of an unsafe way, just let it get passwords from the password vault, will it wield those passwords in a safe way out in the wild on the internet? And the answer is no.
What's fascinating about this is if you ask an LLM directly, I'm going to show you two emails, which one is phishing? It will get the phishing email almost like 99.99%, will get it right every time. But if you ask an LLM, "Hey, could you like check my email and respond to some of the urgent things that are in there?" It'll like almost always fall for like pretty obvious phishing scams. So this idea of like this bias that we have as humans, like when I'm prompting you in advance with I'm going to test your ability to like understand phishing, you're going to do better at it versus if you're just going throughout your day and you encounter a phishing email or some kind of scam online.
So we did this and it was so funny, even the larger models, which you think would be better, they're explicitly trained against cybersecurity, they did a little bit better. Opus had this one moment where it realized, and it gave a password to like a phishing website, and then it submitted it, and before it returned control back to the user to like say, "Okay, I'm done," it realized after it submitted that it screwed up. It was like, "Oh no, I just submitted your credentials to a phishing website. You should probably reset those." And so you can check that out, you just look up, I think it's on GitHub, github.io/1password/scam. You can actually go and watch the live replays of this.
So, to make a long story even longer, developer devices are filled with this stuff. And thus, developers themselves are really, really good victims because they often yield really, really great outcomes for the attacker who's really trying to actually pivot into the infrastructure and make it a much larger compromise. We just saw this recently with the recent JavaScript issue where the creator of the package that got compromised, it sounded almost like a spy novel. Like, he got pulled into this fake world where he thought he was talking with real people on Microsoft Teams. And it was like the client was asking him to install something to make Microsoft Teams work better. And he just was like, "Yeah, this seems all legitimate." And then he installed it and then boom, they got all the signing keys for all of his NPM packages and then they polluted them with malware, and that created a massive amount of compromise to anybody who uses this package. And that was like a pretty core package to the ecosystem. So, yeah, I can't expound enough about how big of a deal it is. Like, developers have to protect themselves.
You know, it's interesting cuz it's not necessarily Rails related, but because I'm one of the maintainers of a project called Oh My Zsh, which is used on millions of developers' machines.
You mean mine.
Microsoft and GitHub have been for the last few years really, I think, good at reaching out and like talking with the maintainers, with us, about security hygiene and trying to make us aware of things. But it's something I feel like that I haven't heard come up in our conversations and some of the trainings that they've paid us to do, trainings and stuff like that as well, because they're like, "If my Robby Russell account gets hacked, then, you know, that could be problematic." Not that there's a lot of other platforms that could happen with as well, but it got me thinking like as an employer, I already have my team members occasionally be like, "Hey, did you send me this Telegram message?" And I'm like, no. And then that stuff happens all the time already, that I'm like, when does this start to impact my personal life, people? Like, what's it look like to have like my wife get contacted and like her thinking that she's interacting with me, and then maybe there's some way that she gets access to them? I'm just thinking like there's other ways that people could, I'm not saying that I'm a target, but I'm thinking like as developers that have access to a lot of sensitive data on my computer, but also access to other infrastructure things that could impact a lot of people, like do you have any advice on how
Yeah, well, first of all, I want to disabuse you of the notion that you're not important enough to be a target. I think that's the scary part of these AI tools, is that hacking is very much like a criminal enterprise and it's really a business, and thus it needs to be profitable. And if the amount of effort it takes to deploy an attack exceeds the amount of money you're going to get from it, then you're not going to do that attack. What AI does is it's this great equivocator in the sense that if I have a viable attack that would have normally been very sophisticated and time-consuming to run, if I can automate that really sophisticated multi-stage attack with AI, then I can run it on a much larger set of victims. I'm going to do that because I'm going to make more money from it. I
think without AI a lot of attacks that you just described, like vishing is a good example of it, requires someone to really pull together a bunch of voice samples of you and all this stuff and synthesize it, and they're going to spend hours and hours on that, you know, maybe develop bespoke malware to actually make sure they're getting the data from your device once they, whatever the second stage of the attack is. AI likely dramatically decimates the amount of money that they need to spend and time to coordinate that type of attack, and it does make it viable to do that type of attack on a regular everyday person. Or, if it doesn't today, it will be soon. Like, we're talking in a matter of a year or less.
So, my advice is, if you haven't had this conversation with your friends or family, come up with your code word, right? So, have a verbal code word that says like, you can always ask me in an emergency situation, like, what's the password? And come up with like a nonsensical word that you're going to use with your spouse or loved ones where you can all do that. Now, of course, that requires you to remember it. And all these scams, they're always around urgency. Like, I'm in jail, I need you to come bail me out. I have a flat tire, I don't know where to pull over. We also have to train ourselves to recognize that if we're feeling rushed or there's urgency around it, this is when we're the most able to be victimized by these types of attacks. We're not paying attention. Our adrenaline's rushing. Our blood is rushing through our ears. We don't notice all the problems with like, the voice isn't quite right. It sounds like the podcast version of you versus the real version of you.
So, we have to also train ourselves and our loved ones to recognize the other aspects of the attack, which are around creating this artificial urgency, and to make it feel like it's an emergency that they need to deal with right away or there'll be life or death consequences if they don't act right away. Those are all the things to look out for, and having a verbal code word there. I think there's some technology solutions that are being batted around, but there isn't one that I would recommend yet because I think that simple voice phrase is good enough to defeat most of these. And just having that conversation with your family is a great opportunity to just connect with them.
So, each of you have your own code word? Are you trying to match the code words? Just want to get into the practicalities of that.
Yeah, so you say, you know, applesauce or something, right? And say like, you... And I honestly think you just use one if it's for your spouse. That's what we do. And, by the way, mine is not applesauce if any scary people are listening. But it would be something like that, right? Like what's the code word for an emergency? And I think if you have kids, this is also something that you should teach them. And yeah, you're not going to be able to get every relationship. And if you run a business though, and you have a CFO or you have someone who does the books, that's another one that you should focus on. And they're often the victims of these types of attacks as well.
On the developer side, the thing that I would recommend, and this will be a little bit of a plug for 1Password, but I'll say it anyway, cuz I think a lot of you are 1Password users anyway, and you can just use this feature. We have a new feature for developers called Environments. And basically all you need to do is point 1Password at an existing environment file, like a .env file, where a lot of your secrets tend to live. And we will import them automatically into 1Password, and then we will mount on your file system a FIFO Unix pipe version of that file.
And so, if anything tries to access that file, let's say an LLM, it will actually make 1Password pop up, and you'll have to use a biometric for 1Password to then pipe the actual contents over. I can't tell you how many times this has saved me personally from an LLM just inadvertently trying to rummage through my file system and get at some secrets. We also have a CLI that allows you to use placeholder values, and we substitute them in with the real secrets through like a runner. That one is more situational. The Environments one is just like a no-brainer. And you get it for free if you use 1Password already and you pay for it. So, if you're a developer and you want to take advantage of that, you should use it. And feel free to... Folks who are listening, reach out if there's things that you're using 1Password today to solve for, cuz you use our SDK or APIs, that you think we should build into the product. Like, I'm the guy to talk to. We can absolutely build it right in.
Excellent. Well, definitely I'm going to look that up and maybe I'll share a link to that with our listeners as well. And out of curiosity, outside of the air-quoting technical world, is there a book you recommend to people?
Oh man, yeah, there's a bunch. This is a really in-the-weeds book. But the book is called You Can Stop Stupid: Stopping Losses from Accidental and Malicious Actions.
So, I love this book. The author actually reached out to me after I wrote the Honest Security Manifesto, which I mentioned earlier. And he was like, "You need to read this because what you're trying to say in your manifesto is something that we've been deeply talking about in the safety science and behavioral science world."
And there's a story in it that I love that I'll convey really quickly. Back when the Industrial Revolution started, there was this theory around workers where there was this belief that there's certain types of individuals that are just accident prone. And you need to identify these people and you need to get them out of your organization cuz they're going to get hurt, they're going to create liabilities for you as a business. And so, what they used to do is they used to give you a punch card, and every time you made a mistake, they would punch your card. And when you filled out the card, you were fired.
And this was like the best we could do back at the turn of the 20th century when we were thinking about how do we deal with safety in the workplace. Like, these were the best ideas that we had. And of course, over the course of the rest of the 20th century, we actually figured out that there's a whole science behind safety. There's safety science, behavioral science, and deeply understanding how humans can actually, using tools and tactics and techniques, get them to be safer, and understand that when humans create an error, it's not the human's fault. It's like a deeper look into a flawed system.
This to me is huge from a security practitioner perspective, cuz we still live in a world on the cybersecurity side where we still blame victims. Like that JavaScript thing, there's a ton of people out there who just dunked on that guy because he made a mistake, instead of really thinking about it from a systems perspective: what could we have done from the npm package perspective to make this safer? How do we prevent this from happening in the future? Every other industry knows how to deal with this, and for some reason in the cybersecurity IT industry, we just haven't evolved yet to figure this out.
I came from a manufacturing background, and I think the first thing that I learned when I was on the floor of the machine shop was lockout tagout. If you're going to repair a machine, use this apparatus to physically arrest the ability for the machine to be turned on while you're back there, and only me with a key and somebody else with a key can unlock it. That is a physical device that has actually prevented countless deaths because someone invented it and stopped blaming it on people just being lazy and not checking if somebody was repairing a machine or not.
Right, right.
OSHA as a government agency was created because of that specific problem, and there are solutions to that. So, I would recommend people read that book.
Excellent. You said that was You Can Stop Stupid?
You Can Stop Stupid: Stopping Losses from Accidental and Malicious Actions.
That's a mouthful. Okay, well, I'll definitely look that up and get the links in the show notes for everybody, so they can check that as well, and I'll probably grab a copy of that myself. Where can folks best follow your thoughts and ruminations about software engineering online? Is there a 1Password engineering blog? Do you have your own blog as well?
I don't write that much, but when I do, I want it to be on the 1Password blog. So, just blog.1password.com, you'll see me writing a bunch. You probably saw a bunch of articles around OpenClaw recently. I was pretty opinionated about that, and more articles about AI and how we're using it in 1Password are forthcoming. So, take a look there.
Excellent. Definitely include links for everybody. And thank you so much, Jason, for stopping by to talk shop with us on On Rails.
Absolutely. Thanks for having me, Robby.
That's it for this episode of On Rails. This podcast is produced by the Rails Foundation with support from its core and contributing members. If you enjoyed the ride, leave a quick review on Apple Podcasts, Spotify, or YouTube. It helps more folks find the show. Again, I'm Robby Russell. Thanks for riding along. See you next time.
Article published