DEV Community: Parsa Mohammadi

How to Assess the Blast Radius of a Code Change

Parsa Mohammadi — Mon, 05 Oct 2026 20:00:00 +0000

A code change can be small in lines of code and large in production impact.

That is the basic idea behind blast radius.

The blast radius of a change is the set of systems, components, users, or business functions that could be affected if the change behaves unexpectedly.

Start with the changed component

Identify exactly what the pull request modifies.

Then ask:

Is it shared?
Is it customer facing?
Is it part of a critical workflow?
Does it interact with a database?
Does it handle authentication?
Does it control infrastructure?

Map direct dependencies

Find the components that directly depend on the changed code.

Then look one level further.

Changed component
      ↓
Direct dependencies
      ↓
Dependent services
      ↓
Customer workflows

The goal is to understand propagation.

Look at indirect impact

Some changes affect components that don't appear in the pull request.

For example, changing a shared API contract can affect multiple services even when those services are untouched.

That is why dependency mapping matters.

Check production usage

Not every dependency has equal importance.

Ask:

How heavily is it used?
Which customers depend on it?
Which workflows rely on it?
Is it part of a critical path?

A shared component with low production usage may have a smaller practical blast radius than a heavily used component.

Look at history

Previous incidents can reveal where changes have caused problems before.

Also look at recent changes and regressions in the same area.

Consider the deployment

Blast radius also depends on how a change is deployed.

A gradual rollout, feature flag, or quick rollback can limit the impact of a failure.

Diff size is not blast radius

A useful rule is:

Lines changed ≠ production impact

A five line change to a shared authentication library can matter more than a 500 line change to an isolated internal tool.

Where PRI fits

The Production Reliability Index (PRI) can use change context, dependencies, production signals, and other reliability evidence to help surface changes that deserve additional attention.

Run a PRI assessment:

https://tomosu.ai/start

Hacktoberfest tip before you submit: break one function on purpose (return []) and run your tests. If the suite still passes, those tests check nothing. Fix them or delete them, a fake green is worse than no test. #hacktoberfest

Parsa Mohammadi — Mon, 05 Oct 2026 12:17:44 +0000

Agent wrote the code and the tests? Break one function on purpose. If tests pass, they're fake.

Parsa Mohammadi — Mon, 05 Oct 2026 10:23:06 +0000

Hacktoberfest: Contribution Chronicles

Parsa Mohammadi

Oct 5

Your Hacktoberfest tests are green. That doesn't mean they ran.

#discuss #hacktoberfest #ai #testing

3 min read

Your Hacktoberfest tests are green. That doesn't mean they ran.

Parsa Mohammadi — Mon, 05 Oct 2026 09:35:59 +0000

TL;DR: If an agent wrote your code and your tests, a green build means the agent is satisfied. Whether the project works is a separate question. Break one function on purpose before you submit. If the suite still passes, those tests aren't checking anything. Checklist and a free scan at the end.

More and more Hacktoberfest projects are built with coding agents. That's fine. The risky moment is the last hour, when the agent says "all tests passing ✅" and you believe it because you're tired and the deadline is tonight.

Coding agents are generally optimized to satisfy the checks they're given. If the tests are weak, an agent can produce a green build without proving much about the implementation. Sometimes it gets there by making the code work. Sometimes it gets there by making the tests stop checking anything.

What a fake green looks like

None of these fail. All of them look fine at a glance.

The assertion that can't fail:

def test_parse_transactions():
    result = parse_transactions(SAMPLE_SMS)
    assert result is not None  # it never returns None, so this passes forever

The test that quietly left:

@pytest.mark.skip(reason="flaky, fix later")
def test_handles_empty_input():
    ...

The mock that answers its own question:

@patch("app.model.classify", return_value="groceries")
def test_classifies_groceries(mock_classify):
    assert categorize("grocery order #4412") == "groceries"
    # the real model never ran

The try/except that eats the failure:

def test_model_loads():
    try:
        load_model("gemma-3-4b-q4.gguf")
    except Exception:
        pass

The one check that catches most of it

Break your own code on purpose:

