Photo by Alvan Nee on Unsplash

I was reading a good article by Matthew Prast called “To be a better programmer, write little proofs in your head” (link) and he mentions this concept of “blast radius” when touching a specific point: isolation.

I want to save myself the trouble of butchering his writing (please go and read the article, it’s really interesting) so I’ll just say this: basically he talks about the impact your code could make on an existing codebase. Matthew calls us to ask ourselves how this new code or fix could create a ripple effect on the project.

Now before I move forward with this specific concept that I find interesting, I need to talk a little about a certain way I manage to deal with content coming from HackerNews (if you don’t know what it is, just take a look over here).

I usually get the newsletter on Fridays and I don’t have the time to read all of it because I find myself busy, but I do try to start marking the links that I want to check up later. So when the weekend gets here (usually on Sundays for me) I take some time and read as much as I can. This week after reading Matthew’s article I found myself later reading this other one:

The bewildering phenomenon of declining quality

And I don’t know if I’m “forcing” it, but the concept of isolation and the conclusion from El País gave me this weird pull. I noticed that they kind of talk about similar things when we make a simple question about quality/blast radius in code with AI.

House Keeping

Before I move forward I want to clarify a stance about AI/LLMs just to be sure I explain myself a little better in the next section.

I think you do not have to use these kinds of tools, but I find that right now when I’m writing this article, if you don’t, you are missing some valuable perspective.

It’s really hard to have a fit-all/umbrella position because it depends on what you do and where you are doing it. For example, we all know that vibe coding something that is intended to check people’s health or keep track of something medical is just a big no-no, but how about boilerplate or maybe a simple prototype of something that you want to test?

I’m stating the obvious but I think it’s not that hard to find a place and a length for the usage of a tool. Not everything is a hammer or a nail.

Knowing You Don’t Know What You Don’t Know

Can you learn programming using an LLM or use it on a production project? Which takes us back to the concept of blast radius. I think so BUT you need to know what you are doing, else you don’t know what you will be impacting and have no idea WHY it works. In other words, as an engineer maybe you know about Swift, Architecture, Algorithms, etc. But can you really know when the tool is giving you gibberish? Can you know when it’s going off the rails? Can you follow, change, adjust things after a few months pass by? Does the code follow the standards, quality, testing, style?

This is where things stop being “magical” and become an actual tool. You don’t just have a hammer—you know that this hammer is for wood and this one is for this type of nail. Wait, the hammer is a little broken from the tip, maybe I shouldn’t use it.

It’s essential to avoid thinking about LLMs as THE source of truth. They are a tool and as such, you need to always ask: what is the best tool for the job? Here are some examples I find myself using when I want to have more “perspective” but again, not the final say.

Development Tools

  1. Claude CLI for project context (small to medium codebase)

    Sometimes I find myself doing some extra work on the weekends after my regular job, and this sometimes comes in the form of either fixing legacy projects or finding a bug on an already production project. I like to get a quick glance of a project and then run Claude CLI to run around the codebase and tell me in general how it’s structured, the modules, the entities, in general how the architecture works, etc. This just adds to my manual research and documentation reading.

  2. Zapier MCP for organization and efficiency

    Zapier MCP - Basically you can connect Zapier with a tool like Claude, then using Zapier you can connect multiple tools. For this example I used Todoist. You can ask Claude to give you some plan to deal with tasks marked with some #hashtag on your Todoist and organize those tasks in intervals. Can you do this manually? Yeah, but you can save some time when you do this daily or prepare yourself for the start of the week.

  3. General Questions with Perplexity

    I don’t always want to use my tokens or in general something super robust for a simple question. I find myself using Perplexity which takes information from the Web, processes it and delivers you (at least for now) some good feedback.

  4. Code Context Tools

    When I want to give a repo/documentation as context to the LLM and help me build from that, having these tools to create an “ingested context” can be super useful.

Writing and Communication

  1. Grammarly for writing polish

    For cleaning up grammar, tone, and clarity in documentation, emails, or articles like this one.

  2. Lex for creative writing

    When you need help with structure, flow, or getting unstuck on longer pieces of writing.

  3. Notion AI for documentation

    Great for organizing thoughts, creating templates, and maintaining project documentation.

Design and Creativity

  1. Figma AI for design iteration

    Helpful for generating design variations and exploring different visual directions.

  2. Midjourney/DALL-E for visual concepts

    When you need quick visual prototypes or concepts for presentations.

Research and Analysis

  1. ChatGPT with plugins for research

    Useful for breaking down complex topics or getting different perspectives on technical decisions.

  2. GitHub Copilot for code suggestions

    Good for boilerplate and common patterns, but requires careful review.

I Wonder

With that out of the way, I’m afraid that basically with AI we’re making this fast fashion code that is just something that is bound to happen: create an app with vibe coding, and if it breaks, create another.

Sell, vibe, sell, vibe.

Conclusion

The concept of blast radius isn’t just about code, it’s about understanding the full scope of impact when we introduce any change or tool into our workflow. I don’t really want to make you question too much but maybe before you do something: what could this affect?

AI tools can be incredibly powerful multipliers when used thoughtfully. They can help us prototype faster, understand complex codebases, organize our work, and even polish our communication. But like any powerful tool, they come with their own blast radius.

The key is developing what I call “tool awareness” knowing not just how to use these tools, but when to use them, when to question their output, and when to step back and rely on fundamental knowledge and experience.

Learn to say: “NO, bad AI, don’t use singletons for everything please” and do the same for you.