Adam Wathan

Next question: why are you still using branches? We talked about PRs. I don't think they make sense anymore, if you rethink them from first principles. Yes, if you only use them to trigger CI, then sure, go ahead. That's a fat commit, not a PR. But for mandatory code review? Knowledge sharing? C'mon. But some of you said: "we use PRs because we use branches! I love to keep my stuff on branches." And I'm here to tell you: you don't need branches! You can just push to main. It's called trunk-based development and the idea behind it is true continuous integration: you continuously integrate your changes with the trunk, the main branch. It's been around for a while, it works. Just yesterday I talked with someone who said they've used it in an org with 400 engineers, without any issues. Ruby, the project, uses trunk-based development. The main idea is that you want to avoid long-lived branches. They're bad, because branches can diverge and merging can turn into a thing. And you don't want routine operations to become a thing. Even when I worked in teams that used PRs and branches, I considered it a smell when a branch lived for longer than a day or two. But when I shared this with others, I'd often get something back like this: "Well, good for you, but no. MY thing, what I'm working on, that can't be done on main. It needs to be on a branch! It has a database migration, it changes the underlying shape, the architecture, it refactors this and changes that. It can't go on main yet! I need to merge it all at the end." And then I'd say: "Nah, I can merge nearly anything continuously in small commits to main. You split things up. Add the column first, merge that, deploy it, now it's out, works, safe. Add the helpers first, merge them, get them out. Want to migrate from legacy pattern A to new pattern B? Don't do it all at once. Add the dependency, then migrate A to B, one by one, safe." If it can be merged in a large change, I bet it can be done in small increments that you merge to main. Yes, there are exceptions, but it's 0.5% of cases, not 50%. But there was a real problem with this approach: it was hard! There's a lot of "meta programming" you have to do: make sure this small first change compiles and runs and the tests work, merge it, get it out, monitor it; then do the next small piece, make sure that works and get it out; then maybe push some still-unused dead code, add a feature flag, add a config variable; or keep both configurations working at the same time, etc. That meant sometimes it was just easier to do it in a big fat branch. But big fat branches are risky! A system that continuously flows is safer than a system that starts and stops in spurts. But -- you guessed it -- here's the good news: Now, with agents, all of these chores are no chores at all! Agents are great at adding feature flags, they're great at splitting up code, they're great at keeping track of three changes and merging them one by one and watching them roll out. They're great at keeping two configurations working for a day. They're great at migrating one by one. In other words: it's now 10x easier to just work on main and make sure everything is continuously integrated and working. It's now easy to make sure the system constantly flows. And look, ... I'm not here to convince you to switch to trunk-based development. Just a ruse to get you to read this. (But also, hey: try it! Pushing to main is amazing.) I'm here to make you RETHINK how you develop software. Don't just use agents to replace your typing. Use agents as the magic code-writing machines they are. Everything that was hard about software development because it involved writing code -- even the meta programming -- has become easier. You can now reach for the stars! But you need to look up.

No pull requests, no code review. We push to main. Our agents read production logs, watch deploys, grant feature flags, and check their own work end to end. Here's how we do that: