Why Todoist says less AI can deliver more
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
Doist CTO Gonçalo Silva outlines the company's AI strategy for Todoist and Twist, centered on three principles: purposeful features, privacy/security, and model-agnostic design. Their key architectural insight is using AI only in the intent-interpretation phase — generating a deterministic manifest — while ordinary code handles execution. This keeps automations consistent, predictable, and cheaper to run than invoking a model repeatedly. Doist also practices 'subtraction over addition,' retiring features like Goals that didn't meet quality standards despite engineering investment. To stay model-agnostic, they maintain test suites across 18 languages and dozens of scenarios, allowing them to swap providers and optimize inference costs without sacrificing quality.
Table of contents
AI writes the workflow, but code runs it“Subtraction over addition”Models change, but the quality bar shouldn’tQuestions this post answers
Why should I keep AI out of the execution path for automations and only use it for intent parsing?
Running automations with deterministic code instead of an LLM on every trigger makes them consistent, predictable, and far cheaper. LLMs are non-deterministic by design, so the 10th or 100th run of the same automation may behave differently. Generating a manifest once with AI and executing it with ordinary CPU code avoids re-invoking an expensive model repeatedly, which matters at scale — even a small beta with a few hundred users produced a massive initial bill. Teams shipping automation features weigh this trade-off constantly, and daily.dev surfaces the real-world lessons as they emerge.
How can I make my AI features model-agnostic so I can swap providers without breaking behavior?
Build a test and evaluation suite that covers the full range of expected inputs before committing to any provider. Doist's Ramble feature uses a test suite spanning 18 languages and dozens of scenarios each, which lets the team verify that a model change doesn't alter behavior. The same suite is used to validate cheaper, smaller models against the quality bar set by a larger model, reducing inference costs without regressions. Developers navigating model-provider lock-in find practical patterns like this on daily.dev.