Building a Published App with Zero Code in Four Days: A Complete HarmonyOS Development Journey

A Tech Blogger's Sudden Inspiration

Retro camera apps have flooded app stores over the past couple of years, but Bilibili creator "Gang Gang" spotted a gap: there was almost no truly "working" retro DV (digital video) app on the market. As it happened, he'd dug out an old DV camera from the bottom of a drawer—one that only powered on when it felt like it. Those blurry, barely-visible images ironically stirred up a strong sense of nostalgia.

And so an idea was born—to build a "Time Machine DV" app that could roll your phone's footage back to 1995 with a single tap. The crucial part: he couldn't write a single line of code. The whole process took four days, entirely accompanied by AI, and the app actually made it onto Huawei's App Gallery in the end.

This case is worth discussing precisely because it demonstrates just how low the real barrier to vibe coding (AI-assisted programming) has fallen—even a complete outsider can turn an idea into a shippable product.

What is Vibe Coding? This concept was introduced in 2025 by Andrej Karpathy, former director of AI at Tesla and co-founder of OpenAI. It describes a programming paradigm that relies entirely on AI to generate code, where the developer needs almost no understanding of the underlying implementation logic. Unlike traditional programming, the core of vibe coding is describing intent in natural language and letting AI handle all the implementation details—the developer's role becomes closer to a "product manager" than an "engineer." The rise of this paradigm signals that the entry barrier to software development is undergoing a structural transformation. Notably, when Karpathy introduced the concept, he emphasized that vibe coding is not meant to replace professional engineers, but rather to open a fast lane "from concept to prototype" for those who have ideas but lack programming skills—it lowers the starting threshold, not the engineering complexity itself.

Why Choose HarmonyOS as the First Platform

After researching mainstream development environments across Android, iOS, and HarmonyOS, the author reached a conclusion: the most beginner-friendly platform is Huawei's HarmonyOS.

The reasons are practical—barriers and costs. Most other domestic Android stores no longer accept individual developers; one overseas platform charges over 700 yuan per year, while another requires an upfront payment of over 20 US dollars. In contrast, becoming an individual developer on Huawei is free, the process is almost entirely a green channel, and it even offers an incentive program specifically for individual developers.

It's worth noting that the HarmonyOS referred to here specifically means the "pure-blood HarmonyOS" that Huawei has been fully promoting since 2023—namely HarmonyOS NEXT. Unlike previous hybrid versions that were compatible with Android APKs, pure-blood HarmonyOS made a fundamental choice in its underlying architecture: it adopts a microkernel design, splitting the operating system's core services (such as the file system, driver management, and network protocol stack) into independent processes running in user space, while the kernel itself retains only the most basic functions like process scheduling and memory management. This design is philosophically opposite to Linux's monolithic kernel, offering theoretical advantages in security isolation, but it also means Huawei had to build a complete developer ecosystem from scratch—which is exactly why the ArkTS language and ArkUI framework were born. Because the underlying kernel, runtime environment, and framework layer are all developed in-house by Huawei, dependence on the Android ecosystem has been completely removed. Developers cannot directly port existing Android code and must rebuild applications using Huawei's proprietary technology stack. For beginners, this is actually a relatively "clean" starting point—no historical baggage, highly unified official documentation and developer toolchains, and no need to make difficult compatibility choices within a fragmented Android ecosystem.

"The fact that the platform is willing to leave such an opening for amateurs is quite compelling."

This also reflects a trend: as AI dramatically lowers the barrier to programming, a platform's openness to individual developers is becoming another key variable in whether ordinary people can truly build products.

How Three AI Tools Divided the Work

This project mainly used three tools, and the author clearly delineated each one's role:

• Cursor: The primary coding tool, connecting to more models and adapting to a wide range of scenarios, suited for situations where you need to get hands-on and modify code yourself.
• Codex: Lower learning curve, skilled at UI design, and able to call its own image generation model with very high image quality.
• Huawei DevEco Studio: The official development tool, with a built-in AI chat window that supports switching between large models and even building your own agents.

It's worth mentioning that he didn't choose the currently popular Claude Code—the reason "speaks for itself": account-ban risks and recharge barriers were off-putting. By comparison, Cursor can be used by simply scanning an Alipay QR code, which is far more worry-free. This represents the practical considerations many domestic users face when choosing AI tools.

