{"slug": "ai-is-great-at-reasoning-stop-using-it-for-workflows", "title": "AI Is Great at Reasoning. Stop Using It for Workflows.", "summary": "A Platform Engineering team at an unnamed company built a self-service system using Amazon Bedrock to generate Terraform code dynamically, but later removed it, concluding that AI reasoning should not be used for deterministic workflows. The team now advocates using LLMs only at system boundaries, such as converting natural language into structured data, while keeping the rest of the pipeline deterministic.", "body_md": "More than a year ago, which is practically ancient history in the AI years, I wrote a blog about using AI to build new self-service capabilities.\n\nIt felt like the future.\n\nWe built a self-service action that could create new self-service actions, helping us move faster, reduce bottlenecks, and scale a small Platform Engineering team supporting hundreds of developers.\n\nOne of the most interesting parts was using Amazon Bedrock to generate Terraform code dynamically at runtime, allowing the system to determine how a new cloud resource should be provisioned using our existing Terraform modules.\n\nIt worked.\n\nIt was impressive.\n\nAnd… we removed it.\n\nLooking back, abandoning that approach turned out to be one of the best engineering decisions we made.\n\nAt the time, it felt like an isolated technical decision.\n\nIt wasn’t.\n\nRecently, we faced a much smaller problem. We wanted to automate the creation of DNS records in Cloudflare through our self-service platform.\n\nThe first proposal was exactly what you’d expect today: “Let’s build a Claude Skill.”\n\nImmediately, I had a strong sense of deja vu.\n\nBut my hesitation wasn’t about whether AI could do it — it was about whether it should.\n\nWe were simply asking the wrong question.\n\nA lot of engineers today feel like everything they learned over the last decade suddenly became less relevant.\n\nWe are DevOps engineers.\n\nWe are Platform Engineers.\n\nWe used to spend time designing systems, defining standards, reviewing architectures, and planning before writing a single line of code.\n\nEvery automation started with the same question:\n\n**“How should we automate this?”**\n\nToday, that question has quietly changed. Now we ask:\n\n**“How can AI do this?”**\n\nAt first glance, that sounds like progress. And sometimes it is.\n\nLarge Language Models have fundamentally changed the way we build software. Tasks that used to take hours now take minutes, and entire prototypes appear from a single prompt.\n\nThe temptation is obvious. If AI can do it… why not let AI do it?\n\nSomewhere along the way, though, many of us unconsciously changed more than just our tools. We changed our engineering process.\n\nInstead of designing the architecture first, we choose the technology first.\n\nThe discussion becomes:\n\nDoes this problem actually need “reasoning”?\n\nPeople often talk about AI Agents, Skills, MCP servers, and LLM workflows as if they’re simply the next generation of automation.\n\nThey’re not.\n\nThey solve a different type of problem.\n\nLLMs are great at reasoning through messy, ambiguous problems. They can adapt and change plans. But reasoning adds probability — it’s no longer 100% certain.\n\nThat capability is incredibly powerful, but it comes with fundamental tradeoffs. Reasoning, by definition, introduces probability into a process.\n\nTraditional automation is deterministic. Every step is predictable, testable, and produces the same result every single time.\n\nNow let me go back to our DNS example:\n\n`Slack Form ──► Lambda ──► DynamoDB ──► Terraform ──► Cloudflare`\n\nNothing in that pipeline required interpretation.\n\nWe knew the state we wanted, the code already existed, and the steps were clear. So why introduce a “maybe” into a “definitely” process?\n\nAn LLM can be incredibly valuable at the system boundaries. Imagine a developer writing in Slack: “Create a CNAME for api.staging pointing to our new load balancer.”\n\nTurning that natural language sentence into a structured JSON payload is exactly the kind of ambiguity LLMs excel at. Natural language is messy, humans omit context, and intent needs interpretation. That is a genuine reasoning problem.\n\nStructured Outputs solve formatting. They don’t solve decision-making.\n\nThe risk is letting a probabilistic model decide which tools to run in production.\n\nOnce user intent becomes structured data (or if you collected it via a structured Slack form in the first place), the remaining pipeline no longer benefits from reasoning. Every step after that should behave like standard production software: predictable, testable, and deterministic.\n\nCrucially, the structured data generated by the LLM passes through strict schema validation and deterministic authorization policies (RBAC) in the core. Even if an LLM is manipulated at the edge, it can only request actions — the core independently validates whether the user is authorized to perform them before execution ever touches infrastructure.\n\nThe LLM proposes actions.\n\nThe platform decides whether they’re allowed.\n\nThat realization led us to a clear architectural principle:\n\n**Reason at the edge. Execute deterministically in the core.**\n\nUsing an AI Skill instead of a workflow seems fast at first, but it creates hidden costs for stability and security.\n\nHowever, when you introduce runtime reasoning into an execution path, you accept fundamental tradeoffs that directly impact production stability, security, and cost.\n\nHere is how those tradeoffs manifest in production:\n\n**Human in the Loop Bottlenecks**\n\nIf an LLM cannot be trusted to execute production changes unattended, someone must manually review every single run (When it’s open a PR for example).\n\nThis brings back the very bottleneck you were trying to fix.\n\n**Probabilistic Infrastructure**\n\nA script follows orders; an LLM makes choices.\n\nProduction isn’t the place to find out the AI made a mistake.\n\n**Paying for Unused Intelligence**\n\nScripts cost almost nothing. LLMs cost tokens.\n\nIf the workflow was already predictable, you’re paying for “intelligence” you don’t actually need.\n\n**Expanding the Attack Surface**\n\nA deterministic workflow only executes code you explicitly wrote.\n\nAn LLM executes actions based on how it interprets a prompt.\n\nThe moment an LLM sits directly in the execution path, prompt injection, context poisoning, and unexpected tool execution become part of your threat model.\n\nFor infrastructure, we need predictability, not improvisation.\n\nA script that does the same thing a million times is better than a system that “guesses” correctly most of the time.\n\nUse AI Where It Actually Adds Value\n\nWe use AI more than ever — just not to run our production systems.\n\nWe use AI to design Terraform modules, generate Lambda functions, build CI/CD pipelines, review Infrastructure as Code, write tests, and understand unfamiliar systems.\n\n**Let AI build automation. Don’t let AI be the automation.**\n\nOnce we’ve reviewed the generated code, the reasoning phase is over.\n\nFrom that point onward, production executes deterministic software — not prompts. The model participates during development, not in the production control plane.\n\nThe AI reasons once. The software runs forever.\n\nThe 30-Second Architecture Review\n\nBefore introducing an AI Agent, Skill, or runtime LLM into your next system, ask yourself:\n\n[ ] Does this problem actually require runtime reasoning?\n\n[ ] Can every execution step already be described in advance?\n\n[ ] Will the same input always produce the same desired output?\n\n[ ] Could AI generate the workflow code instead of executing it?\n\nIf the steps are predictable, you don’t need an LLM. You need reliable software.\n\nLLMs are amazing at reasoning, but not every problem needs it.\n\nUse AI to understand what users want and to help you write code. But once the plan is set, let the software take over.\n\nBut once your production system knows exactly what needs to happen, stop reasoning and start executing.\n\n```\nUser\n│\n\n▼\n\nNatural Language\n│\n\n▼\n\nLLM (Intent Extraction)\n│\n\n▼\n\nValidated JSON\n│\n\n▼\n\nAuthorization (RBAC / Policies)\n│\n\n▼\n\nDeterministic Execution\n\nLambda ──► DynamoDB ──► Terraform ──► Cloudflare\n```\n\nReason where things are uncertain. Execute where things are clear.\n\nBecause great architecture isn’t about eliminating AI.\n\nIt’s about confining uncertainty to the parts of the system that actually benefit from it.", "url": "https://wpnews.pro/news/ai-is-great-at-reasoning-stop-using-it-for-workflows", "canonical_source": "https://dev.to/orelbello/ai-is-great-at-reasoning-stop-using-it-for-workflows-313c", "published_at": "2026-08-03 09:50:13+00:00", "updated_at": "2026-08-03 10:11:48.204400+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-agents", "developer-tools", "mlops"], "entities": ["Amazon Bedrock", "Cloudflare", "Claude", "Terraform", "Slack", "Lambda", "DynamoDB"], "alternates": {"html": "https://wpnews.pro/news/ai-is-great-at-reasoning-stop-using-it-for-workflows", "markdown": "https://wpnews.pro/news/ai-is-great-at-reasoning-stop-using-it-for-workflows.md", "text": "https://wpnews.pro/news/ai-is-great-at-reasoning-stop-using-it-for-workflows.txt", "jsonld": "https://wpnews.pro/news/ai-is-great-at-reasoning-stop-using-it-for-workflows.jsonld"}}