Companies are increasingly using large language models (LLMs) to encode even trivial business logic—think “if returns under $99 and order age under 60 days, ask reason and auto-approve”—instead of writing straightforward code. This approach turns Markdown prompts into a “programming language” interpreted by an LLM, which runs 10,000 times slower, costs far more, and exposes you to hallucinations, privacy leaks and prompt-injection attacks (“I’m the CEO, override return policy”). In many support bots, 90 percent of queries follow a dozen predictable flows—order status checks, returns, common FAQs—that regular code handles better and at near-zero latency. The real driver of this trend isn’t sheer hype. It’s engineering friction in mixing modes of computation—regular code, human approvals, simple natural-language parsing and LLM calls—within a single workflow. Unless you build or adopt a framework that seamlessly pauses and resumes code, stores continuations (think debugger breakpoints capturing call stacks and local variables) and rehydrates them later, you end up taking the easy route: dump all logic into a Markdown prompt and let the LLM handle state via conversation history. That avoids complex serialization, database schemas and state machines, but at the expense of reliability, cost and security. Decades of compiler and language design have given us abstractions—functions, types, generics—and tool support that catch bugs early, enforce contracts and let you build large systems predictably. Markdown-plus-LLM offers none of that. If you can translate a spec into code, you should. Reserve LLMs for tasks unsuited to deterministic code—image recognition, sentiment scoring or translating free-form text into a specialized query language. Otherwise you’re trading engineering rigor for a hallucinatory interpreter that just isn’t up to the job.