Most business value from automated decisions still comes from predictive ML and rules-based systems rather than LLMs.
2
Feature stores emerged because data pipelines repeatedly blocked ML projects from reaching production.
3
ML infrastructure should match the business value, reliability needs, and maturity of each use case.
Summary
Mike Del Balso explains what he learned building production ML systems at Google, Uber, and Tecton. He describes how Uber moved from scattered ML experiments to a central platform, with feature pipelines becoming a major source of repeated work and the reason Tecton was founded. He maps the maturity of ML use cases, from hand-coded rules to trained models and highly operational decision systems. Fraud, underwriting, acquisition, recommendations, and real-time pricing can directly affect revenue and losses, so teams need strong reliability and fast response. Other projects may be exploratory and do not need the same operational investment. Mike also discusses how teams measure ML value, why speed and model accuracy are useful dimensions, and how Tecton's AI co-pilot can help subject-matter experts and ML engineers create features. Generative AI fits into this world by helping build predictive systems and by combining with them in applications that use shared, governed data.
Production decisions are where ML creates business value
Mike contrasts the current excitement around generative AI with the predictive ML systems already making many business decisions. At Google, he worked on the ads decisioning system that chooses which ads appear in search. At Uber, his team supported pricing, fraud detection, and other decisions used in live products. He argues that a model matters only when it reaches users and affects the business. Some companies depend on automated decisions as part of their core business model, while other ML projects remain experiments. That difference should affect how teams prioritize work and how much operational support they provide.
Repeated data pipeline work led to the feature store
At Uber, the team first built basic model training and serving infrastructure, then found that data pipelines were the recurring blocker in almost every project. Teams needed to collect, transform, and connect data so models could use it for prediction. The platform group kept rebuilding similar pipelines for surge pricing, ETA, fraud detection, and other projects. Mike says they centralized and automated that work in a feature store. It let teams configure transformations, make data available to models in real time, and build high-quality training sets without asking the central platform team to construct every pipeline.
ML use cases move from rules to models as they mature
Mike describes a common progression for business decision systems. Teams often begin with simple if statements, add more business logic, then adopt a rules engine. In financial services, rules engines can become elaborate collections of hand-coded cases. When those systems become brittle, teams may train a model and replace or supplement the rules. Fintech companies often organize their work around customer acquisition, risk estimation, fraud detection, operational support, and personalization. The right system depends on the decision, the available data, and how directly the decision affects the business.
Fraud and underwriting need continuous, fast decision systems
Fraud detection and financial risk are examples where automated decisions can directly change revenue and losses. Mike says fraud is a continuing contest because attackers may train models to imitate anti-fraud systems. A company may build its own model when its proprietary customer data is especially predictive, or use an external fraud service when the problem is more generic. More mature teams combine both approaches, using outside models as additional signals. Fraud thresholds also require tradeoffs. Rejecting every suspected fraudster can reject too many legitimate customers, so the best threshold may allow some fraud if it lets in many more good customers.
Operational investment should match the use case's value and failure cost
Mike separates mission-critical decision systems from exploratory projects. Fraud, real-time pricing, and recommendations often run inside live customer flows where a person cannot review every decision. These systems need reliability, disaster recovery, and resilience. Other projects may produce forecasts for a slide deck or predictions used later, so a failure may only require pressing retry. He says teams should decide which service levels they are willing to take on instead of treating every model as mission critical. A large insurance company may move more slowly because it checks each reliability and recovery requirement before putting a system into production.
ML platform value is hard to reduce to a single dollar number
Mike says platform teams struggle to track the business impact of their work across many internal users. Asking each team how much money a platform saved or made produces estimates that change, become outdated, and depend on whether the team chose the right project. He suggests thinking about value through several dimensions: helping a team run more iterations, improving model accuracy with better signals, and providing reliability and scale. Faster delivery can turn a six-month cycle into something much shorter. Better architecture can also reduce waste, such as recomputing data unnecessarily or running duplicate pipelines.
An AI co-pilot can connect ML skills with domain knowledge
Tecton's AI co-pilot is aimed at people building predictive ML systems. Mike describes two common roles: an ML specialist who may not understand the business problem deeply, and a subject-matter expert who understands the problem but is not an advanced ML engineer. The co-pilot can inspect data, suggest feature ideas, and help turn a small transformation into a productionized feature. Domain experts can point it toward suspicious customer segments or other signals based on years of experience. The system can then propose features for evaluation, while experts can reject signals they know should not be used.
Predictive ML and generative AI can share one decision system
Mike describes generative AI as useful both for building predictive ML systems and for applications that combine predictive models with generation. In a marketing application, predictive models may estimate customer attributes or preferences, then feed those signals into a generative model that writes personalized text. Tecton can also provide embeddings and process unstructured data for generative applications. Mike argues that keeping the signals in one governed data system allows teams to reuse computation, apply compliance controls, and send consistent context to different decision systems.
"The thing that was surprisingly a major blocker that we practically spent a ton of time on in every individual project was just the data pipelines."Mike Del Balso04:04
Who should watch
You are building an ML platform and need to decide which data, serving, and reliability problems deserve central investment.
Your team is trying to explain the business value of model accuracy, faster iteration, or better infrastructure to company leadership.
You are combining predictive models with generative AI and need shared data, feature reuse, and governance across both systems.
