Production AI is difficult because data science optimizes for rapid experimentation while software engineering optimizes for reliable, observable systems.
2
A feature platform must let teams define features, compute them across batch and streaming contexts, and retrieve them online and offline with historical accuracy.
3
Tecton uses Python-based workflows, notebook experimentation, data warehouse integration, and low-latency serving to connect model development with production applications.
Summary
Matt Bleifer explains how Tecton built a feature platform around the different needs of data scientists and software engineers. Data scientists want Python, notebooks, quick experimentation, and the freedom to install the tools they need. Software engineers need version control, code review, repeatable deployments, monitoring, reliability, and production service levels. Tecton's approach lets users experiment with feature definitions in notebooks, then move those definitions into Git-backed repositories and deploy them through a Tecton apply workflow. Its Rift engine runs Python transformations, integrates with Snowflake and BigQuery, and supports batch, streaming, backfills, and training data generation. Feature services expose vectors through an HTTP API for online inference and through a Python SDK for historical offline data. Matt also argues that generative AI applications follow many of the same data and serving patterns as predictive systems, so feature platforms may become a shared foundation for both.
Production AI requires data science and software engineering to work together
Matt says production AI is hard because data science and software engineering optimize for different things. Data scientists work in notebooks, iterate quickly, install Python packages, and focus on model quality. Software engineers need changes to be reversible and monitorable, with version control, code review, scale, latency, and reliability. A production AI application has to satisfy both sets of requirements because models and features become part of a live user-facing system.
A feature platform connects raw data to models in online and offline environments
Matt defines a feature platform as a system that connects to raw data, transforms it into features, and supplies those features for training and online inference. The online environment handles live application activity, such as transactions or recommendations. The offline environment is where teams train models and run data science work. The platform bridges the two so that the features used during training match the features available when the application makes a prediction.
Feature platforms have to define, compute, and retrieve features
Matt describes three jobs that every feature platform must handle. Users need a way to express a feature, identify its source data, define its transformations, and specify where it will be used. The platform then has to run the required batch, streaming, or real-time computation and manage backfills. Finally, it must serve features online at low latency and provide historically accurate offline values for training data.
Tecton first addressed the software engineering side by making feature definitions code. Users write declarative feature logic in a Git-backed repository, then run Tecton apply to compare the repository with production and review a deployment plan. Teams can put this process into CI/CD, with commits, code review, and a controlled production change. Matt says this gave ML engineering teams familiar software engineering practices, although it made rapid experimentation harder for data scientists.
Notebook experimentation keeps Python users productive before production deployment
Tecton adapted its workflow so users can place the same declarative definitions inside a Jupyter notebook. They can query feature values for a time range, inspect the resulting data, and train a model without first pushing every experiment through Git. Once the feature is ready, they move the definition into the main feature repository and use the same controlled deployment process. This separates fast exploration from the final production change.
Rift removes Spark from the normal Python feature workflow
Tecton initially used Spark for batch pipelines, streaming pipelines, and training data generation, while managing clusters, retries, orchestration, and backfills for users. Matt says this worked for software engineers but exposed data scientists to Spark jobs, tuning, and constrained notebook environments. Tecton built Rift so feature transformations can run in Python or pandas and can be explored in ordinary Python environments. Users can keep pip-installing the packages they need.
Rift combines Python transformations with warehouse computation
Rift integrates with data warehouses so batch features can be expressed in Snowflake SQL or BigQuery SQL. Tecton pushes relevant computation into the warehouse and makes the resulting features available there for analysis. Matt also says Rift processes large event sets for backfills, training data jobs, and streaming pipelines, using DuckDB, Ray, Arrow, and Tecton's aggregation framework underneath.
Online serving and historical training data use different interfaces
A Tecton feature service defines the features required by a model. For live inference, an application calls an HTTP API and receives a feature vector that can be passed to the model. For offline work, the Python SDK generates training data with time travel, allowing a team to ask what a feature's value was at the time of a past event. Matt connects these two interfaces to model quality and low-latency application behavior.
Generative AI follows many of the same data workflows as predictive AI
Matt compares a conventional predictive application with a retrieval-augmented generation application. Predictive systems turn data into structured features, store them for lookup, run a model, and change application behavior. RAG systems turn data into embeddings, store them in a vector database, retrieve documents, pass context to an LLM, and use the output in the application. He argues that both involve similar data pipelines and a similar need to connect offline experimentation with online production.
"Instead of your iteration loop being part of that declarative GitOps workflow, we say, hey, iterate inside of your Jupyter notebook where you're happy and only as a final step should you store and manage this all as code and push that to production."12:26
Who should watch
You are building a feature platform and need to balance notebook experimentation with controlled production deployment.
Your ML team is tired of exposing data scientists to Spark operations, cluster tuning, and custom orchestration work.
You are deciding how a feature platform might support retrieval-augmented generation alongside conventional predictive applications.
