Dataiku vs code-first is the wrong fight
I have used both in forecasting and production data workflows. They solve different parts of the problem, so the useful question is not which tool wins — it is where standardisation helps and where code should stay the source of truth.
TL;DR: Code gives flexibility; platforms can provide operational structure. The wrong question is "code or platform?" — the right one is "where does standardisation help, and where should code remain the source of truth?" Explore in code, validate the assumptions, formalise stable logic with tests and interfaces, operationalise repeatable work, and keep genuinely custom logic in code. Maintainability comes from ownership, tests, review, and operations, not from the tool alone.
The Problem
The tool debate usually starts as a team argument rather than a design question. "Should we use code or a platform?" sounds decisive, but it hides the real problem: the two options are strong at different stages of the same workflow.
Neither approach is automatically better, and both fail in a predictable way. A notebook-only workflow becomes difficult to maintain once its original author leaves — the logic still works, but nobody can safely change it. A platform-only workflow becomes restrictive when the solution needs custom libraries, non-standard logic, or rapid iteration, because the tool shapes the solution instead of the other way around.
The Approach
I stop asking which tool is better and start asking what each side is genuinely strong at. In practice the split is fairly stable.
Code-first is strongest when the work is still uncertain
Rapid experimentation, custom feature engineering, unusual modelling logic, and detailed debugging are all faster in code. You also keep the things that make change safe: reusable tests, code review, and full control over implementation choices.
A platform is strongest when the workflow must become repeatable and visible
Inspectable workflow dependencies, collaboration between technical and non-technical users, scheduled execution, and operational handoff are where a platform earns its place. Lineage and governance capabilities and standardised delivery patterns come with it.
The useful question is about ownership, not tooling
Not "should we use code or a platform?" but "where does standardisation help, and where should code remain the source of truth?" That reframing turns a preference debate into a design decision with a clear owner.
The operating model I actually use looks like this:
- Step 1: Explore in code.
- Step 2: Validate assumptions, data, and modelling logic.
- Step 3: Formalise stable components with tests and interfaces.
- Step 4: Operationalise repeatable workflows in a platform or orchestration layer.
- Step 5: Keep custom logic in code where it creates real value.
Outcome
The hybrid model removes the argument. Code stays where the value is genuinely custom — experimentation, feature engineering, unusual modelling — and the platform carries the work that has stopped changing: scheduled execution, dependencies that others need to inspect, lineage, and operational handoff.
What this changes in practice is who can maintain the workflow. When stable components are formalised with tests and interfaces, someone other than the original author can pick it up. When repeatable work is operationalised, the run does not depend on remembering to execute a notebook. Maintainability still requires ownership, review, tests, and operations — the tool is only the last part of that list.
Key Takeaway
Design insight: Code gives flexibility; platforms can provide operational structure. The wrong question is "code or platform?" — the right one is "where does standardisation help, and where should code remain the source of truth?" Explore in code, validate the assumptions, formalise stable logic with tests and interfaces, operationalise repeatable work, and keep genuinely custom logic in code. Maintainability comes from ownership, tests, review, and operations, not from the tool alone.