Inspiration

I built Algorithm Studio because I was tired of pretending I understood algorithms.

As a student, I could memorize a formula and repeat a textbook definition, but I still didn’t feel like I truly understood how the algorithm worked. Papers and diagrams often assumed too much, and learning one method meant piecing together AI answers, videos, articles, notebooks, and code. Then a classmate would explain it with a few scribbles and one tiny example, and suddenly the whole thing made sense.

Years later, I entered industry and found the same challenge, except now it affects real product and business decisions.

Every new use case starts with hours of research: Which methods might work? What assumptions do they make? Which approach is worth testing? Before I can run an experiment, I first have to turn scattered technical material into a working mental model.

Algorithm Studio recreates that step-by-step classmate experience. It turns a method—or a real-world problem—into an interactive example where every decision can be followed, questioned, and tested.

It is the tool I wish I had as a student and still need today as a data scientist.

What it does

Algorithm Studio supports two starting points.

1. Learn a method

A learner can request an algorithm directly:

Teach me Dijkstra’s algorithm.

Algorithm Studio constructs a deliberately small example and turns its execution into an interactive lesson. The learner can:

  • Move through the algorithm one step at a time.
  • Inspect the values and state at each step.
  • See the process represented as a graph, matrix, sequence, or structured state.
  • Ask follow-up questions about the current step.
  • Change the input and compare the resulting trace.
  • Take generated Python starter code into their own environment.

2. Find a method

A user can also begin with a real problem:

I need to route delivery vehicles with capacity limits and customer time windows. Which methods should I consider?

Algorithm Studio identifies the important constraints, compares plausible approaches, explains their tradeoffs, and recommends a starting point. The user can then turn that recommendation directly into a visual lesson.

How we built it

I wanted an architecture that was simple to run locally but flexible enough to support more than a predefined list of algorithms. Instead of hardcoding a separate animation for every method, the core idea was to treat the model as a lesson compiler. When a user requests a method, GPT-5.6 Terra creates a small example, uses Code Interpreter to work through it, and returns the result through a strict lesson schema. That schema describes the steps, explanations, values, verification checks, and visual format. The frontend renders those instructions using reusable graph, matrix, sequence, and state components.

Method recommendations and follow-up questions use GPT-5.6 Luna because those interactions need to feel faster and do not require Code Interpreter. Web search can also be enabled when a lesson needs additional supporting information.

The rest of the product is intentionally deterministic. Flask handles the API, Pydantic validates model output, vanilla JavaScript renders the lessons, and SQLite saves them locally. Caching and generation locks prevent duplicate requests, while failed variations remain isolated so the original lesson never disappears.

I used Codex as a technical product partner throughout the process. It helped me challenge the original scope, design the architecture, implement the backend and frontend, investigate failed generations, improve cost and latency, write tests, and prepare the repository. I made the product decisions and tested the experience as a user, while Codex helped turn each round of feedback into a working iteration.

Challenges we ran into

Reliability versus open-ended generation

Generated lessons can be incomplete, malformed, or difficult to visualize. We addressed this with strict structured outputs, Pydantic validation, bounded lesson sizes, and reusable renderers. Structural validation does not guarantee mathematical correctness, so the product is transparent about its role as a learning aid. Stronger algorithm-specific evaluation is an important next step.

Maintaining visual consistency

Our early variation flow could replace an intuitive graph with a less useful visualization. We learned that technically valid output is not automatically good teaching.

Cost and latency

A complete lesson is more expensive than a normal text answer because it includes an example, execution trace, explanations, visuals, verification, and code. We reduced unnecessary usage through:

  • Routing lightweight interactions to a faster model
  • Saving successful lessons locally
  • Reopening lessons without regeneration
  • Sharing concurrent identical generations
  • Briefly caching repeated failures
  • Returning only changed lesson fields for variations
  • Keeping examples and lesson traces intentionally small

What we learned

The first version of an idea is not always where its real value lives. Algorithm Studio began as a proof-of-concept helper, but testing the experience showed that the more important problem was helping people understand and choose a method before they tried to implement it. That insight shifted the product toward method discovery, interactive lessons, follow-up questions, editable examples, saved lessons, and starter code.

I also learned a completely different way of building software. As a data scientist who came from the “dark era” of writing and debugging every line by hand, working with Codex felt like moving up a level of abstraction. I could spend more time thinking about the user, challenging product decisions, and testing the experience, while Codex helped translate those decisions into working software.

What's next for Algorithm Studio

The local application can become a hosted learning service with collaborative learning space and experiment accelerator. Users could describe their data schema and constraints, then receive customized proof-of-concept code and an evaluation plan for testing whether the selected method fits their use case.

Our long-term vision is simple: Any learner should be able to move from an unfamiliar algorithm to a working mental model—and from that mental model to a confident experiment.

Built With

Share this project:

Updates