Looking at the tool positioning, Cursor is essentially a code editor deeply integrated with large language models. Built on the VSCode kernel, it supports chatting with AI directly within the editor and lets the AI generate or modify code after reading the entire project context. Its core advantage lies in "project-level context awareness"—it can index the entire code repository, tracking function call relationships, type dependencies, and module boundaries across multiple files, making it especially good at handling complex logic modifications that require cross-file coordination. Codex, on the other hand, is closer to an AI programming assistant with a chat-first interface. Its underlying model has been specially optimized for front-end UI generation, and its integration with image generation models like DALL·E gives it a natural advantage in the design phase—users can describe requirements, generate reference images, and then directly convert those images into runnable UI code, all within the same chat window, without switching between multiple tools. The core difference between the two lies in the trade-off between "context awareness depth" and "design capability": the former excels at handling complex cross-file code logic, while the latter offers a smoother experience for visual prototype generation and is far friendlier to users with no design background.

Lesson One for Beginners: Let AI Solve the Obstacles Beyond AI

When he actually got started, the author hit a solid wall. Opening Huawei DevEco Studio for the first time, a screen full of English plus all sorts of panels left him bewildered—the AI told him to click "Settings," but he searched for ages and couldn't find the entry point, at one point doubting whether he could pull this off at all.

Then he "got it": why look for it himself? Just throw a screenshot of the interface to the AI, let the AI tell him where it is, and even have the AI analyze the cause. In the end, the AI determined that he had downloaded the wrong version—after switching to the correct version, the whole process went smoothly.

This detail is quite telling. The true value of AI-assisted programming often lies not just in "helping you write code," but in helping people with no experience whatsoever cross the environment-configuration obstacles that discourage beginners. Throwing problems, error messages, and screenshots to the AI, letting it act as a teaching assistant that accompanies you throughout, is the most practical way of working for zero-experience users.

This working method is known in the industry as "multimodal debugging"—feeding both a visual interface screenshot and a text description into a large model that supports image-text understanding (such as GPT-4o, Claude 3.5, etc.), letting the model directly "read the picture and speak" to pinpoint the problem. This relies on the ability of Vision-Language Models (VLMs) to align the visual elements in an image with semantic concepts: the model can not only identify UI components like buttons and menu bars in a screenshot, but also associate that visual information with its training-data knowledge about specific software versions, thereby providing a concrete operational path. For an IDE (Integrated Development Environment) with complex panels like DevEco Studio, this approach is often far more efficient than digging through documentation on a search engine, because the AI can directly map the visual elements in the screenshot to the behavior of a specific software version, offering concrete steps rather than generic advice. This capability is especially crucial for beginners—they often can't even accurately describe "what problem I've encountered" in professional terms, and a screenshot makes this communication barrier nearly disappear.

Architectural Thinking: Build the Engine First, Then Stack the Features

HarmonyOS is a relatively new platform, and there isn't much ready-made experience online. The author's solution was to have the AI directly scrape Huawei's official documentation, organize it into notes, then feed those to Cursor while clearly explaining his own requirements.

The first step Cursor gave was to get an MVP (Minimum Viable Product) running, specifically to validate the core functionality. The MVP (Minimum Viable Product) is a core tool of lean startup methodology—implementing a functional loop at the lowest cost to quickly validate whether the core hypothesis holds, avoiding over-stacking features in an unvalidated direction. For independent developers, MVP thinking is especially critical: it forces you to answer "what is the one most indispensable capability of this product," rather than falling into an endless feature list. This concept was systematically introduced by Eric Ries in The Lean Startup, originally aimed at how startups can rapidly test and iterate under limited resources—and in the context of AI-assisted development, it applies equally to individual developers: AI can quickly help you set up the skeleton, but if you get greedy from the start, code complexity rises exponentially, and the AI's suggestions will also degrade in quality due to context confusion.

The author did one crucial thing right—rather than blindly stacking features, he first built the app's core body: the compositing engine.

What "Time Machine DV" needs to modify is the image after video compositing, which involves the core mechanism of a mobile video compositing engine. A compositing engine is essentially a real-time image processing pipeline based on GPU shaders: every frame output by the camera passes through a program written in GLSL (OpenGL Shading Language) or a similar shader language. GLSL programs execute computations in parallel on millions of pixels on the GPU—this massively parallel computing architecture is the fundamental reason real-time video effects become possible. The CPU's serial computing architecture simply cannot process a 4K frame pixel-by-pixel within 16.7 milliseconds, whereas the GPU's thousands of computing cores handle it with ease. Specifically for retro effects, the shader program performs color matrix transformations on pixels (simulating color shifts), random noise overlays (simulating graininess), edge blurring (simulating low-resolution lenses), and so on, ultimately compositing an output image with a retro texture.

