In a tool-calling chatbot, the model never runs a tool: it only asks your code to. This post follows one question through Quick Math Coach, a mental-maths tutor that demonstrates the mechanics of tool calling, from the user’s message to the answer, with traces from a real run.
For a long time my picture of an “agent chatbot” was simple: you type, the model types back, repeat. I knew that tool calling was what let a chatbot look things up, run code or call an API, and I had used products that did it. But if you had asked me what actually happens between my question and the answer, who calls what, and how the model even knows a tool exists, I would have waved my hands. So I built a small one to find out.
How a plain Python model grows, one stage at a time, from a prototype on local files into scheduled Databricks jobs: running laptop code against Unity Catalog with Databricks Connect, tracking the model with MLflow, and deploying the same files with Asset Bundles.
Most models start life the same way: a few Python files on a laptop, a data extract in a folder, and a metric that looks promising. Getting from there to a model that runs every day on its own, reading live data and writing predictions somewhere other people can use them, is a different kind of work. The model code barely changes. What changes is where the data lives, where the code runs, and who presses the button.
The web development world is huge, and an LLM can write the boilerplate for any of it. What it cannot do for you is choose. This post surveys the popular options, breaks any use case into twelve functionalities, and ends with a skill file you can hand to your own assistant.
Almost every analysis I have worked on ends in the same small moment: someone needs to see it. A chart in a notebook is often enough to convince me, but it rarely convinces a colleague or stakeholder who is never going to open that notebook. A small web app can. It lets them move a slider, filter to their own region, or type in a value and watch the model’s answer change, which feels very different from looking at a screenshot.
Sequence alignment on Rosalind looks like thirteen unrelated puzzles, until you notice most of them are the same dynamic programming recurrence wearing different clothes. This post traces how one DP engine, parameterized by a scoring function, a gap model, and four free-start/free-end flags, grows from counting point mutations into global, local, overlap, semiglobal, affine-gap, and multiple alignment.
A reusable OOP framework for optimization problems: Config, Problem, Builder, SolverStrategy, and Report as five composable layers, worked through two use cases, the Berth Allocation Problem and Citi Bike station rebalancing, each solved with a greedy heuristic and an exact MIP.
I’ve been deep in an optimization problem for work recently, formulating it as a mixed-integer program and building a few different ways to solve it. I won’t get into what the problem actually is here, that part is specific to my job, but the experience behind this post is not.