Feature Engineering Isn't Dead — It's Evolving

Every year or so someone publishes a take claiming that feature engineering is dead — AutoML will do it, foundation models will make it irrelevant, end-to-end deep learning will learn the representations directly from raw data. And every year, the teams doing serious ML work on enterprise tabular data are still writing feature engineering code, because the take is wrong.

Feature engineering isn't dead. It's evolving. Here's what that actually means in practice.

Why Features Still Matter Even in the GenAI Era

The models that run most enterprise AI workloads — fraud detection, risk scoring, demand forecasting, customer propensity models — are still trained on tabular features derived from transactional data. The accuracy of these models is determined more by feature quality than by model architecture. A gradient boosting model with good features will outperform a neural network with bad features. The signal is in the features.

What has changed: the boundary of "feature" has expanded. Traditional features are handcrafted numerical aggregations — average transaction amount in the last 30 days, days since last login, count of high-risk merchant categories in rolling window. Modern features include LLM-derived embeddings of free-text fields, semantic similarity scores, and model-generated classifications from unstructured data. The feature engineering skill set now includes both the classic transformations and the new embedding-based transformations.

The Feature Store as the Single Source of Truth

from databricks.feature_engineering import FeatureEngineeringClient

fe = FeatureEngineeringClient()

# Create a feature table — registered in Unity Catalog
fe.create_table(
name="prod_analytics.features.customer_behavioral",
primary_keys=["customer_id"],
timestamp_keys=["feature_date"],
schema=customer_features_df.schema,
description="Customer behavioral features for risk and propensity models"
)

# Write features — Unity Catalog lineage automatically tracked
fe.write_table(
name="prod_analytics.features.customer_behavioral",
df=customer_features_df,
mode="merge"
)

# Training: log the feature table lineage to the training run
training_set = fe.create_training_set(
df=labels_df,
feature_lookups=[
FeatureLookup(
table_name="prod_analytics.features.customer_behavioral",
lookup_key="customer_id",
timestamp_lookup_key="event_date"
)
],
label="churn_label",
exclude_columns=["customer_id", "event_date"]
)

My Critique of the End-to-End Narrative

The "end-to-end learning will eliminate feature engineering" narrative typically comes from researchers working with image data or text data, where deep learning genuinely does learn representations from raw inputs. It doesn't generalize to tabular data with business logic.

Whether a customer's most recent purchase was in a high-risk merchant category is a feature that requires understanding your organization's merchant risk taxonomy. A model cannot learn this from raw transaction data — it needs the encoding. That encoding is feature engineering. The business logic, domain knowledge, and careful thought about what signals predict the outcome of interest are not automatable. They're the intellectual work of the data scientist.

My Predictions for Feature Tooling in 2025

Feature freshness monitoring becomes standard — every feature has a defined acceptable staleness, and pipelines alert when features drift beyond that threshold. Embedding features get first-class treatment in feature stores: you'll be able to store and look up dense vector embeddings with the same infrastructure as scalar features. And feature importance explainability — understanding which features are driving which predictions — will get tighter integration with Unity Catalog, so you can trace from "the model made this decision" back to "these features caused it" back to "this source data populated those features." As always, I'm here to help.