A coding agent built a four-platform Kotlin messenger from a 33 KB plan cut into five steps

The author's control case is the one-line request. By the author's account, a one-line request to build a family messenger in Kotlin produces something. "It doesn't reliably produce a system where the backend and four clients agree on the same DTOs, where sync survives a dropped connection, and where deployment is handled separately from application code," the author wrote. ^[17] According to the author, code generation was not under test: "I wanted to see whether a complex, multi-surface product can be planned well enough that an agent carries it out coherently." ^[16]

The best decision in the plan is the shared module. Request and response DTOs, enums and transport contracts live in one Kotlin module that the backend and the client both use, with no duplicate copies ^[8]. With that module in place first ^[12], every later step compiled against the same types. A client that reads a field the server never sends then fails in the build, on the developer's machine, instead of on a phone. Koin handles dependency injection on both sides, so the wiring pattern matches too ^[7].

Sync gets the same single-path treatment. New messages arrive by polling messages/sync?since_id=... ^[6][9]. The since_id parameter implies a cursor that the client holds, so a client that drops its connection can ask again from the last id it saw. That covers the "survives a dropped connection" condition in the author's own counterexample ^[17]. Receipts get their own table, message_receipts, one of eight in the PostgreSQL schema ^[10].

Step 4 is where the rule that shared code must be substantial gets tested. The same panels render as a stack on mobile and as a split pane on desktop and web ^[13]. The step 5 review then asks whether commonMain is "substantial or decorative" ^[15]. Every step prompt also lists what it must not do ^[11].

The review step is the part I would copy first, and I have seen few roadmaps with a step that adds no features. Its seventh area reads "platform realism - can each target actually be launched?" ^[15] The post does not report what the review found. Whether all four clients start is something a reader has to check against the public repository ^[2].

Because an LLM drafted the plan ^[3], its cost is easy to overlook. The author's part was the idea, the constraints, moving each step to the agent and checking what came back, with no application code written by hand ^[4]. In a normal team, by the author's account, this work would involve a backend developer, a mobile developer, someone for web, and an architecture discussion before any business logic ^[19]. Of the 33 KB master prompt ^[5], the author wrote: "None of this is exotic. These are the decisions a team would normally make in a design review." ^[18]

For the method to transfer, a team has to settle those decisions before code exists and hold them fixed for five steps. In my view that is realistic for a greenfield product with one owner who knows the constraints. Where the API is still being negotiated, each change reopens the contract that step 1 treated as settled ^[12].