Data Expo – 10th of September CONFIDENTIAL AND PROPRIETARY Any use of this material without specific permission of McKinsey & Company is strictly prohibited
Iʼm from the Netherlands Studied CS at UCL Iʼve been working as a Software Engineer for 10 years Currently Principal Software Engineer at QuantumBlack ✨ Iʼve been the tech lead for Kedro for over 4 years 🚀 • Open source Python framework • Part of Linux Foundation AI & Data • Brings structure, standardisation and trust to data and AI pipelines for scalable and reliable impact Contact [email protected] 3
prompts, agents, and configuration are loosely connected and hard to reason about. This leads to solutions that are less robust, less efficient, and harder to scale. It typically arises from tight deadlines, rapid experimentation, or limited engineering knowledge. Teams usually under-engineer data and AI pipelines, from traditional ML to agentic workflows, creating code with hidden complexity and accumulating technical debt Technical debt is intentional or accidental decisions that make code difficult to understand, maintain, extend and fix. Much like a loan, you pay a higher cost later, because it decreases the team's agility as the project matures. 5
ability to engineer it Many data and AI pipelines are deployed to production before they are ready to scale AI adoption is accelerating, but impact at scale remains constrained As a result, impact remains fragmented and difficult to sustain Fragmented workflows: Solutions are built as isolated pilots, tightly coupled to tools, teams, and specific use cases, with limited standardisation across projects Lack of reproducibility: Logic, data, prompts, and configuration are scattered, making results difficult to recreate Limited visibility & explainability: Workflows act as black boxes, especially in agentic systems where behaviour is non-deterministic and hard to trace Weak engineering foundations: Pipelines evolve from notebooks and prototypes, creating hidden complexity and significant rework for production 6
software thatʼs superior in terms of speed of execution, shipping with higher quality, or building more maintainable code.ˮ GERGELY OROSZ, AUTHOR OF THE PRAGMATIC ENGINEER 9
independent modules. • Each module is responsible for a specific function or feature and operates independently. • Modules should be loosely coupled, meaning that they should not depend on each other too much. • Enhanced readability and understandability of the system • Allows for reusability • Easier collaboration • Makes it easier to test smaller chunks, which can be faster and help find bugs 12
be designed to address different concerns ‒ E.g. separate user interaction layer, data access layer and business logic layer • Separation of concerns helps to improve the readability, understandability, and maintainability of software systems. • It also makes it easier to change and evolve the system over time. 15
learning models/LLMs, such as learning rate, train/test split, and model version. Hyperparameters for deep learning models, such as number of layers and number of neurons. Experiment configuration, such as the number of trials, the random seed, and the logging level. • “Settingsˮ for your AI system • A way to define requirements for data, LLM models and parameters in different environments • Helps keep credentials out of your code base • Keep all parameters and prompts in one place What does configuration help you do? Location of Data Credentials Prompts/evals Paths to files and directories, so the code knows where to find and save the data it needs. Also specify required columns or filters. Connection information for databases and other data sources, such as server address and credentials. System and agent prompts that can be versioned, evals, LLM as judge configuration. • Machine learning/AI code that transitions from prototype to production with little effort • Makes it possible to write generalisable and reusable systems that do not require significant modification to be used EXPERIMENT OR MODEL DATA ACCESS 16
diagnose, and troubleshoot a system purely from its external outputs, without changing code. • Logging: structured, timestamped records of discrete events, used for debugging and audit trails • Metrics: quantitative measurements (latency, error rate, throughput) tracked over time to monitor system health • Tracing: following a single request's path across distributed services to pinpoint bottlenecks and failures 19
knowledge graph, indexes it into a vector database, and exposes an agentic Q&A interface. • Five modular pipelines: 1. Data ingestion 2. Graph construction 3. Graph update 4. Vector indexing 5. Query answering 22
stay fragmented, hard to reproduce, and difficult to scale beyond a pilot • Modularity and separation of concerns keep prompts, agents, data and logic loosely coupled, so systems are easier to understand, test and evolve • Observability through logging, metrics and tracing makes non-deterministic, agentic behaviour explainable and trustworthy • Together, these software engineering practices turn disconnected experiments into structured, reproducible AI pipelines that deliver lasting impact 26
mark3t1ng
tammyeverts
codingconduct
mojombo
rasagy
davidcarrasco
aleyda
inesmontani
sonatard
mza
tmiket
addyosmani
schlessera