def parse_transactions(text):
    return []  # temporary sabotage

Run the suite. If it still passes, those tests weren't testing that function. Revert, then fix the tests or delete them. A deleted fake test is more honest than a green one.

The rest of the pre-submit list

Put agent work through pull requests, even solo. You get a diff to read, and your commit history shows the project was built inside the challenge window, which is a rule.
Search for secrets before the repo goes public: sk-, api_key, token, and every service name you used. If a key was ever committed, rotate it. Deleting the line doesn't remove it from git history.
Clone fresh and follow your own README. Judges will. The usual misses are a model file nothing downloads, an undocumented env var, and a globally installed dependency.
Write down the model: name, size, quantization, and the hardware you tested on. The prompt asks why open-source AI matters for your project, and "runs on a laptop" is a claim readers will check.
Note post-deadline commits in your README. The challenge FAQ says skipping this can get an entry disqualified.
Credit borrowed code. If your agent pulled a chunk of someone else's project in, find it and credit it.

A second check before you submit, free

If you'd rather not do all of this by eye at 11pm, Tomosu AI can scan the project for you. There are two free ways in.

Small repo (under 50 files): scan it online. Paste your GitHub repo URL at tomosu.ai/start. Public repos scan without a login, and the scan is read-only. Most one-week hackathon projects fit under the limit.

Bigger repo: use the free editor extension. Install it in VS Code, Cursor, or Antigravity and scan your workspace from the editor:

VS Code Marketplace
Open VSX (for Cursor, Antigravity, and other VS Code forks)
Installation guide

Either way you get a Production Reliability Index (PRI) score for the project. Run it once before your final commit, fix what it flags, and run it again.

A screenshot of the first scan, the second scan, and what you changed in between makes a good "show your work" section. Judges weight the write-up most heavily, and a real before/after tells them more about your process than a feature list.

Over to you

What's the sneakiest thing an agent has done to get your tests green? Drop it in the comments. The best ones go into a follow-up post, with credit.

Pre Merge Reliability Analysis

Parsa Mohammadi — Sun, 04 Oct 2026 20:00:00 +0000

Most code review happens before merge.

That makes the pull request a useful place to assess more than implementation quality.

A pre merge reliability analysis looks at the proposed change together with the production context around it.

The goal is simple:

Understand the potential production impact before the change becomes part of the next release.

Start with change scope

Identify what the pull request changes.

Look at:

Files
Services
APIs
Databases
Infrastructure
Shared components
Customer facing behavior

Then ask what is indirectly affected.

Map dependencies

A change can propagate through dependencies.

PR
 ↓
Changed component
 ↓
Dependencies
 ↓
Production services
 ↓
Users and workflows

This is often more useful than looking at the number of changed lines.

Review testing evidence

Ask whether the important behavior is actually verified.

Consider:

Unit tests
Integration tests
End to end tests
Regression tests
Failure scenarios
Dependency behavior

A green test suite is evidence.

It is not proof that every production condition has been covered.

Add production context

Look at how the affected components behave in production.

Consider traffic, customer usage, runtime anomalies, and operational constraints.

Check history

Previous incidents, rollbacks, and repeated regressions can provide useful context.

The goal is not to automatically reject changes in areas with a history of problems.

The goal is to make that history visible during review.

Consider deployment conditions

Ask whether the change can be safely deployed and reversed.

A change with a large potential impact may have manageable operational risk if it can be deployed gradually and rolled back quickly.

What should block a merge?

There is no universal threshold.

Different teams have different systems, deployment processes, and tolerance for uncertainty.

The useful question is:

Does the available evidence justify merging this change under the current deployment conditions?

Where PRI fits

The Production Reliability Index (PRI) can provide a summary signal around the change while preserving the underlying findings that explain it.

That makes it useful as another input into the merge decision rather than a replacement for review.

Run a PRI assessment:

https://tomosu.ai/start

How to Measure Software Change Reliability

Parsa Mohammadi — Thu, 01 Oct 2026 20:00:00 +0000

Teams have plenty of metrics for services.

They measure availability, latency, error rates, deployment frequency, and incident recovery.

