AI + Kuikly: Multimodal Chat App Across 3 Platforms in 7.5 Hours

Project Overview

Using 28 rounds of dialogue and 740 Chinese characters of natural language, the author generated approximately 3,500 lines of code to deliver a fully functional multimodal AI chat application running on Android, iOS, and HarmonyOS — all in 7.5 hours with zero hand-written code. The app supports streaming Markdown replies, photo capture, album selection, SSE long connections, local session management, and history recovery.

Traditional native development for three platforms would require ~30 person-days; even with Kuikly hand-written it would take ~7.5 person-days. The AI-assisted approach compressed this to 7.5 hours.

Environment Setup (09:00–09:10)

Prepared the AI development environment by installing the Kuikly plugin and creating a three-platform template project via the KuiklyUI GitHub repository ( https://github.com/Tencent-TDS/KuiklyUI). Installed Kuikly AI Skills and Rules using: npx skills add Tencent-TDS/KuiklyUI-AI/skills These Skills and Rules feed Kuikly's proprietary DSL and framework conventions into the model, enabling it to work like a seasoned Kuikly developer.

Requirement Analysis & Design (09:10–10:20)

Used CodeBuddy's brainstorming skill to decompose requirements, explicitly requesting "one codebase for three platforms" and "prioritize existing components." The AI queried the component registry and identified six reusable components: KuiklyChatUI (chat UI, includes AiMessageText for Markdown rendering) KuiklyAlbum (album picker) KuiklyCamera (camera capture) KuiklySQLite (local session storage) KuiklyWebview (external link opening) KuiklyToast (lightweight prompts)

Notably, the AI initially selected KuiklyMarkdown but discovered AiMessageText already covered AI message Markdown rendering, so it avoided duplicate dependency — demonstrating awareness of when not to write code.

Two capability gaps required custom Kuikly Modules: SSEModule — existing Network module lacked SSE long-connection support. ImageModule — needed unified image compression and base64 encoding before sending to multimodal models.

The AI produced a detailed development plan covering architecture, data structures, and interaction design.

Coding Implementation (10:20–11:10)

The AI executed the plan autonomously, invoking specialized skills at each stage: [skill:kuikly-expand-api] for generating the two custom Modules — from commonMain interface definitions to native bridge implementations on all three platforms, following Kuikly's official Module specification. [skill:kuikly-ui-framework] and [skill:kuikly-reactive-observer] for chat and session-list pages, using observable to bind streaming replies and message lists to UI.

The process felt like the AI loaded the relevant Kuikly skill before each task, ensuring correct component usage, API extension patterns, and reactive state binding.

Integration Testing & Debugging (11:10–12:30)

First compilation succeeded on Android. Text messaging, streaming replies, and Markdown rendering worked immediately. However, album thumbnails failed to load — grid cells appeared blank.

The author handed the symptom and file ( @ImagePickerPage.kt) to CodeBuddy, instructing it to add logs and analyze via adb logcat. The AI traced the root cause: KuiklyAlbum returns thumbnail URIs in content:// (content provider) format, but the template's ImageAdapter only handled base64, http, assets, and file schemes. The AI patched ImageAdapter to recognize content:// URIs, after which thumbnails displayed correctly and the multimodal understanding pipeline worked end-to-end.

This debug session showcased the AI acting as a senior Kuikly engineer: it navigated the long chain from component → cross-platform UI → native image view, leveraging the Kuikly AI knowledge base to avoid framework source-code spelunking.

Iterative Polish (14:00–17:30)

Four refinement cycles, each driven by a single prompt and verified on-device:

Keyboard obscuring input: AI listened to keyboardHeight and adjusted container paddingBottom. It also added a proxy Input inside the page to capture Kuikly keyboard events (since ChatSession 's internal input doesn't expose them) — an idiomatic workaround the author didn't suggest.

HarmonyOS new-session not persisting: AI traced the routing layer to RouterAdapter on HarmonyOS, which didn't handle the "openPage then closePage" edge case. Fixed in one round thanks to Kuikly AI's framework knowledge.

ActionSheet → grid quick-actions: Replaced system ActionSheet with a WeChat-style bottom grid. Initial attempts caused input-field jump because the panel and keyboard elevation logic conflicted. After several clarifications, AI unified both under a single bottom-lift mechanism sharing one elevation value, stabilizing the input position.

UI consistency across pages: AI extracted design specs from the two main pages (purple gradient background, 44dp transparent nav bar, ‹ back button, 17sp white centered title, light content area) and applied them to ImagePickerPage and WebViewPage. This "infer-then-apply" approach was far more efficient than manual style enumeration.

Final Verification (17:30–18:00)

The app ran successfully on all three platforms with the complete feature set:

Text / image message sending

Photo capture & album selection

AI streaming replies via SSE

Markdown rendering & link opening

Multimodal image understanding

Local session management & history restoration

This is a shippable application, not a demo — one person, one day.

Retrospective: What Kuikly Solved

Kuikly eliminates repetitive labor : one codebase replaces three platform-specific implementations, reducing 30 person-days to 7.5 person-days. More profoundly, it removes repetitive decision-making : every UI/UX iteration (e.g., the ActionSheet-to-grid change with its keyboard-interaction ripple effects) happens once in the shared layer instead of three times with cross-platform alignment overhead.

Retrospective: What AI Solved

AI eliminated boilerplate labor within the Kuikly paradigm. The 7.5 person-days of a skilled Kuikly developer became 7.5 hours because Kuikly AI's Skills and Rules gave the model "senior Kuikly developer" context:

Idiomatic custom Modules: SSEModule and ImageModule followed official structure exactly — commonMain interfaces + three native bridges — without correction.

DSL & reactive mastery: Page structure, component usage, and observable -based state binding matched Kuikly's paradigms.

Custom components & native interop: Proxy Input for keyboard events; ImageAdapter fix for content:// URIs — both requiring deep knowledge of Kuikly's rendering layer and native seams.

Reuse vs. build judgment: Leveraged AiMessageText instead of reinventing Markdown; extended via Modules only where gaps existed; self-debugged the thumbnail issue via logcat + adb down to the exact adapter layer.

These are precisely the areas where generic LLMs hallucinate private APIs. Kuikly AI bridges that gap by injecting framework-specific knowledge, keeping the model inside correct boundaries.

Conclusion

"AI + Kuikly" is one of the most efficient client-development combos today. Kuikly erases cross-platform duplication; AI erases framework-level boilerplate. What remains for humans is product judgment, experience polishing, and engineering oversight — effectively giving a single developer the throughput of a three-platform squad.

Resources

KuiklyUI GitHub: https://github.com/Tencent-TDS/KuiklyUI Official docs: https://kuikly.tds.qq.com/Introduction/arch.html Tencent Terminal Services (TDS): https://tds.qq.com/ TDS Framework:

https://framework.tds.qq.com/