Why Year-Round Hobbies Need a Smaller Blast Radius Than You Think

There’s a certain satisfaction in keeping things small. Small batches of work, small steps forward, small, manageable goals. For years, software teams swore by the small pull request—the idea that a code change should be tiny, atomic, and easy to review. It made sense when humans were writing every line. But what happens when the writer is an AI agent that thinks in whole features, not increments? That’s the question Rootly, an incident management platform, recently tackled in a blog post. And honestly, it got me thinking about hobbies.

See, hobbies are a lot like code. Whether you’re into knitting, woodworking, or trail running, there’s a constant tension between doing something small and safe versus taking on a big, ambitious project. The small approach feels responsible. It’s easy to measure progress, easy to spot mistakes. But if you’re using a tool that changes the game—like a new loom, a power planer, or a training plan that adapts to your heart rate—the old rules might not apply anymore. Rootly’s story is about software, but the underlying lesson is universal: when the nature of the work changes, the metrics you use to judge it must change too.

The Small-PR Rule: A Love Story That Ended

Rootly had a strict rule for two years: keep pull requests small. Stack them, keep changes under a few hundred lines. It worked beautifully when humans wrote code. Small diffs are easier to review, easier to reason about, and easier to roll back if something breaks. But then AI agents entered the picture. These agents don’t think in increments; they think in features. Give one a task, and it will generate the entire implementation at once—database migrations, models, services, controllers, tests, and front-end components. All in one go.

The company tried to force AI agents to produce stacked, small PRs. The result? Technically correct code that was, in the broader business context, actually worse. Reviewers had to jump between multiple PRs to understand a single change, because comments on one PR depended on fixes in another. The mental overhead skyrocketed. They realized the small-PR rule was designed for human efficiency, not for AI efficiency. The rule had become a tax on the process, not a benefit.

From Line Count to Blast Radius

Rootly’s team shifted their focus from measuring the number of lines in a PR to assessing what they call the “blast radius”—the potential impact of a change if something goes wrong. This is a concept that translates beautifully to hobbies. Think about a big knitting project: a king-size blanket with an intricate pattern. The blast radius is huge. One mistake in row 47 could mean hours of unraveling. Compare that to a small dishcloth: a mistake is easy to fix, or you can just start over. The size of the project matters less than how much damage a single error can do.

In software, feature flags have moved the safety boundary from the moment you merge code to the moment you release it. Every important feature now ships behind a flag, so it’s off by default. The real review happens during progressive rollout—first to the team, then to a small group of customers, then to 10% of users, and finally to everyone. If something breaks, you flip the flag and the feature is gone. No rollback drama. The lesson for hobbies? Build in your own “feature flags.” If you’re trying a new technique, test it on a small, inconsequential piece first. If you’re training for a marathon, don’t suddenly double your mileage. Give yourself an off-ramp.

The Context Problem: AI’s Blind Spot

Rootly’s engineers noticed that AI-caused bugs are often context bugs. The code runs fine, but it’s used in the wrong scenario. A database migration deletes a field that a background job still calls. A service writes to a table that another team is reading. The code is syntactically perfect but semantically wrong. The same thing happens in hobbies. You might follow a pattern perfectly, but if you use a different yarn weight than the pattern calls for, the finished sweater won’t fit. The instructions were correct; the context was off.

This is why Rootly built an internal AI code reviewer that doesn’t try to act like a human reviewer. Instead, it asks one question: if this change has a defect, what user-facing features would break? It classifies changes by whether they alter actual business behavior or just affect performance or appearance, and assigns risk levels accordingly. This gives human reviewers a structured reference, not just a raw diff. For hobbyists, the equivalent is asking: “If I mess this up, what’s the worst that happens?” If the answer is “I waste a weekend,” that’s a low-risk project. If it’s “I ruin an expensive piece of wood,” you might want to practice on scrap first.

Why Small PRs Are a Relic of Human-Centric Work

The small-PR rule was a product of human limitations. Humans can only hold so much context in their heads at once. We need small chunks to stay focused. But AI agents don’t have that limitation. They can hold the entire feature in their “mind” and produce it in one shot. Forcing them to break it into small pieces actually makes the output worse, because you lose the holistic view. It’s like asking a master carpenter to build a chair one leg at a time, without seeing the whole design. The result might be four perfectly crafted legs that don’t fit together.

Other companies are reaching the same conclusion. Rewind, a backup and version control service, borrowed Rootly’s risk-based review model for its Diff Vader tool. They found that a PR’s risk has almost nothing to do with its line count. Instead, they assign a risk label based on the review. Patrick Debois, known as the “DevOps father,” argued that PR-based workflows become an anti-pattern when development runs at agent speed. In open source, PRs make sense because contributors need to build trust and align on strategy. But inside a team with shared context and goals, the PR review cycle becomes hard to justify when agents are iterating rapidly.

The Cost of Not Adapting

There’s a financial angle too. Debois and others point out that AI agent usage costs money—token consumption, compute time, and so on. Inefficiencies that were invisible when humans wrote code for free (well, for salary) are now glaringly obvious on the bill. If you’re paying for every AI-generated line, you want to make sure you’re not wasting tokens on process overhead. In hobbies, the cost might be time or materials. If you spend hours on a practice piece that you’ll never use, that’s a cost. But if that practice piece teaches you a new technique, it’s an investment. The key is to know which is which.

Practical Takeaways for Hobbyists

So what can the rest of us learn from Rootly’s pivot? Here are a few ideas, applicable to any hobby you pursue year-round:

• Focus on blast radius, not size. Whether it’s a knitting project, a home improvement task, or a new recipe, ask yourself: if this goes wrong, how bad is it? A small project with a huge blast radius (like a gift for a picky friend) might be riskier than a large project with a small blast radius (like a blanket for your own couch).
• Use feature flags in your own life. Try new things in a limited, reversible way. If you’re experimenting with a new painting style, do a small canvas first. If you’re trying a new running shoe, wear it on a short run before a long race. Give yourself permission to “switch off” the feature if it doesn’t work.
• Write your own “why” and “what.” Rootly now requires every PR to explain why the change is happening, what the impact might be, and how to roll back safely. For hobbies, that means documenting your process. Why are you trying this technique? What could go wrong? How can you undo it? It sounds overkill, but it saves time in the long run.
• Embrace rollbacks. If a project isn’t working out, don’t feel obligated to finish it. Rip out the stitches, sand down the wood, or abandon the recipe. The ability to roll back is a superpower. In software, it’s called a “safe rollback.” In hobbies, it’s called “learning from mistakes.”

The Bottom Line: Let Go of the Old Metrics

Rootly’s CTO Quentin Rousseau admitted that abandoning the small-PR rule was uncomfortable at first. The rule had felt so right for so long. But it was necessary to support “fast delivery of reliable software.” The same applies to hobbies. Maybe you’ve always believed that you should finish every project you start, or that you should only take on small, manageable tasks. But if you’re using new tools—like AI assistants, advanced software, or modern equipment—those old rules might be holding you back. The point isn’t to do less; it’s to do better, with a clear understanding of risk and a safety net in place.

So next time you’re about to start a hobby project, think like Rootly. Don’t ask “How small can I keep this?” Ask “If this fails, what breaks?” And then make sure you have a way to flip the switch and walk away. That’s the year-round hobbyist’s version of a feature flag. It might just save your sanity—and your stash of yarn.