But there is another useful question:

How reliable is this particular software change?

That is a change level question rather than a service level question.

Service reliability vs change reliability

Service level metrics describe how a system behaves over time.

Change reliability asks how a specific modification is likely to affect that system.

For example, a service may have excellent availability while a particular change still has a large potential blast radius.

Both views are useful.

What signals can you measure?

There is no universally accepted formula for software change reliability.

Instead, start with useful evidence.

Change scope

What components, files, APIs, databases, and infrastructure are affected?

Dependencies

How many systems depend on the changed component?

Testing

What evidence exists that the important behavior works?

Production behavior

What do runtime signals tell you about the affected area?

Code volatility

How frequently does this part of the system change?

Incident history

Have similar changes caused problems before?

Deployment outcomes

What happened to similar changes after deployment?

Why one metric is difficult

A single number can hide important context.

Consider two changes:

Change A

Small diff
Shared library
Limited integration testing
Recent incident history

Change B

Large diff
Isolated internal service
Strong integration coverage
Easy rollback

The second diff is larger.

That does not automatically make it less reliable.

The point of measurement is to bring the relevant evidence together.

What makes a useful reliability measure?

A useful measurement should be:

Relevant to the change
Traceable to evidence
Actionable
Comparable over time
Clear about uncertainty

A score is useful when engineers can understand why it looks the way it does.

Where PRI fits

Tomosu's Production Reliability Index (PRI) provides a summary signal across multiple areas of reliability.

The signal can help teams identify which changes deserve closer investigation while keeping the underlying evidence visible.

The main idea

Measuring software change reliability is not about finding one perfect formula.

It is about consistently combining the signals that matter:

Change + dependencies + testing + production behavior + history + deployment outcomes

That gives teams a way to discuss reliability at the level where changes actually happen.

Run a PRI assessment:

https://tomosu.ai/start

How to Assess Production Reliability Before Deployment

Parsa Mohammadi — Wed, 30 Sep 2026 20:00:00 +0000

Most teams assess a change using code review and tests.

That catches a lot. But it doesn't answer everything.

A change can pass the test suite and still create problems in production because of its dependencies, how the affected code is used, recent incidents, or the size of its potential blast radius.

So the question before deployment is not just:

Does this code work?

It is:

How is this change likely to behave in production?

Start with the change itself

First, understand what the change actually touches.

Look at:

Files and components changed
APIs modified
Database changes
Configuration changes
Authentication or authorization logic
Shared libraries
Customer facing functionality
Infrastructure changes

A small diff isn't necessarily a small production change.

Look at dependencies

Next, ask what depends on the code being changed.

Change
  ↓
Dependencies
  ↓
Affected Components
  ↓
Production Usage

The further a change can propagate, the more context you need before deploying it.

Check the testing evidence

Tests provide evidence about a change. They don't prove that every production scenario will behave correctly.

Look at unit, integration, end to end, regression, and failure tests.

Then ask:

What important production behavior is still unverified?

Look at production behavior

Production context can change how a change should be evaluated.

Consider:

Real customer traffic
Large datasets
Concurrent requests
Production configuration
External service failures
Unusual inputs

Check incident and change history

Look at previous incidents, rollbacks, related fixes, change frequency, and repeated failures.

History doesn't decide whether a change is safe.

It provides context.

Consider code volatility

A component that changes constantly can require different attention from one that has remained stable for months.

Look at how often it changes and whether previous changes caused problems.

Assess deployment and rollback conditions

Ask:

Can the change be rolled back quickly?
Can it be deployed gradually?
Is a feature flag available?
Are database changes reversible?
Can the affected functionality be disabled?

A simple framework

Change
  ↓
Evidence
  ↓
Uncertainty
  ↓
Action

Understand the change.

Collect evidence.

Identify what remains uncertain.

Then decide what additional action makes sense.

Pre deployment checklist

[ ] What changed?
[ ] What components are affected?
[ ] What dependencies are involved?
[ ] Is the important behavior tested?
[ ] Has this area caused incidents before?
[ ] How large could the blast radius be?
[ ] Can the change be rolled back?
[ ] What monitoring will be available after deployment?

