DHH says hand-written code is dead at Rails World 2026. "David Heinemeier Hansson declared the end of manual coding at Rails World 2026, revealing 37signals now defaults to AI agents for code generation. The Hey email client rebuild demonstrates the shift, a native app built in weeks via 'vibe-coding.'" Julian Rossi Key Takeaways * - 37signals has made AI agents the default code generation method. human developers only intervene to fix generated output. * - DHH wrote 50% less code in the last 20 months versus the prior 21 months, and only 5 developers in the Rails World audience still write significant code by hand. * - The new Hey email client is being rebuilt as a native app using vibe-coding, production-ready UI achieved in weeks, with a Windows prototype iterated from 'less than viable' to 'astonishing' in 20 minutes. * - DHH compares AI's impact to Kodak's Brownie camera: a democratization moment that changes what the craft *is*, not just how fast it goes. * - Basecamp 5's failed vibe-coding experiment produced 'Swiss cheese' architecture, the lesson wasn't that AI fails, but that architectural guardrails are essential. David Heinemeier Hansson doesn't do subtle. At Rails World 2026 last week, the 37signals co-founder and Rails creator walked onstage and declared that writing code by hand is effectively over. His company has already made the switch: AI agents now generate code by default. Humans only step in when the output needs fixing. The numbers he dropped were blunt. Over the past twenty months, DHH wrote half as much code as he did in the twenty-one months before that. He didn't frame it as a productivity hack, he framed it as the new baseline. "Writing code by hand is now an exceptional state," he said. When he asked the audience how many still write material amounts of code manually, five hands went up. Five. In a room full of Rails developers. The Brownie moment. DHH reached for a historical analogy: Kodak's Brownie camera. When it launched in 1900, photography stopped being a specialist craft and became something anyone could do. The industry didn't just change, it inverted. DHH argues AI is doing the same thing to software development. The camera didn't eliminate photographers. it changed what photography meant. Same here, he says. The craft isn't typing syntax anymore. It's directing intelligence. There's a psychological angle he explored on the REWORK podcast. Humans get attached to code they write. AI doesn't. "You just start a new session and boom, amnesia. They've completely forgotten that they spent a lot of expensive tokens producing this stuff, and they're not offended." That detachment, DHH argues, is a feature. It lets you throw away bad approaches without ego getting in the way. The Hey rebuild: native, fast, ai-generated. The proof-of-concept is the new Hey email client. 37signals is rebuilding it as a native app, not a web app, and the entire thing is being vibe-coded. DHH showed a demo that looked production-ready after a few weeks of work. His word: "electrifying." The shift to native matters. Before AI, DHH argued, web apps were the only way small teams could stay productive. Cross-platform native development was too expensive. AI changes that calculus. If you can generate a Windows app, a Mac app, and an iOS app from the same prompts, the web's deployment advantage evaporates. He showed the receipts. First iteration of the Windows app: "less than viable." Twenty minutes later, after prompt tweaks: "astonishing." The audience saw both versions back to back. No slide deck. Working software. The Basecamp 5 lesson. This wasn't DHH's first rodeo with AI-generated code. Basecamp 5 included an experiment where designers vibe-coded features directly. The result? Architecture that looked like "Swiss cheese", full of holes, inconsistent patterns, no coherent structure. The team reverted to manual coding and assumed the tech wasn't ready. DHH now thinks that was the wrong lesson. The problem wasn't the AI. It was the lack of architectural guardrails. The real question, he says, is "How do you get the most out of this intelligence exposure?" Not whether to use it, but how to constrain and direct it. What this means for teams. The implications are uncomfortable. If 37signals, a company famous for opinionated, human-crafted frameworks, has flipped the default, the economic argument for hand-writing code is collapsing. DHH put it plainly: hand-written code is no longer economically viable. For engineering teams, the practical trade-off shifts from writing to reviewing and architecting. The bottleneck moves from typing speed to prompt quality, context management, and knowing when to intervene. Senior developers become AI supervisors. Juniors face a steeper curve: they need to understand good architecture before they can evaluate AI output. There's also the ownership question. When nobody writes the code, who understands it? DHH's answer: you don't need to understand the implementation if you trust the tests and the architecture. But that trust has to be earned, and maintained. The grief is real. Not everyone in the room was cheering. DHH acknowledged reactions ranging from excitement to "grief over the last craft of manual coding." That grief isn't Luddism. It's the recognition that a skill you spent decades honing, the tactile, line-by-line shaping of logic, is becoming optional. Like darkroom developing after digital photography. The craft doesn't disappear, but it stops being the job. DHH's closing line: "This is coming. Get ready." Not a prediction. A statement of fact. The Brownie moment already happened. Mango Developer is just arguing about the exposure settings. Frequently asked questions. What exactly did DHH announce at Rails World 2026? DHH announced that 37signals will use AI agents as the default method for generating code. Developers will write code manually only when the AI output needs fixing, hand-writing code is now treated as an exceptional state. What is the 'Brownie moment' analogy DHH used? DHH compared AI's impact on software development to Kodak's 1900 Brownie camera, which made photography accessible to everyone and transformed the industry. He argues AI is doing the same for coding, changing the craft from writing syntax to directing intelligence. How is 37signals applying this approach to the Hey email client? 37signals is rebuilding Hey as a native application (not a web app) using 'vibe-coding' with AI. DHH demonstrated a production-ready version built in weeks, and showed a Windows prototype that went from non-viable to impressive in 20 minutes after prompt adjustments. Discussion (0). You must be signed in to post a comment. No comments yet. Start the conversation!

