# A Local-to-Backend Workflow for Iterating on AI Features in Kotlin Multiplatform Apps

DevFeed: [A Local-to-Backend Workflow for Iterating on AI Features in Kotlin Multiplatform Apps](<https://devfeed.tech/articles/building-ai-features-isn-t-scary-24741.md>)

Original publisher: [Read original article](<https://medium.com/yazio-engineering/building-ai-features-isnt-scary-92817564e364?source=rss----65bd178b00af---4>)

Author: Paul Woitaschek

Published: 2026-07-17T11:49:09Z

Content type: tutorial

Language: en

Sources: [YAZIO Engineering - Medium](<https://devfeed.tech/sources/yazio-engineering-medium.md>)

Topics: [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [Kotlin Multiplatform](<https://devfeed.tech/topics/kotlin-multiplatform.md>), [LLMs](<https://devfeed.tech/topics/llms.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-multiplatform](<https://devfeed.tech/tags/kotlin-multiplatform.md>), [llm](<https://devfeed.tech/tags/llm.md>), [llms](<https://devfeed.tech/tags/llms.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [mobile-app-development](<https://devfeed.tech/tags/mobile-app-development.md>)

## AI overview

The article presents a workflow for building AI features in a Kotlin Multiplatform mobile app: define an app interface, implement and iterate on the prompt locally with Koog, then move the completed logic to a backend. It uses a voice-based nutrition-tracking example that converts natural-language input into typed proposed actions.

## Source excerpt

TLDR: Define the interface in the app, iterate locally with Koog, move the logic to the backend when it's done. AI features have a weird reputation among mobile developers. The model sits behind an API, the prompt lives on a server someone else owns, and every change means a ticket, a review, a deploy. So the whole topic feels like backend territory. But an AI feature is just a feature. Text in, structured data out, some logic in between. The only unusual part: the core of that logic is a prompt. And prompts are not designed, they are iterated. You try an input, look at the output, adjust, try again. Dozens of times. So the real problem is not building the feature. It's making that loop fast. The pattern I would like to show: define an interface in the app, build the real UI against it, implement it locally with Koog, iterate until the output is solid, then move the implementation to the backend. In Kotlin that last step is mostly copy paste. The example: track everything in one sentence We build Yazio, a nutrition tracking app, as Kotlin Multiplatform: one shared codebase for iOS and Android. That matters here, because everything below is written once and runs on both platforms. Tracking today is many small interactions: search a food, pick a portion, add water, log a workout. Now imagine the user just says what happened: "I had two scrambled eggs and a coffee for breakfast, drank half a liter of water, went for a 30 minute run, and for lunch I ate the same as yesterday."Users can track using voice The app answers with a list of proposed actions. The user deletes the wrong ones, speaks again to add what's missing, and confirms everything at once. Speech to text is solved on both platforms, so from our side the input is just a string. Messy natural language in, exact typed data out. That's what LLMs are good at. It's also the kind of logic you won't get right on the first try. The constraint: the key can't live in the app You can't ship an OpenAI or Anthropic API ke