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

> Source: <https://dev.to/derangga/call-graph-planning-adapting-effects-mental-model-for-ai-558h>
> Published: 2026-08-31 08:59:46+00:00

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.