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

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.