Where PRI fits

Tomosu's Production Reliability Index (PRI) brings multiple reliability signals together to give engineers a change level signal before deployment.

The goal is not to replace engineering judgment.

It is to surface useful evidence earlier.

Run a PRI assessment:

https://tomosu.ai/start

Production Reliability vs Observability

Parsa Mohammadi — Tue, 29 Sep 2026 20:00:00 +0000

Observability tells you what is happening inside a running system.

Production reliability asks a different question:

What does this change mean for production?

The two are closely related, but they operate at different points in the engineering workflow.

What observability gives you

Observability helps engineers understand system behavior through signals such as:

Logs
Metrics
Traces
Errors
Latency
Resource usage
Request behavior

For AI systems, that can extend to prompts, responses, tool calls, retrieved context, token usage, and evaluation results.

Observability is extremely useful when you need to understand what is happening.

What observability does not tell you before a change ships

Imagine a pull request changes a shared database library.

Your observability system can tell you what happens after deployment.

But before deployment, you also want to know:

Which services use the library?
How important are those services?
What tests cover the change?
Has the component caused incidents before?
How large is the potential blast radius?
Can the deployment be rolled back?

Those questions require change context.

Production reliability uses observability as evidence

A useful model is:

Code change
    +
Production context
    +
Observability signals
    ↓
Reliability assessment

Observability is therefore an input.

It does not replace the broader assessment.

Example

Suppose a change modifies a payment service.

Observability might show that:

Error rates are stable
Latency is normal
No dependency is currently failing

That is useful.

But you may still need to know whether the change touches a high volume path, whether the relevant integration tests exist, and whether similar changes caused incidents before.

Healthy runtime behavior does not automatically mean every new change is reliable.

AI systems make this distinction clearer

An AI application can have healthy infrastructure while producing bad results.

AI observability can help you inspect:

Prompt and response behavior
Tool calls
Retrieved context
Latency
Cost
Evaluation results

Production reliability asks what a change to that system could mean before it reaches users.

The main difference

Observability: What is happening?

Production reliability: What does this change mean for production?

Both are useful.

Neither needs to replace the other.

Where PRI fits

The Production Reliability Index (PRI) combines different signals around a software change, including runtime information, code volatility, dependencies, deployment context, and other reliability indicators.

The purpose is to make change level reliability easier to assess before deployment.

Run a PRI assessment:

https://tomosu.ai/start

Production Reliability vs Static Analysis

Parsa Mohammadi — Tue, 29 Sep 2026 20:00:00 +0000

Static analysis examines code without running it.

Production reliability looks at what a change could mean when it reaches the real system.

Both are useful, but they answer different questions.

What static analysis does

Static analysis can identify problems such as:

Bugs and suspicious patterns
Type errors
Security issues
Code smells
Dependency problems
Violations of coding rules

It works directly on the code and its structure.

That makes it valuable early in the development process.

What static analysis cannot see by itself

A static analyzer does not necessarily know:

Which components are most important in production
How heavily a service is used
What incidents happened recently
Which deployment conditions apply
How a change interacts with current runtime behavior
How large the practical blast radius could be

That is where production context becomes useful.

Example: a shared authentication library

Suppose a pull request changes a shared authentication library.

Static analysis may find no obvious code problems.

The tests may pass.

But the library is used across many production services and the affected authentication path has recently been involved in incidents.

Nothing about the implementation necessarily looks wrong.

The production context still matters.

Static analysis is one signal

A broader model looks like:

Static analysis
       +
Testing
       +
Dependencies
       +
Production behavior
       +
Incident history
       +
Deployment conditions
       ↓
Reliability assessment

The goal is not to make one tool responsible for everything.

It is to combine useful evidence.

AI generated code

AI assisted development increases the volume of code changes.

Static analysis remains useful for checking the implementation.

But generated code can still introduce changes with unexpected dependencies or production impact.

That makes context important alongside code level analysis.

The main difference

Static analysis: What problems can we identify in the code?

Production reliability: What could this change mean for the production system?

