DEV Community

Cover image for Drawing Probability Trees by Hand Is Annoying, So I Built This
Ajiaxi
Ajiaxi

Posted on

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

#ai #webdev #showdev #programming

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
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

Or:

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

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
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

the application should immediately know something is wrong because:

0.4 + 0.3 + 0.4 = 1.1
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

But that isn't how people actually work.

Users want to generate something and then change it.

For example:

Flip a fair coin twice.
Enter fullscreen mode Exit fullscreen mode

might generate the first version of a tree.

Then the user might decide:

Actually, make the coin 70% likely to land heads.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

This is the easiest sanity check.

Each branch should remain:

Heads = 0.5
Tails = 0.5
Enter fullscreen mode Exit fullscreen mode

and each final path should have probability:

0.5 × 0.5 = 0.25
Enter fullscreen mode Exit fullscreen mode

Drawing without replacement 

A bag contains 5 red balls and 3 blue balls.
Draw two balls without replacement.
Enter fullscreen mode Exit fullscreen mode

The first event is:

Red = 5/8
Blue = 3/8
Enter fullscreen mode Exit fullscreen mode

But after drawing red, the next event becomes:

Red = 4/7
Blue = 3/7
Enter fullscreen mode Exit fullscreen mode

After drawing blue:

Red = 5/7
Blue = 2/7
Enter fullscreen mode Exit fullscreen mode

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%
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (1)

Collapse
 
crdtcto profile image
Kane Lim •

Hello Glad to see you, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.

I really like the separation between probabilistic semantics and deterministic execution. I would push this further by representing the generated model as an immutable intermediate representation, with each node carrying conditional probability expressions rather than only resolved values.

That enables symbolic validation before evaluation, dependency tracking for without replacement scenarios, automatic recomputation after edits, and reproducible test cases. For the layout engine, a constraint based tree layout with incremental positioning would avoid rebuilding the entire graph after every mutation.

I would also add property based testing against known probability invariants, especially conservation of probability and conditional independence assumptions. AI should produce the semantic model, while the calculation engine remains completely deterministic and auditable.

This could evolve into a very interesting educational reasoning system. I would enjoy exchanging ideas around the parser and graph architecture.