Architecting Complexity: How a Structured Multi-Prompt Strategy Enabled an AI Agent to Build a Multi-Platform Messenger

In the rapidly evolving landscape of artificial intelligence, the narrative has shifted from simple code generation to the complex orchestration of entire software ecosystems. A recent development project has demonstrated that while AI coding agents are often relegated to building simple "CRUD" applications, they are increasingly capable of handling sophisticated, multi-surface products when guided by a rigorous architectural framework. The project in question—a comprehensive "Family Messenger"—was developed not through a single, sprawling request, but through a calculated "architecture-first" methodology that mirrors the workflow of a professional engineering team.

The scope of the project was intentionally broad, designed to test the limits of what an AI agent can coherently execute. The requirements included a robust backend, a shared data layer, and four distinct client targets—Android, iOS, Desktop, and Web—all running on a single codebase. Beyond the basic interface, the system required complex features such as data synchronization, delivery and read receipts, push notifications, and a self-hosted deployment strategy targeting a plain Virtual Private Server (VPS).

In a traditional corporate environment, a project of this magnitude would typically necessitate a multi-disciplinary team. It would require a backend developer to handle the server logic and database, a mobile developer for the handheld platforms, a web specialist for the browser interface, and a lead architect to ensure that all components interact seamlessly before a single line of business logic is even written. The goal of this experiment was to determine if an AI agent could fill all these roles by following a structured sequence of prompts that prioritized architectural integrity over immediate code output.

The Shift from Code Generation to Architectural Contracts

The developer behind the project, who has made the entire repository and every prompt used publicly available on GitHub, noted that the primary challenge was not the generation of code itself, but the maintenance of coherence across a wide surface area. A common pitfall in AI-assisted development is the "single prompt" approach. Asking an AI to "build a family messenger in Kotlin" might produce a functional prototype, but it rarely results in a production-ready system where the backend and four different clients agree on the same Data Transfer Objects (DTOs), or where data synchronization can survive a dropped connection.

To solve this, the developer utilized a two-stage planning process. First, the core idea was described to a web-based Large Language Model, such as ChatGPT or Claude. This model acted as a senior architect, translating the high-level requirements into a massive "master prompt" that functioned as a solution architecture document. This document fixed the boundaries of the system before any implementation began.

This master prompt, an extensive document of approximately 33 KB, served as the project’s contract. It laid out specific technical constraints that are often overlooked in casual AI prompting. For instance, it mandated that the backend run on an Ubuntu 24.04 VPS via Docker Compose, specifically eschewing the complexity of Kubernetes. It also dictated that the system use polling as its primary method for message retrieval to ensure reliability across all platforms, making Firebase Cloud Messaging (FCM) push notifications an optional enhancement rather than a hard dependency.

The architectural contract also defined the internal plumbing of the application. It specified the use of Koin for dependency injection on both the backend and the client sides. Crucially, it required a separate, shared Kotlin module to hold all request and response DTOs, enums, and transport contracts. This ensured that the backend and the various clients were using the exact same definitions, preventing the duplication and divergence that often plague multi-platform projects.

Designing the Sequence of Implementation

Once the architectural contract was established, the work was divided into five sequential steps. Each step was designed with explicit boundaries, often naming what the agent should not do as much as what it should. This prevented the AI from getting ahead of itself and introducing logic that might conflict with the overall structure.

The first phase focused entirely on the "monorepo skeleton." The agent was instructed to build the shared-contract module and wire it to a skeleton backend and client. The explicit constraint here was to avoid implementing any business logic. By forcing the AI to build the right skeleton first, the developer ensured that the foundation was solid before the more complex features were added.

The second phase moved into the full backend implementation. This included routing, authentication, and persistence using the Exposed framework. The agent was required to use the shared-contract DTOs exclusively, ensuring that no duplicate models were created within the backend. The prompt was clear that "TODO" stubs were unacceptable; the logic had to be fully realized from the start.

Infrastructure was the focus of the third phase. The developer opted for a pragmatic stack, requiring Dockerfiles, a docker-compose configuration, and optional Caddy integration for SSL management. The goal was to create a deployment process that was understandable to someone new to VPS management, rather than relying on a complex DevOps stack that might be overkill for a family-focused application.

The fourth phase was perhaps the most ambitious, involving the creation of the client for Android, iOS, Desktop, and Web. This relied heavily on Kotlin Multiplatform (KMP), where the "shared code" had to be substantial rather than decorative. This phase implemented the sync engine and local storage, ensuring that the UI could adapt across different form factors. For example, the application was designed to use a mobile stack layout on phones while automatically transitioning to a split-pane layout on desktop and web interfaces.

The Critical Role of Self-Review

The final phase of the project deviated from the standard feature-addition cycle. Instead, it tasked the AI agent with acting as a principal engineer to review its own output. The agent was asked to evaluate the repository across eight specific areas, including sync consistency, platform realism, and security.

This self-review step was designed to bridge the gap between "the code exists" and "the code fulfills the contract." The agent looked for discrepancies between the real API endpoints and the documentation, checked for the presence of necessary database indexes for chat history, and verified that the backend could actually start via the provided Docker Compose files. It also evaluated the security of the invite-only registration flow and the isolation of data between different "families" using the app.

The result of this structured approach was a repository containing roughly 13,000 lines of Kotlin and Gradle code spread across 113 files. The entire process, from the initial architectural discussion to a working multi-platform version, took approximately three days. For comparison, the developer—drawing on years of experience in mobile app agencies—estimated that a human team of several specialists would typically take at least a month to reach a similar Minimum Viable Product (MVP) stage.

Real-World Testing and the Limits of AI

While the AI-generated code provided a coherent and large-scale first version, the project also highlighted the current limitations of AI in software development. After the five steps were completed, the developer used the app for a week on real devices, including those belonging to family members. This real-world usage revealed issues that were not immediately apparent during the generation phase.

The most prominent issue involved message status synchronization. While the logic for moving a message from "Local Pending" to "Sent," "Delivered," and finally "Read" seemed straightforward on paper, the unread counters began to drift once multiple devices were involved in the same conversation. The git history of the project shows a series of follow-up fixes that were necessary to address authorization bugs, deployment hiccups, and issues with the "stale sync cursor" during network errors.

These findings suggest that while an AI agent can build a massive, structurally sound foundation, it cannot yet replace the iterative testing and refinement that comes from real-world usage. The "last mile" of software development—handling edge cases, network instability, and complex state synchronization—still requires human oversight and manual intervention.

Lessons for the Future of AI-Driven Development

The success of the "Family Messenger" project provides a roadmap for developers looking to use AI agents for more than just simple tasks. The primary takeaway is the importance of the "Master Prompt" as an architectural anchor. By defining the data schema, API endpoints, and platform constraints upfront, the developer prevents the AI from making conflicting decisions as the project grows in scope.

Furthermore, the project emphasizes that "shared code" should be the default for multi-platform projects. Using Kotlin Multiplatform allowed the AI to maintain a single source of truth for the business logic and data models, which significantly reduced the potential for bugs across the four different client targets.

Ultimately, this experiment proves that AI is capable of handling high-breadth projects, provided the human operator acts as the architect and supervisor. The methodology of splitting work into sequential, bounded steps ensures that each layer of the application is built on a stable foundation. While it may not yet replace a full engineering team for a polished, production-grade product, it dramatically collapses the time required to move from a complex idea to a working, multi-platform reality.