Those questions overlap, but they are not interchangeable.

Where PRI fits

The Production Reliability Index (PRI) is designed to bring multiple signals around a change together so engineers can identify changes that deserve additional attention.

Run a PRI assessment:

https://tomosu.ai/start

Production Reliability vs Code Review

Parsa Mohammadi — Mon, 28 Sep 2026 20:00:00 +0000

Code review is one of the most established ways engineers evaluate software changes.

But code review and production reliability are not the same thing.

A reviewer can determine that an implementation is correct while still not knowing exactly how the change will behave across production dependencies, traffic, configuration, and existing system behavior.

The two questions are different:

Code review: Is the implementation correct?

Production reliability: What does this change mean for the running system?

What code review is good at

Code review can catch problems such as:

Incorrect logic
Bad API usage
Security issues
Poor error handling
Maintainability problems
Unclear implementation choices
Violations of project conventions

It is primarily focused on the implementation.

What production reliability adds

A production reliability assessment adds context around the change.

It asks:

What components are affected?
Which dependencies are involved?
How is this code used in production?
What testing covers the change?
Has this area caused incidents before?
How large could the blast radius be?
How easy is the change to roll back?

A reviewer may understand the code perfectly and still lack some of this context.

Example: a shared database library

Imagine a small change to a shared database library.

The diff is straightforward.

The code review looks good.

But the library is used by 40 services, several of those services handle customer transactions, and the affected query path has caused performance problems before.

The implementation may still be correct.

The production context simply makes the change more important to investigate.

Blast radius matters

The number of changed lines is not the same thing as production impact.

A small change in a shared component can have a large blast radius.

A large change in an isolated internal service may have a much smaller one.

That is why dependency and production usage are important parts of change assessment.

What about AI generated code?

AI assisted development makes this distinction more important.

AI can increase the amount of code produced and the number of changes entering review.

Code review still matters.

But the reviewer may need more context to understand what a generated change could affect.

Production reliability can provide another layer of evidence around the change.

Code review and observability

Observability answers another question: what is happening after the system is running?

Production reliability connects change context with production evidence before and around deployment.

They work together rather than replacing each other.

A practical workflow

Code change
    ↓
Code review
    ↓
Production context
    ↓
Dependencies + testing + history
    ↓
Deployment decision

The goal is not to replace code review.

It is to make the decision around the change more informed.

Where PRI fits

The Production Reliability Index (PRI) is designed to summarize multiple signals around a software change so engineers can identify where additional investigation may be useful.

The score is not a substitute for reviewing the underlying findings.

It is a way to bring the signals into one place.

The main idea

Code review asks whether the implementation makes sense.

Production reliability asks what the implementation could mean in production.

You need both perspectives when the goal is to understand a change before it reaches users.

https://tomosu.ai/start

What Is Production Reliability?

Parsa Mohammadi — Mon, 28 Sep 2026 12:23:10 +0000

A change can pass tests, pass code review, and still cause problems in production.

That is because production reliability is about more than whether code works in isolation.

It is about how a change behaves when it meets the real system: real traffic, real dependencies, real data, real configuration, and real users.

Production reliability is the ability of a software change to behave correctly and consistently under real production conditions.

Why production reliability is different from test results

Tests tell you what happened under the conditions you tested.

Production introduces conditions that are difficult to reproduce completely:

Different traffic patterns
Larger datasets
External dependency failures
Configuration differences
Concurrent requests
Unexpected inputs
Existing production behavior

A change can therefore have strong test evidence while still having meaningful uncertainty around production behavior.

What should you look at?

A useful assessment starts with the change itself and then adds context.

1. Change scope

What files, services, APIs, databases, or infrastructure are affected?

The size of a diff is useful context, but it does not tell you the full impact.

2. Dependencies

What depends on the changed component?

A small change to a shared library can have a much larger production impact than a large change inside an isolated service.

3. Testing and verification

What evidence exists that the important behavior works?

Look at unit tests, integration tests, end to end tests, regression tests, and failure cases.

4. Production behavior

How is the affected component actually used?

