The ML-to-production field guide: who shapes what breaks and why

The shortlist below is grouped by influence on the practitioner community, meaning the degree to which each entry has changed how data teams actually think about moving models from experiment to production. Revenue figures are irrelevant here; what matters is whether teams at real companies have changed their behaviour because of this work. Five entries, no filler.

The field guide

DuckDB and the DuckLake project

DuckDB started as an academic project at CWI Amsterdam and has become the runtime of choice for engineers who need analytical SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.View full definition → without spinning up a cluster. The recent DuckLake work, covered in Towards Data Science, extends the idea: start with a local Parquet file, join it to data stored in the cloud, and you have a functional lakehouselakehouseA hybrid architecture combining the flexibility of a data lake with the analytical capabilities of a data warehouse, on a single storage layer.View full definition → in minutes. What makes this notable for production ML is the friction it removes at the data layer. Most pilots fail not because the model is wrong but because the data pipelinedata pipelineETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.View full definition → is a mess of undocumented dependencies. DuckLake gives small teams a path to aunified analytical and ML data layer without a six-month infrastructure project first. That changes the pilot-to-production calculus materially.

dbt Labs and the open lakehouse pivot

At dbt Summit 2026, dbt Labs (a commercial data tooling vendor, so treat the framing with appropriate scepticism) announced dbt v2, dbt State, and a stated "open lakehouse vision" alongside Fivetran. dbt State is now generally available and the company's own description is that it was built to stop rebuilding what had not changed: the system tracks transformation state so only modified models rerun. For production ML, this matters because retraining pipelines routinely rebuild everything regardless of what changed, burning compute and introducing unnecessary variance. The dbt State approach, if applied to feature pipelines, is a practical answer to that waste. The commercial relationship between dbt Labs and Fivetran means the full vision should be evaluated against independent benchmarks before committing, but the underlying mechanism is sound.

The Zed editor team and the rethinking of developer workflow

Zed's Delta project, reported by The New Stack in September 2026, launched on the premise that AI agentsAI agentsAgentic AI refers to AI systems that pursue goals autonomously by planning, taking actions through tools, and adapting based on results, with minimal step-by-step human direction.View full definition → have made the pull request model obsolete and that everyone is racing to replace GitHub's collaboration layer. This is relevant to ML production for a less obvious reason: the bottleneck in most MLOpsMLOpsMachine Learning Operations: combining ML and DevOps practices to industrialise, deploy, monitor, and retrain models reliably in production.View full definition → pipelines is not model quality but code review and deployment ceremony. When agents generate, test, and merge code faster than human review cycles allow, the organisational process becomes the constraint. Zed's bet is that the tooling layer needs to rebuild around agent-native workflows. Whether Delta succeeds commercially is a separate question; the diagnosis of where production ML slows down is accurate.

The O'Reilly Radar analysts tracking enterprise analytics

O'Reilly's ongoing Radar work on intelligent data orchestration with LLMs documents a pattern that anyone who has tried to ship a model to production will recognise: organisations spend years building dashboards that answer last quarter's questions, then discover that the model they trained needs answers to this week's questions. The observation from O'Reilly's analysts, drawn from 17 years of enterprise platform work, is that the question "can I ask one thing and get one answer across everything my company knows" has driven every serious data architecture decision. The production ML failure mode this names is the query gap: the training distribution does not match the operational distribution, anddetecting that drift before it reaches your users requires infrastructure most teams have not built.

MIT Sloan Management Review on the skills lag

MIT Sloan's 2026 research on emerging tech skills found that reskilling programs are typically built around forecasted skill needs rather than observed ones, which creates a predictable mismatch. For CDOs trying to move pilots into production, this surfaces as a hiring and team composition problem: the person who built the pilot in a notebook often does not have the software engineering background to own the production system, and the software engineer assigned to productionise the model often does not understand what the model is doing. MIT Sloan's data suggests the gap is structural, not a training problem that a weekend course fixes. That is an uncomfortable finding, and it is worth taking seriously precisely because it comes from independent research rather than a vendor with a platform to sell.

The pattern, what these standouts share

Every entry on this list is responding to the same underlying problem from a different angle. DuckDB and DuckLake attack the data infrastructure gap. dbt State attacks the compute and reproducibility gap. Zed attacks the deployment workflow gap. O'Reilly names the query distribution gap. MIT Sloan names the skills gap. None of them is solving "ML." They are each solving one specific failure mode in the path from a working model to a working system.

The implication for CDOs is that "ML to production" is not a single problem with a single solution. It is five or six distinct failure modes that happen to be sequential. Organisations that treat it as one problem tend to fix the most visible one, usually model accuracy, and then discover the next one waiting. The teams making genuine progress in 2026 are the ones that have named each failure mode separately and assigned ownership accordingly.

The honest lesson from this shortlist: the most valuable skill in ML production is not building better models, it is knowing which layer is actually broken.

Who to watch: the small engineering teams combining DuckDB-native data layers with agent-assisted deployment pipelines, because they are collapsing three of these failure modes simultaneously and doing it without enterprise budgets.