From a technical implementation standpoint, this processing pipeline is typically divided into three stages: first is the input layer, where the raw YUV-format data captured by the camera is converted into a texture the GPU can process; next is the shader processing layer, where the fragment shader executes color operations on each pixel in parallel—this step is at the heart of the retro effects; finally is the output layer, where the processed frame data is encoded into the target format and written to storage. Because this processing must be completed in real time on the GPU (typically requiring one frame to be processed within 16.7 milliseconds to achieve 60fps), and all subsequent filter effects must be "mounted" onto this pipeline, the stability of the compositing engine directly determines the performance ceiling of the entire app. With this foundation in place, subsequent UI work and feature additions become much smoother.

Interestingly, this architectural thinking didn't come from programming experience, but from his instinct as a video creator—he naturally thought to "gather all the material into editing software for processing." Domain experience remains a scarce, transferable advantage in the age of AI programming.

The "Meticulous Teacher" Experience of HarmonyOS

The author was initially uneasy about the fact that pure-blood HarmonyOS uses Huawei's self-developed kernel, entirely different from Android's underlying architecture. But the result was unexpected: not only were there few errors, but the whole process of writing was especially smooth.

He described the language HarmonyOS uses as being like a "meticulous teacher"—the moment you make a mistake, it circles it on the spot, rather than holding it back for a big explosion at the end. Behind this immediate-feedback experience is the static type-checking mechanism of the ArkTS language at work.

ArkTS is a strongly-typed development language Huawei extended from TypeScript. Unlike dynamically-typed languages such as JavaScript or Python, ArkTS requires developers to explicitly annotate data types when declaring variables, and it disables some of TypeScript's "escape hatch" features—for example, restricting the arbitrary use of the any type and mandating interface declarations. Huawei calls these constraints the "ArkTS specification." To understand the value of this design, one must first understand the essential difference between static and dynamic type systems: dynamically-typed languages (like Python, JavaScript) don't require declaring variable types when writing code, and the interpreter only performs type inference at runtime—this brings flexibility in writing, but it also means type errors only surface when the program actually runs to the erroneous line. Sometimes such bugs are only triggered under specific user operations, making them extremely hard to reproduce and diagnose. Statically-typed languages, on the other hand, complete full type inference and validation at compile time, and type errors are highlighted in red by the IDE the instant the code is saved, fundamentally eliminating these "time bombs." Combined with the ArkUI declarative UI framework, the entire system can catch a large number of type errors and logic flaws at compile time (rather than runtime), significantly reducing the cognitive burden of debugging for beginners. More importantly, this feature synergizes well with the AI-assisted programming workflow: if AI-generated code has type issues, the IDE immediately highlights them, and the developer can feed the error messages directly back to the AI to request a fix, forming an efficient "generate-check-fix" loop.

UI Design: From "Unbearable to Look At" to Instantly On Point

The most intuitive part was UI design. The author first had Cursor auto-generate a version, but each iteration was so ugly he couldn't bear to look at it, and the generated images were saved locally, requiring lots of digging through files just to open them.

Later he subscribed to Codex's Plus membership, and the experience immediately changed: among the two images generated in the very first round, one had a retro style that hit exactly the right note. The images were directly visible in the chat window, and he could even have it draw an interactive UI prototype in code on a web page based on that image.

This "image-to-code" workflow is known in front-end design as "Design-to-Code." Traditionally, it relied on plugin bridges between professional design tools like Figma and development tools, and the whole process required collaboration between two roles—designers and front-end engineers—often taking several days. AI's involvement has dramatically compressed this chain: the user only needs to provide a reference image (whether AI-generated or a hand-drawn sketch), and the model can directly output the corresponding HTML/CSS/ArkTS component code. The underlying support for this capability is the vision-language model's semantic understanding of UI components—the model can identify standard UI elements like buttons, cards, and navigation bars, and map them to the corresponding code components. Codex's additional advantage in this step lies in its deep integration with image generation models: it not only understands design intent, but also maintains visual style consistency within the same conversation context, ensuring that generated interface elements remain unified in tone, font, and spacing across multiple iterations, avoiding the problem of "getting messier with every change." For developers without a design background, this means the cost of translating "the picture in your head" into "the interface on the screen" has been reduced to an unprecedented low.