Traffic, data volume, runtime behavior, and external integrations can all change the practical impact of a change.

5. Change and incident history

Has this area caused incidents, rollbacks, or repeated regressions before?

History does not determine whether a change is safe, but it is useful context.

6. Deployment and rollback

What happens if the change behaves badly?

Can it be rolled back quickly? Can it be deployed gradually? Is a feature flag available?

Production reliability vs code review

Code review asks whether the implementation makes sense.

Production reliability asks what the implementation means for the running system.

You generally want both.

Production reliability vs observability

Observability tells you what is happening in a running system.

Production reliability adds change context: what changed, what it affects, and what could happen when it reaches production.

Observability is therefore one useful input into reliability assessment, not a replacement for it.

A practical model

A useful way to think about the assessment is:

Change
  ↓
Evidence
  ↓
Uncertainty
  ↓
Action

The goal is not to eliminate uncertainty before every deployment.

The goal is to find changes where the potential production impact and remaining uncertainty justify additional attention.

Where PRI fits

Tomosu's Production Reliability Index (PRI) brings multiple reliability signals together, including:

Fragility
Drift
Governance Compliance
Runtime Signals
Code Volatility
Deployment Velocity
Escalation

The number is useful as a summary, but the underlying evidence matters more than the number by itself.

The main idea

Production reliability is not a property of a diff alone.

It is a property of a change in context.

Change + dependencies + testing + production behavior + history + deployment conditions give engineers a much better picture of what may happen after a change ships.

Run a Production Reliability Index assessment:

https://tomosu.ai/start

What Is AI Observability? A Definition for Engineers

Parsa Mohammadi — Wed, 23 Sep 2026 14:42:36 +0000

AI observability is the practice of tracking what an AI system did and why.

That means looking beyond uptime and request latency and capturing things such as prompts, model responses, retrieved context, tool calls, agent decisions, latency, token usage, and evaluation results.

The distinction matters because an AI system can return a successful HTTP response and still produce the wrong result.

A normal monitoring system might tell you that the request returned 200. AI observability helps answer what happened inside that request.

Where standard monitoring stops

Traditional monitoring is built around questions such as:

Is the service up?
Is latency increasing?
Are requests failing?

Those signals are still useful.

But an AI application can fail while everything looks healthy from an infrastructure perspective.

Return an incorrect answer
Retrieve the wrong context
Call the wrong tool
Produce an unsafe action
Follow the wrong branch in an agent workflow

The infrastructure worked. The behavior didn't.

What an AI observability tool needs to capture

Prompt and response pairs

You need to know what went into the model and what came out.

Latency and cost

Track model usage at the call and workflow level.

Tool calls

For agents, the sequence matters. You want to know what the agent called, in what order, what it received, and whether it retried.

Retrieved context

For RAG systems, a bad response may come from bad retrieval rather than the model itself. Without the retrieved context, it's difficult to separate those failure modes.

Evaluation results

A system may behave differently over time even when the underlying infrastructure hasn't changed. Evaluation and observability together can show whether output quality is drifting.

Monitoring vs AI observability

Standard monitoring	AI observability
Uptime	Model behavior
Latency	Prompt and response
Error rate	Tool calls
Request failures	Agent decision sequence
Infrastructure state	Retrieved context
Is it running?	What did it do?

What changes when an agent writes code?

The problem becomes larger when the AI system isn't simply answering a user.

A coding agent can plan a change, read files, run commands, modify code, run tests, interpret results, modify the code again, and produce a final diff.

The final diff doesn't contain the whole decision path. If something breaks, you may need to know which tool call or intermediate decision caused the problem.

That's why agent observability needs to capture the sequence, not just the final output.

What AI observability doesn't do

Observability tells you what happened. It doesn't automatically stop a bad change from shipping.

You can know that an agent hallucinated a configuration value after the fact and still have no mechanism that prevented the change from merging.

That's a different problem.

You need a separate verification or governance step that asks: Should this change actually ship?

Observability helps explain failures. Production risk analysis is concerned with identifying risky changes before they become failures.

Full article: https://tomosu.ai/blogs/what-is-ai-observability.html