Drawing Probability Trees by Hand Is Annoying, So I Built This

Ajiaxi — Mon, 31 Aug 2026 14:15:07 +0000

Probability trees look simple.

You start with an event, add a few branches, write probabilities next to them, and calculate the probability of each path.

Easy, right?

That was what I thought too.

Then I started thinking about what it would take to generate a probability tree automatically from something like:

A bag contains 5 red balls and 3 blue balls. Two balls are drawn without replacement.

Suddenly, it was no longer just a drawing problem.

The system needs to understand the scenario, identify events and outcomes, calculate conditional probabilities, validate the math, position the nodes, and still make the result easy to edit.

That experiment eventually became ProbPath, a browser-based probability tree generator.

But building it taught me a few things that turned out to be much more interesting than simply drawing a tree.

1. Natural language is messy

A probability engine would probably prefer input like this:

P(Red) = 5/8
P(Blue) = 3/8

P(Red | Red first) = 4/7
P(Blue | Red first) = 3/7

Unfortunately, humans usually don't describe probability problems like that.

They write:

There are 5 red balls and 3 blue balls in a bag.
Two balls are drawn without replacement.

Or:

A test has 95% sensitivity, a 5% false positive rate,
and the disease prevalence is 1%.

So before generating any visualization, the first problem is turning natural language into a structured probability model.

Conceptually, the result might look something like:

{
  "event": "First draw",
  "outcomes": [
    {
      "label": "Red",
      "probability": 0.625
    },
    {
      "label": "Blue",
      "probability": 0.375
    }
  ]
}

For dependent events, each branch may then contain a different set of next-step probabilities.

This distinction matters because the tree is not just visual decoration.

The structure determines the math.

2. I don't want AI to be the source of truth for the math

One design principle became important very quickly:

Use AI to understand the problem. Use deterministic code to calculate the probabilities.

An AI model is useful for interpreting what the user means.

For example, it can recognize that:

Draw two balls without replacement

means the second probability depends on what happened during the first draw.

But once the structure is understood, calculations such as:

5/8 × 3/7 = 15/56

should not need to depend on an AI model guessing the answer correctly.

The same applies to validation.

If a node has three outgoing branches:

A = 0.4
B = 0.3
C = 0.4

the application should immediately know something is wrong because:

0.4 + 0.3 + 0.4 = 1.1

That kind of validation is deterministic.

This led to a simple separation of responsibilities:

Natural language
      ↓
AI interpretation
      ↓
Structured probability model
      ↓
Deterministic calculation
      ↓
Validation
      ↓
Visualization

I like this pattern beyond probability tools too.

AI can be very useful at the fuzzy boundary where humans express intent.

Once the intent has been converted into structured data, traditional software is often still the better tool for enforcing rules.

3. Drawing the tree was harder than I expected

A two-level tree is easy.

           Start
          /     \
        Red     Blue

The problem appears when the tree grows.

Imagine something closer to this:

Start
├── A
│   ├── A1
│   ├── A2
│   └── A3
├── B
│   ├── B1
│   └── B2
└── C
    ├── C1
    ├── C2
    ├── C3
    └── C4

Now the visualization needs to answer several questions:

How much vertical space should each subtree receive?
How far apart should parent and child nodes be?
How do you avoid overlapping labels?
What happens when one branch becomes much deeper than the others?
How should the layout change when the user adds another outcome?
How much should the canvas expand before the tree becomes difficult to navigate?

At that point, I realized that a probability tree generator is partly a graph-layout problem.

Rendering lines and boxes is easy.

Deciding where they should go is the interesting part.

4. Generation shouldn't be the final state

My first mental model for the product was basically:

Describe problem
      ↓
Generate tree
      ↓
Done

But that isn't how people actually work.

Users want to generate something and then change it.

For example:

Flip a fair coin twice.

might generate the first version of a tree.

Then the user might decide:

Actually, make the coin 70% likely to land heads.

Or they might want to rename an outcome, add another stage, delete a branch, or change a probability directly.

So the workflow became closer to:

Describe
   ↓
Generate
   ↓
Edit
   ↓
Recalculate
   ↓
Validate
   ↓
Export

That changed how I thought about the product.

AI generation is useful for removing the blank page.

But the generated result still needs to behave like normal software.

It needs to be editable.

A few probability problems I use for testing

Simple examples are useful, but the more interesting cases are the ones where the probability changes along the tree.

Coin flips

Flip a fair coin twice.

This is the easiest sanity check.

Each branch should remain:

Heads = 0.5
Tails = 0.5

and each final path should have probability:

0.5 × 0.5 = 0.25

Drawing without replacement

A bag contains 5 red balls and 3 blue balls.
Draw two balls without replacement.

The first event is:

Red = 5/8
Blue = 3/8

But after drawing red, the next event becomes:

Red = 4/7
Blue = 3/7

After drawing blue:

Red = 5/7
Blue = 2/7

This is where probability trees become particularly useful because the diagram makes conditional probabilities much easier to follow.

Medical testing

Another good example is Bayes-style problems.

Suppose:

Disease prevalence = 1%
Sensitivity = 95%
False positive rate = 5%

A common intuition is:

If the test is 95% accurate and I test positive, I must have around a 95% chance of having the disease.

But that's not what the numbers imply.

A probability tree makes the base-rate effect much easier to see visually.

This is one of the reasons I like probability trees: they are not only calculation tools.

They are reasoning tools.

What I ended up building

The experiment became ProbPath.

It lets you describe a probability scenario in natural language and turn it into a visual probability tree.

From there, the tree can be edited and recalculated rather than treated as a static AI-generated image.

You can try it here:

https://probpath.com/

The main goal is pretty simple:

Make probability trees faster to create without hiding the underlying math.

I'm also experimenting with more traditional manual tools for people who prefer building the tree themselves instead of starting with AI.

What I learned

A few ideas from this project have stuck with me.

1. Let AI interpret. Let code calculate.

Natural language understanding is fuzzy.

Probability rules are not.

Separating the two makes the system easier to reason about and easier to validate.

2. Generated interfaces still need to be editable.

Generation is great for getting from zero to one.

But users still need control after generation.

3. Visualization problems often become layout problems.

The hardest part wasn't drawing nodes and branches.

It was deciding where everything should go as the tree changes.

4. Small educational tools can hide interesting engineering problems.

A probability tree generator sounds like a very small application.

But once you combine natural-language parsing, structured data, mathematical validation, graph layout, editing, and export, there are quite a few interesting problems inside it.

I'm still working on ProbPath and experimenting with better ways to handle larger trees, conditional probability, and more advanced probability problems.

If you've built graph editors, diagramming tools, math visualizations, or AI-to-structured-data workflows, I'd be interested to hear how you approached similar problems.

DEV Community: Ajiaxi