Call Graph Planning: Adapting Effect’s Mental Model for AI

A developer has adapted Effect TypeScript's mental model into a call graph planning technique for AI-assisted coding, making AI-generated plans easier to review and understand. The approach, inspired by Dillon Mulroy and Rin (r17x), structures AI planning around Effect's A, E, R channels to enforce linear, structured thinking before code is written. The method is language-agnostic and can be applied in Swift, Go, and other languages, with example prompts provided for integration into AI workflows.

Saat menggunakan AI untuk melakukan koding, biasanya kita melakukan planning terlebih dahulu. Namun, pada planning yang sudah dibuat oleh AI, output planning yang dihasilkan terkadang sulit untuk kita mengerti dan juga terkesan terlalu banyak jargon teknis yang sulit dipahami. Beberapa minggu yang lalu, aku melihat Dillon Mulroy membagikan bagaimana dia menggunakan callstack untuk membuat techical spec https://x.com/dillon mulroy/status/2069852516309762411 Dan aku juga melihat Rin r17x menggunakan cara yang sama https://x.com/ r17x/status/2073106580632117433 untuk planning. Melihat penggunaan callstack yang mereka gunakan untuk planning membuatku merasa mudah untuk mereview apa yang sedang di plan oleh AI dan juga kita bisa melihat mock functionality dari callstack tersebut dan error apa yang diproduce. Tdak lama setelah itu, Rin membuat https://x.com/ r17x/status/2084954879530012801 sebuah design thinking yang mengadopsi mental model effect typescript. Effect adalah standard library untuk typeScript yang menyediakan runtime khusus agar kode asynchronous, error handling, dan dependency injection menjadi 100% type-safe dan terprediksi. Jika kamu membuka design thinking https://gist.github.com/r17x/90eb2f7be93932b5693753aedb09c01a kamu akan melihat workflow seperti ini: X → Graph → Effect<A, E, R │ │ │ │ │ │ │ │ │ └─ what each node needs │ │ │ └──── where the graph breaks │ │ └─────── what flows through nodes │ │ │ └─ nodes = functions, edges = data flow │ └─ the problem: what you’re trying to build Di effect typescript, sebuah function yang memiliki potensi return error selalu diberikan return Effect<A,E,R atau Effect<A,E jika tidak memiliki dependency . Nah ketiga channel tersebut memiliki sebuah definisi: Terkadang saat AI melakukan planning, AI sering kali memberikan output teks yang panjang lebar dan disertai jargon sehingga sulit untuk kita pahami. Dengan memberi aturan untuk AI agar menyusun call graph berbasis A, E, R sebelum menulis kode, kita memaksa AI berpikir secara linier dan terstruktur. Alur berpikir call graph pada dasarnya adalah sebuah hirarki kode yang akan ditulis. Production: HTTP Handler → UserService.getUser → UserRepo.findById → PostgresDB Tests: HTTP Handler → UserService.getUser → UserRepoMock Saat AI menyusun call graph , ada beberapa hal menarik yang terjadi: Dengan call graph , proses code review terhadap planning AI menjadi lebih cepat. Jika call graph -nya salah atau terlalu rumit, kita bisa langsung memberi feedback di tahap planning sebelum baris kode pertama ditulis. Mental model A, E, R bersifat agnostik dan dapat diterapkan di luar ekosistem TypeScript. Konsep ini dapat diadaptasi saat menulis kode di bahasa seperti Go, Swift, Kotlin, Dart, dll. Meskipun bahasa pemrograman tersebut tidak memiliki runtime bawaan seperti Effect, prinsip dasarnya tetap dapat diimplementasikan: Either<E, A jika pakai library Result<T, E atau async throws ber-tipe, sedangkan Either<E, A jika pakai library Untuk mengadopsi design thinking ini ke dalam workflow AI seperti Cursor, Claude, atau LLM lainnya , kamu bisa menggunakan contoh prompt ini In this session we are going to build a " YOUR IDEA " and this app has features: Breakdown The MVP The tech stack is: - Flutter Use best practice coding in Flutter and adopt this design thinking: " ATTACH GIST DESIGN THINKING URL/CONTENT " Actually this design thinking is based on the Effect TypeScript mental model, but we can adapt its core concepts A, E, R channels, call graph planning, typed errors, clean dependency separation into Flutter functional programming. Please port the design thinking into effect-flutter skills before planning the architecture. Prompt diatas hanyalah sebuah contoh saja dan aku sudah coba menerapkan ini pada projek swift. Ini adalah output yang dihasilkan claude saat melakukan planning Dengan mengadopsi cara ini, AI akan memetakan bagian happy path, error yang bisa direcovery atau tidak, kebutuhan dependency dari sebuah function/class, dan kita bisa memverifikasinya dengan mudah karena rancangan sistemnya lebih jelas.