Not because it found a magical model, but because it removed a large amount of repetitive feature plumbing across hundreds of series.
TL;DR: Good forecasting tooling moves effort away from repeated plumbing and toward forecasting judgment. Define the feature recipe once, apply it consistently across every series, and make the forecast cutoff explicit — the value is in what you decide, not in how many times you rewrite the lag code.
In multi-series forecasting, the same mechanics appear again and again: build lags per series, add rolling and expanding transforms, create calendar features, preserve time ordering, generate multi-step forecasts, and repeat the process consistently across hundreds of series. That work matters. But rebuilding it manually for every project creates fragile code and slows down iteration.
Instead of hand-writing the plumbing every time, you define the forecasting recipe once: the lags, the lag transforms, the date features, and a scikit-learn-compatible model. Then you apply that same recipe consistently across all your series.
Historical target values plus rolling and expanding transforms, defined once in the recipe and applied consistently to every series.
Day of week, month, and holiday signals added consistently so the model can learn seasonality without custom code per series.
Anything from the sklearn ecosystem — LightGBM, XGBoost, CatBoost, or a linear model — plugs in without rewriting the pipeline.
The same feature definition fans out across all series instead of duplicating feature logic as the collection grows.
The gain is not "zero thinking." You still need to decide what history is available at forecast time, which lags make sense, which validation scheme matches the horizon, whether future exogenous inputs are genuinely known, and how to monitor drift and forecast quality. The difference is that the tool pushes the effort away from repeated plumbing and toward those decisions.
Less custom lag code to maintain. More time for validation, signal design, and forecasting judgment. The forecast cutoff becomes explicit — you build features only from what would have been known at forecast time — which keeps the whole pipeline honest about leakage. And a single reusable recipe fans out to every series instead of duplicating feature logic, so the code stays clean as the number of series grows.
Design insight: Good forecasting tooling moves effort away from repeated plumbing and toward forecasting judgment. Define the feature recipe once, apply it consistently across every series, and make the forecast cutoff explicit — the value is in what you decide, not in how many times you rewrite the lag code.
Purged Cross-Validation Is Not for Every Time Series →RevIN: When a Neural Forecast Learns Only One Scale →Make a Simple Forecasting Baseline Fail First →An LLM-Derived Feature Is Still a Feature → Route Structurally Inactive Series Before Forecasting →Seed Sensitivity Is Part of Model Selection →TabPFN: a Pre-Trained Prior for Tabular ML →Aggregate → Forecast → Disaggregate →Nixtla Forecasting Libraries → Turning Decomposition into a Forecasting Strategy → Forecasting Routing Layer → Conformal Prediction → LightGBM vs XGBoost in 2026 → AgriBORA Maize Price Forecasting → Sea Turtle Forecasting → Encoding Is a Modeling Decision → Zero-Shot Forecasting Changes the Baseline →Foundation Models Raise the Baseline →A Strong AutoML Baseline Can Beat Hand-Tuned Models →Conformal Prediction: Calibrated Forecast Intervals →
Good forecasting tooling moves effort away from repeated plumbing and toward forecasting judgment. Define the feature recipe once, apply it consistently across every series, and make the forecast cutoff explicit — the value is in what you decide, not in how many times you rewrite the lag code.
This was written by Mahmoud Trigui, Senior Data Scientist. MLforecast removes the repetitive lag, rolling, and calendar feature plumbing of multi-series forecasting so you can spend time on validation and signal design.