Active Search, meet Bonsai: Ruby on Rails search on managed opensearch. Web Dev. Color writer. Fire Starter. Rational Pessimist. I'm crazy slap-happy and I'm scrappy when I'm nappy. Ruby on Rails has a search framework of its own now. At Rails World 2026, Donal McBreen from 37signals, the company behind Basecamp and Rails itself, introduced Active Search. It gives you one chainable, Active Record style interface for full-text search across OpenSearch, Elasticsearch, Solr, Meilisearch, Typesense and friends, as well as the full-text search built into PostgreSQL, MySQL and SQLite. If you've written search in Rails before, you know the drill: pick a gem, learn its DSL, marry it forever. Active Search changes that. Start on your database today, move to a managed search cluster when your app outgrows it, and your models and controllers stay the same. It's alpha software (0.1.0 on RubyGems as I write this), but it already runs against OpenSearch, which means it runs against Bonsai. Active Search vs Searchkick and Chewy. Searchkick and Chewy are built for Elasticsearch and OpenSearch, and expose a lot of what those engines can do (Bonsai compared the Ruby gems a while back). Active Search is a common interface instead, the way Active Record is for databases, so the same Article.search("rails") works on SQLite in development and OpenSearch in production. The trade-off: no aggregations, nested documents or autocomplete yet. If you need those today, Searchkick is still a great fit. Step 1: add Active Search to your Rails app. Active Search doesn't bundle a search client. Bonsai clusters run OpenSearch, so bring opensearch-ruby: # Gemfile gem "rails-active_search" gem "opensearch-ruby" bundle install bin/rails active_search:install Running Elasticsearch instead of OpenSearch? Use adapter: elasticsearch with the official client pinned to 7.13. Starting with 7.14, the gem refuses to talk to open-source Elasticsearch 7.x: gem "elasticsearch", "7.13.3" Step 2: connect Active Search to your Bonsai cluster. Grab your cluster URL from the Access section of your cluster dashboard. Heroku users already have it in BONSAI_URL. # config/search.yml development: adapter: sqlite production: adapter: opensearch hosts: - <%= ENV["BONSAI_URL"] %> The client reads the host, port and credentials straight out of the URL (its Active Search docs cover the full setup). Development runs on SQLite, production runs on Bonsai, and your app doesn't know the difference. Step 3: Define a search index and connect your model. # config/search.rb ActiveSearch.define_index(:articles) do text :title text :body string :status end # app/models/article.rb class Article < ApplicationRecord has_search end text fields are searched, the rest are for filtering and sorting. has_search adds callbacks that reindex a record on every save and remove it on destroy, through Active Job. Step 4: Create the index and load your data. bin/rails active_search:index:create INDEX=articles The callbacks only fire on new writes, so batch your existing records in from a console: ActiveSearch.index(:articles).batch(max_size: 500) do |batch| Article.find_each {|article| batch.add(article)} end Step 5: search from your Rails controller. # app/controllers/articles_controller.rb def index @page = Article.search(params[:q]) .filter(status: "published") .page(params[:page], per_page: 20) end It chains like the Active Record queries you already write, and pagination is built in. Loop over @page.results in your view and each result is the record itself. See what your Rails search is doing in the Bonsai dashboard. Active Search writes the queries for you. That's the whole point, but it's also why it's worth having somewhere to see them land. Documents: did the load actually work? Run bin/rails active_search:status COUNT=1, then compare it with the Usage panel on your cluster's Overview: If your database says 5,000 articles and Bonsai says 5K docs, you're done. If not, you know before your users do. Performance: your traffic, at a glance. Each column in the Overview heat map is a slice of time, each row a bucket of request duration, and hotter colors mean more requests. A cool, tight band at the bottom? Happy cluster. Heat creeping upward right after a deploy? You just found your slow query, and you know exactly when it started. Query Logs: what your users are really asking. Query Logs ranks the search terms your users type by volume, with duration and hit count for each. High volume with low hits is a relevancy problem, and zero-hit queries are the first thing to fix. To tell Bonsai exactly what the user typed, add it to the request with native: Article.search(params[:q]).native {|request| request.merge(ext: {bonsai: { user_query: params[:q]}})}.page(params[:page]) The Console: talk to your cluster directly. Want to see what Active Search is sending? Article.search("hotwire").to_native_query returns the request body. Paste it into the Console as a POST to /articles/_search and tweak it until the results look right. No curl, no credentials on your clipboard. Why Active Search and Bonsai work well together. Active Search makes the engine swappable. Bonsai makes the engine visible. Together you get Rails-native search code and a cluster you can actually see into, without running a single node yourself. Spin up a free Sandbox cluster, add the gem, and watch your first queries light up the heat map. The Active Search README covers everything this post skipped, and Bonsai'd love to hear how you're using it at [email protected]. Ready to power your search with AI? Launch a fully managed Elasticsearch or OpenSearch cluster, with built-in vector search and AI capabilities. Or, schedule a consultation: Optional - If you would prefer for Bonsai to call you. Already a customer? Log in to your account to connect with its support team, or e-mail them at [email protected].