Tecton 0.6 lets teams define, develop, and test features directly in a Python notebook before moving them into the production repository.
2
Notebook-driven development shortens the feature iteration loop by letting engineers validate dependencies, transformations, feature views, and feature services in one environment.
3
Production deployment still uses the existing repository and CI/CD workflow, with Tecton CLI applying validated feature definitions to a cluster.
Summary
Jason Dunne presents notebook-driven development in Tecton 0.6. He starts with the difficulty of building and maintaining real-time ML systems, using Uber Eats and fraud detection to explain why feature engineering needs reliable data flows and fast iteration. The new workflow lets data scientists, data engineers, and ML engineers retrieve existing features, define new ones, validate them, combine them with existing features, and generate point-in-time accurate training data from a Python notebook. Once a feature improves a model, its definition can be copied into a feature repository and sent through the normal CI/CD process. Tecton does not replace the production apply step or require teams to abandon their existing workflow. Dunne also discusses stream ingest and built-in aggregation functions, which support lower-latency pipelines and feature development. He is clear that notebook work is for development and testing, while production changes still require coordination and appropriate validation coverage.
Real-time ML depends on feature pipelines built from many live and batch sources
Dunne uses Uber Eats to show how raw inputs such as live deliveries, driver locations, and restaurant orders become features for an ETA model. Examples include restaurant order count over 30 minutes and available drivers over five minutes. He then uses fraud detection as the main demo scenario, while also naming recommendations, loan approvals, ranking, search, dynamic pricing, and personalization. The point is practical: real-time predictions depend on feature transformations that combine different data sources before online inference or offline training.
Maintaining real-time ML systems is harder than building the first version
Dunne says teams often end up with siloed, error-prone, brittle systems that are difficult to scale. The architecture may span real-time user inputs, streaming sources such as Kafka and Kinesis, and batch systems such as Snowflake, Delta, S3, and Redshift. A feature platform is intended to connect those pieces while supporting feature development, standardization, monitoring, cost control, online inference, and offline training. Tecton's feature repository, feature engine, and feature store fit into that larger flow alongside existing GitOps and CI/CD practices.
Tecton 0.6 moves feature development and validation into Python notebooks
The new capability lets users develop and test features directly in a notebook after setting up the feature platform. They can validate a feature as they go, retrieve existing features, and generate training data before productionizing the result. Dunne describes this as reducing the number of steps in feature creation and making one part of the model iteration loop faster. The feature definition remains compatible with the normal production process, so notebook development does not require changing how teams ultimately deploy features.
Notebook validation can produce point-in-time accurate training data
The example creates a feature for the average transaction amount for a user during the previous 30 days, with daily refreshes and a backfill beginning on January 1, 2022. Tecton's get historical features function joins existing features to raw transaction data and computes the new feature values. That produces a training dataset for testing a new model version against the current champion. If the new feature helps, the definition can be copied into the Tecton repository and sent through CI/CD.
The notebook is for development and testing, while production still uses the CLI
In the live walkthrough, Dunne validates a feature view from a notebook by selecting a workspace, entity, and stream feature view, then checking its dependencies, transformation, feature view, and feature service. The notebook can show transaction fields and run Spark jobs. It does not replace the apply step. After validation, the feature definition is placed in a Python file in the feature repository, adjusted to use the right data source and entity, and applied from the CLI. The resulting feature then appears in the production environment.
Notebook-driven development is related to test-driven development, but it is broader
In response to Demetrios Brinkmann, Dunne distinguishes the capability from test-driven development. He describes test-driven development as a way to structure a workflow, while notebook-driven development makes Jupyter or Python notebooks central to developing and validating features. Users can use it simply to confirm that the correct entities and data are being pulled, even without extensive tests. More validation coverage can still reduce the chance that untested scenarios reach production.
Concurrent notebook work stays separate until a production change is applied
Dunne says that creating and testing a new feature in a notebook does not conflict with features already live in production. Coordination with teammates becomes necessary when changes are applied through the shared GitOps workflow. He also says developers can intentionally sample data during development, such as pulling every tenth transaction, when they only need a quick validation. This can make exploratory checks faster, but production changes still need enough coverage for the relevant scenarios.
Tecton 0.6 also adds stream ingest for lower-latency feature pipelines
Dunne briefly describes a new API for stream ingest. It lets teams bring in and refresh data with lower ingestion latency, which supports real-time feature pipelines. He connects this with notebook-driven development and Tecton's built-in aggregation functions. Together, these capabilities help users define new feature logic, inspect the resulting data, and prepare features for real-time machine learning use cases.
"The ultimate outcome that we're really looking to help to support and enable is, as you set up and learn the feature platform, you can jump straight into being able to develop and test features directly within notebook-driven development."13:15
Who should watch
You are building real-time ML features and want a shorter path from exploration to a validated training dataset.
Your team passes notebook work between data scientists and ML engineers and wants to reduce manual refactoring before production.
You already use a repository and CI/CD process for feature deployment and want notebook-based development without replacing that process.