After this round of comparison, he summed up the optimal division of labor: use Cursor for writing and modifying code, and use Codex for design and image generation—each has its focus, and combining them yields the best results.

The Finished Product: Rewinding Youth with a Single Tap

To capture the texture of an old DV in the past, you had to switch to professional mode, manually lower the exposure, adjust the white balance, and then drag it into editing software to add effects bit by bit. Now you just tap "Time Capsule" in the app, and you can roll all the way back from a 2020 pocket camera to a first-generation DV from 1995—even the little icons on the UI are 1:1 recreations of what they looked like back then.

The detail the author is most proud of is the "slightly greenish" tint of the 1995 setting—this isn't a bug, but a deliberately recreated feature: DV white balance was inherently inaccurate in that era, so the image naturally leaned green. Technically, this feature corresponds to the color-matrix flaws of early CCD sensors. Consumer-grade DVs in the 1990s generally used single-chip CCD (Charge-Coupled Device) sensors. Unlike modern phone cameras that use multi-sensor fusion, single-chip CCDs rely on a Bayer filter for spatial interpolation of color—a Bayer filter is a color filter array laid over the photosensitive element, using a 2×2 repeating unit containing 1 red, 2 green, and 1 blue filter (green is more prevalent because the human eye is most sensitive to green brightness), reconstructing complete color by interpolating the color information of adjacent pixels. This interpolation process itself introduces color-precision loss, and on top of that, the auto white balance algorithms of the time were constrained by processor performance, with severely insufficient computing power—modern phone white balance algorithms can perform thousands of color-temperature samplings and matrix operations per second, whereas 1990s DV processors could often only manage a few per second. When shooting under indoor tungsten lighting (color temperature around 2700K), the algorithm couldn't accurately compensate for the warm tone, and after color-matrix operations, it produced a greenish color drift instead. This "imperfection," jointly created by hardware limitations and immature algorithms, has become an emotional anchor of a generation's visual memory decades later. To verify the effect, he even bought a genuinely old DV specifically for image comparison—that slightly reddish, edge-shaking grainy texture made him exclaim, "My youth is back!"

AI Programming Enters Ordinary Homes, But the Ceiling Still Exists

After four days of tinkering, the author's biggest takeaway is: AI programming has truly landed in ordinary homes with a "zero-barrier" posture—an outsider who has never written a line of code can build a published app.

But he also maintained a rare clarity—this app is quite simple, and there are still some bugs that even AI can't solve. The final workaround was to have the AI search developer forums for others' solutions. In other words, the burden of the key difficulties ultimately still falls on truly professional developers.

"What I made can at most be considered a toy. To truly build system-level engineering, you still need developers who have accumulated experience in the industry."

This remark precisely captures the real boundary of current AI programming: it dramatically lowers the barrier to "going from 0 to 1 to build something usable," allowing ideas to be quickly validated; but between a "toy" and "system-level engineering," there remains a chasm of professional experience.

This chasm is largely tied directly to the architectural limitations of current large language models. Although the context windows of mainstream LLMs have expanded to 128K or even 200K tokens, the codebase of a medium-scale production system often exceeds millions of tokens, far beyond what the model can "see" at once. This means that when handling complex cross-module dependencies, AI lacks the "global perspective" that human engineers possess, and can easily give suggestions that are locally correct but systemically wrong. System-level engineering requires developers to have deep capabilities in concurrency safety, memory management, exception handling, scalable architecture, and more—for example, how to design a database indexing strategy to support high-concurrency reads and writes, how to handle network partitions and data consistency in distributed systems, how to avoid OOM (Out Of Memory) crashes caused by object reference leaks on memory-constrained mobile devices, and how to design a deployment architecture that supports gradual rollouts and rapid rollbacks. The answers to these questions are often deeply embedded in specific business contexts, requiring engineers to make trade-off judgments on the premise of "understanding the system as a whole"—and this is precisely where current large language models are most prone to "hallucination" when handling complex engineering problems: they may offer solutions that seem reasonable but simply cannot run under specific system constraints, and inexperienced developers often struggle to recognize such errors. These capabilities are engineering intuition distilled from countless production incidents and code reviews, and they remain a professional barrier that AI cannot yet fully replicate.

For ordinary people, the best attitude may be exactly the one this creator held—boldly give it a try, enjoy the fun, and at the same time maintain reverence for complex engineering.

Key Takeaways