#054 ML Валерий Бабушкин и Арсений Кравченко. Как написать книгу об ML System Design

#054 ML Валерий Бабушкин и Арсений Кравченко. Как написать книгу об ML System Design

#054 ML Valery Babushkin and Arseny Kravchenko. How to write a book about ML System Design

by Machine Learning Podcast · View the channel on PSI

Applied Sciences & Engineering AI — Models & Research UYQArtificial intelligence (AI)UYQMMachine learning
🎙 Machine Learning Podcast 👥 5K 📅 September 18, 2024 ⏱ 77 min 👁 1K 📄 expert opinion 🧭 2026-10-09
Available in: English (current) Français

Keywords

ML System Designsystem architectureML pipelinetechnical bookMLOps

Summary

This episode of the Machine Learning Podcast features two guests, Valery Babushkin and Arseny Kravchenko, co-authors of the book ‘Machine Learning System Design with end-to-end examples’. The host opens with a long career segment in which Babushkin explains why he left Blockchain.com (successive layoff waves in 2022 and early 2023 left his team without meaningful work) and how he moved to BP, a ‘super major’ energy company headquartered in London. He frames job choice around four criteria: people, the nature of the work, compensation, and the company’s mission or vision, praising BP’s 2050 net-zero vision and its scale. The conversation then turns to the book: it was initiated by a publisher’s proposal, and Babushkin argues he would likely not have finished it alone, crediting co-authorship as the accountability mechanism that kept the project moving. The central conceptual thread is that ML is not merely ‘fit-predict’: building an ML system means building an entire software system plus the ML layer on top, including data collection and storage, queues, object storage, training and inference pipelines, validation, reporting, monitoring, ownership and on-call. System Design is presented as the architectural document that covers the whole lifecycle of a system, from the reason for its existence to its operation. A recurring argument is that asking ‘why are we doing this?’ early can reveal that the project should not be built at all, saving weeks or months of invested effort. The book is described as a reference the author himself consults, structured densely by topic, and intended to compensate for the shortage of experienced practitioners by making knowledge transferable and updatable through new editions.

268 words

Critical Evaluation

Value of the Information & Strength of the Argument

The informational value of this episode lies mainly in its framing of ML engineering as a systems discipline rather than a modelling exercise. The strongest argument is the layered-cost thesis: an ML system is a software system plus an ML component, so all the classical software engineering obligations (documentation, reproducibility, ownership, monitoring, on-call) apply, with additional failure modes introduced by data and models. The ‘fit-predict is a terminal case’ formulation is a compact and effective way to describe the gap between notebook experimentation and production. The second substantive argument concerns documentation as an economic instrument: writing a design document before building forces the team to articulate purpose, initial decisions, evaluation criteria, data collection, validation, pipeline separation between training and inference, reporting and monitoring. The claim that the best possible outcome of such a document is discovering that the project is unnecessary is well argued in terms of opportunity cost, comparing one to two weeks of writing against three to six months of misallocated engineering time. The analogy with construction drawings and with a technical specification is used consistently and helps make the case that ML has been under-documented relative to older engineering fields. The weakest part of the argumentation is the career segment, which is anecdotal and largely unverifiable, and the discussion of energy transition, which is asserted rather than demonstrated. The co-authorship argument is also plausible but supported only by personal testimony: the claim that the book would not have been finished by a single author is a reasonable account of motivation and accountability, not a general finding. Overall the reasoning is coherent, internally consistent and aligned with mainstream MLOps practice, but it remains expert opinion rather than evidence-backed analysis.

Scientific Rigor, Source Quality, Title Accuracy

Scientific rigour is moderate. The episode is a conversational interview with practitioners, not a research presentation, and no studies, benchmarks or datasets are cited. The claims made about ML system design are consistent with widely accepted engineering practice, but they are presented as experience-based judgements rather than as findings supported by evidence. Source quality is limited: the primary reference is the authors’ own book, linked in the description, and the remaining links are podcast distribution channels, a Telegram book club, a Telegram channel, a chat, and paid Python/aiogram courses by the host. These are legitimate but promotional or community-oriented rather than independent scientific sources. No external literature, no competing framework and no dissenting view is referenced. The title/content match is good: the episode is explicitly about writing a book on ML System Design with its two co-authors, and the discussion returns to that subject after the opening career digression. The main structural weakness is the proportion of the episode devoted to the guest’s job change and to the energy-transition digression, which delays the announced topic and dilutes the density of the technical discussion.

479 words

Title / Content Match

The title accurately reflects the episode: it is a conversation with the two co-authors of 'Machine Learning System Design with end-to-end examples' about how and why the book was written. The first ~20 minutes drift into career and industry anecdotes before returning to the book, but the core topic matches the title.

Quality & Reliability

7/10

The discussion is grounded in the authors' direct experience writing a technical book on ML System Design and in Valery Babushkin's first-hand account of industrial ML/Data roles (Blockchain.com, X5, BP). Claims are mostly experiential and clearly framed as such; no quantitative results or external studies are cited, and the book itself is the main reference. The absence of verifiable data points and the conversational format limit the score, but the content is coherent, non-sensationalist and consistent with established ML engineering practice.

Key Moments

Markers derived by PSI from the transcript: the creator did not define chapters.

Cited Sources

Concurring Sources

External References

Contribution & Novelties

The episode’s original contribution is a practitioner’s account of why ML System Design deserves book-length treatment, framed around the gap between notebook-level modelling and production systems. The most transferable idea is the layered-cost argument: an ML system is a software system plus an ML layer, so documentation, reproducibility, ownership and monitoring obligations are inherited and amplified rather than optional. The second is the use of the design document as a decision instrument whose best outcome can be cancelling the project, which reframes documentation as a way to avoid misallocated engineering time rather than as bureaucratic overhead. The third is the co-authorship mechanism as a practical answer to the knowledge-transfer problem in a field where experienced practitioners are scarce and where a book can be updated through new editions. The episode also illustrates, through the career segment, how industrial ML roles converge across very different sectors: the pipeline-building and maintenance work described at X5, Blockchain.com and BP is presented as essentially the same job.

Pour aller plus loin :

  • Machine Learning Operations (MLOps) — Overview of the operational practices that the episode describes as the missing layer around modelling.
  • Software design document — Background on the design-document artefact that the guests position at the centre of ML System Design.
  • Designing Machine Learning Systems — Chip Huyen’s book, a widely used reference on the same problem space, useful for comparing scope and structure.
  • Reproducibility — The general scientific and engineering principle underlying the guests’ complaints about systems that cannot be reproduced or debugged.
  • Technical debt — Relevant to the described consequences of skipping design and documentation in ML projects.

267 words

Radar Profile

The profile is balanced toward practical engineering rather than research: information quantity and technical level are moderate, reflecting a conversational interview with limited quantitative content, while quality and overall reliability are higher because the claims come from direct industrial experience and are internally consistent. The relatively low technical depth score reflects the absence of benchmarks, architectures or code-level detail, not a lack of expertise.

Reliability 7/10