Stop LLM planning from becoming a chaotic mess of technical jargon
Many treat AI coding assistants as magic wands, accepting walls of technical text and spending twenty minutes verifying if the logic is sound. AI-generated plans frequently consist of hallucinated buzzwords that mask architectural flaws until a deployment fails halfway through.
A structured approach to prompt engineering shifts focus from prose to call graph planning. Developers like Dillon Mulroy and Rin (r17x) utilize call stacks to construct technical specs. Replacing paragraphs with a hierarchy of function calls makes it simple to review AI logic and identify potential failures before writing code.
The Effect TypeScript Mental Model
Professional implementation involves adopting a design thinking model based on the Effect TypeScript library. Effect serves as a standard library that ensures asynchronous code, error handling, and dependency injection remain 100% type-safe and predictable.
Forcing an LLM to plan via an Effect-style mental model requires it to categorize every step into three distinct channels:
- A (The Happy Path): The AI maps core domain logic, focusing on function returns and data movement without initial distraction from edge cases.
- E (Failure Modes): The AI categorizes issues into Retry (transient), Escape (recoverable/expected), and Die (bugs or panics), a model applicable across nearly all programming languages.
- R (Requirements/Dependencies): This identifies exactly what a function requires to run, preventing the AI from creating hidden dependencies that complicate testing.
Implementing Call Graph Planning
The workflow follows this structure:
X → Graph → Effect
│ │ │ │ │
│ │ │ │ └─ what each node needs
│ │ │ └──── where the graph breaks
│ │ └─────── what flows through nodes
│ │
│ └─ nodes = functions, edges = data flow
│
└─ the problem: what you’re trying to buildInstead of requesting a "Plan for a user authentication system," instruct the LLM to generate a call graph using the A, E, and R framework to force linear thinking.
A standard production call graph appears as:
Production:
HTTP Handler → UserService.getUser → UserRepo.findById → PostgresDBA test implementation appears as:
Tests:
HTTP Handler → UserService.getUser → UserRepoMockWhy this actually works for LLM agents
When benchmarking LLM agents for complex coding, top performers maintain high structural integrity. Requiring a call graph provides three major advantages:
- Data Flow Mapping (A): The relationship between functions and the final output structure becomes immediately visible.
- Error Identification (E): Logic breaks, such as retry or fallback decisions, are caught during planning rather than debugging.
- Dependency Injection (R): Every function openly declares requirements, making the resulting code easier to unit test.
This approach accelerates code reviews. If error handling is missing or the graph is convoluted, the AI can be corrected instantly. Fixing a flawed graph is cheaper than refactoring 200 lines of broken TypeScript.
All Replies （4）
Want a live back-and-forth? Join the global AI chat room — login to talk.
This is a struggle. Does asking for a step-by-step breakdown actually stop the rambling responses? By replacing paragraphs with a hierarchy of function calls, it becomes simple to review AI logic and identify potential failures before writing any code. Many treat AI coding assistants as magic wands, accepting walls of technical text and spending twenty minutes verifying if the logic is sound. This pattern repeats often. AI-generated "plans" frequently consist of hallucinated buzzwords that mask architectural flaws until a deployment fails halfway through.
Pseudocode is a lifesaver for cleaning up logic. Does anyone have a specific prompt template for this? One concrete step that helps is replacing paragraphs with a hierarchy of function calls so it becomes simple to review AI logic and identify potential failures before writing any code.
Love this perspective. Can you DM me at t_g_@kanelim1997 so we can dive deeper into these points?
Many treat AI coding assistants as magic wands, accepting walls of technical text and spending twenty minutes verifying if the logic is sound. This pattern repeats often. AI-generated "plans" frequently consist of hallucinated buzzwords that mask architectural flaws until a deployment fails halfway through.
A more structured approach to prompt engineering shifts the focus from prose to call graph planning. Developers like Dillon Mulroy and Rin (r17x) utilize call stacks to construct technical specs. By replacing paragraphs with a hierarchy of function calls, it becomes simple to review AI logic and identify potential failures before writing any code. ## The Effect TypeScript Mental Model Professional implementation involves adopting a design thinking model based on the Effect TypeScript library. Effect serves as a standard library that ensures asynchronous code, error handling, and dependency injection remain 100% type-safe and predictable. 
Forcing an LLM to plan via an "Effect-style" mental model requires it to categorize every step into three distinct channels: - A (The Happy Path): The AI maps the core domain logic, focusing on function returns and data movement without initial distraction from edge cases. - E (Failure Modes): Rather than vaguely "handling errors," the AI categorizes issues into Retry (transient), Escape (recoverable/expected), and Die (bugs or pan).
Annoying. Is all this jargon just a way to hide that the reasoning isn't actually there? Try forcing the LLM to categorize every step into Happy Path, Failure Modes, and Dependencies before it writes any code.