Human Judgment Saves the Day from AI's Wrong Answer

There's a massive hype around AI systems right now. How revolutionary they are, how easy they make software development. Funny thing is, especially in industries where correctness is paramount, AI absolutely solves some problems, but it introduces a whole new set of ones too. 🫠 At least with a normal system, you can write deterministic logic. If this value comes back wrong, catch it, fix it, move on. 🧘 🧘 With an LLM? You're dealing with probabilistic outputs. The model might do exactly what you asked. It might not. It might do something close but not close enough. And in production, close enough isn't good enough!!!!! Guardrails help, yeah.. but sometimes the model just ignores them. The same prompt that worked yesterday fails today on slightly different input. 🤩 👏 The part that really gets you is when you need to do something precise in an agentic system. Extract a specific value, pass it somewhere, get an exact result. Things that would be trivial in traditional code become genuinely hard when your pipeline runs through a model that doesn't guarantee consistency. The hype makes it sound like AI handles the hard parts so you don't have to. In reality, it introduces a whole new category of hard parts that we're only beginning to figure out as an industry. 🤕 Curious if others are hitting the same walls. How are you handling reliability in your AI systems? The picture below shows how I am handling it. #AIEngineering #GenerativeAI #LLM #AgenticAI #SoftwareEngineering

We are not afraid of AI. We are afraid of what we are building on top of it. Over the past year, I’ve been deeply immersed in AI-powered development — from agentic workflows to tools like Claude Code and beyond. And I’ll be honest: AI didn’t replace developers. It amplified them to a dangerous level of dependency. Two risks are quietly emerging — and almost no one is talking about them seriously: ⸻ 1. Centralized Intelligence = Centralized Failure Today’s AI ecosystem is not decentralized. It’s controlled by a handful of providers. If a major model provider decides to: * throttle access * change pricing * restrict regions * or simply go down Entire engineering workflows can freeze. This is not a theoretical risk. We’ve already seen outages across major AI platforms impacting production pipelines. We are building critical systems on non-sovereign intelligence layers. ⸻ 2. The Observability Black Hole In traditional systems, debugging is deterministic. In AI systems? * Non-deterministic outputs * Hidden reasoning chains * Probabilistic failures * Silent hallucinations You don’t “trace” the bug. You interrogate behavior. This introduces a new class of problems: * Low debuggability * Weak reproducibility * Fragile reliability at scale Welcome to what I call: The Observability Gap in AI Systems. ⸻ And yet — I’m still all in. Because this shift is real. AI is not a tool anymore. It’s becoming an execution layer. But if we want to build serious systems, we must evolve: * From API consumers → to AI system architects * From prompt engineering → to agent orchestration & control layers * From blind trust → to governance, guardrails, and failover design ⸻ The future will not belong to those who use AI. It will belong to those who understand: where it breaks, why it fails, and how to control it. ⸻ #AI #AgenticAI #LLM #SoftwareEngineering #TechLeadership #FutureOfWork #AIArchitecture #Innovation #MaherMinD

📅 Day 2 — 30 Days of Agentic AI 3 myths about AI agents I keep seeing on LinkedIn. Let me fix them quickly: ❌ Myth 1: "AI agents are just better chatbots." ✅ Truth: Agents don't just respond — they plan, take actions, use tools, and loop until a task is done. That's a completely different architecture. ❌ Myth 2: "You need to be an ML researcher to build one." ✅ Truth: Most agents today are built by software engineers using frameworks like LangChain or CrewAI. If you can write code, you can build one. ❌ Myth 3: "It's still years away from real use." ✅ Truth: Agents are already running in production — automating research, writing code, managing support queues, and processing documents at scale. The hype is real. But so is the technology. Which of these myths did you believe? Drop it in the comments 👇 #AgenticAI #AITrends #TechInsights

𝗔𝗜 𝗱𝗶𝗱𝗻’𝘁 𝗳𝗮𝗶𝗹. 𝗕𝗹𝗶𝗻𝗱 𝘁𝗿𝘂𝘀𝘁 𝗱𝗶𝗱. I spent hours today fighting a bug that wasn’t mine. It was generated by 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 — and not just syntax or structure… This was pure logic. 100% AI-driven reasoning. And it was wrong. The tricky part? It looked right. I tried prompting, re-prompting, refining context… Even asked the AI to fix its own logic. But it kept confidently reinforcing the same flawed path. At some point, I stopped. Not because AI failed. 𝗕𝘂𝘁 𝗯𝗲𝗰𝗮𝘂𝘀𝗲 𝗜 𝗿𝗲𝗮𝗹𝗶𝘇𝗲𝗱 — 𝗜 𝗵𝗮𝗱 𝘀𝘁𝗼𝗽𝗽𝗲𝗱 𝘁𝗵𝗶𝗻𝗸𝗶𝗻𝗴. - So I went back. - Traced the flow manually. - Questioned every assumption Claude had made. And there it was — A subtle logical misstep that cascaded into hours of confusion. 💡 𝗧𝗵𝗲 𝘁𝗮𝗸𝗲𝗮𝘄𝗮𝘆: AI can accelerate execution. But it can also accelerate mistakes — very convincingly. The real edge today is not who uses AI, but who knows when to stop trusting it. Engineers aren’t being replaced. They’re being tested. Not on how fast they code — but on how well they think beyond AI. 𝗛𝗮𝘃𝗲 𝘆𝗼𝘂 𝗲𝘃𝗲𝗿 𝘁𝗿𝘂𝘀𝘁𝗲𝗱 𝗔𝗜 𝘁𝗼𝗼 𝗺𝘂𝗰𝗵 𝗮𝗻𝗱 𝗽𝗮𝗶𝗱 𝘁𝗵𝗲 𝗽𝗿𝗶𝗰𝗲 𝗳𝗼𝗿 𝗶𝘁? #ArtificialIntelligence #AIDevelopment #SoftwareEngineering #AIvsHuman #DevelopersLife #CodingLife #TechLessons #AIReality #PromptEngineering #EngineeringMindset #Debugging #BuildInPublic #StartupLife #TechFounders #AItools #FutureOfWork #HumanInTheLoop #DevInsights

AI systems rarely fail in obvious ways. They keep running. They keep giving answers. On the surface, everything looks fine. But over time, things start to feel… off. Outputs become a bit inconsistent. Some responses don’t quite make sense. Edge cases start showing up in places you didn’t expect. And the tricky part is - it’s hard to explain why. That’s usually not a model issue. It’s a visibility issue. Understanding how the system behaves across inputs, retrieval, and responses is what actually helps teams improve reliability after deployment. I put together a simple breakdown of this what to look at, where things usually go wrong, and how to think about it in real systems. Sharing the link below if you’re working on production AI and want a clearer perspective. 👇 https://lnkd.in/dtFdYi7w #AIEngineering #MachineLearning #RAG #LLM #MLOps #ArtificialIntelligence #BackendEngineering #SystemDesign #SoftwareArchitecture #Observability #DataEngineering #DistributedSystems #AIOps #DeepTech

Across a few of my active side projects, I deliberately made the AI model layer fully flexible. Users can choose any model - a local on-device model or a cloud-hosted one. That constraint forced me to think much harder about architecture rather than leaning on any one provider. Here's what I explored and what I found: Basic Prompt Engineering - Great starting point. Useful for structured outputs and classification tasks. Breaks fast under ambiguity. Intent Recognition + Routing - Using the LLM purely to classify intent and route to deterministic system logic. Surprisingly powerful. Keeps the AI in its lane. Multi-Step Agentic Workflows - The LLM plans, calls tools, and acts across steps. Impressive. Also, where things go wrong at scale if you're not careful. External Tool Use / MCP - Giving agents reach outside the system (in progress). Huge potential. Huge surface area for failure. After everything I’ve built and tested, the winning pattern is Hybrid Intent. Not AI vs Human. Not automation vs control. Both - intelligently combined at runtime. Because in real systems - where decisions affect money, compliance, and core operations - the most powerful AI is not the one that acts fastest… It’s the one that knows when to stop and ask. The journey from prompt to autonomous agent is not a straight line - and that's the most interesting part. #AI #AgenticAI #LLMOps #HumanInTheLoop #EnterpriseAI #SoftwareEngineering #BuildingInPublic

Day 8/100 — Using AI as a debugging accelerator, not a black box Today I leaned into a more deliberate debugging workflow with AI. Instead of asking for a direct fix, I asked for hypotheses, root-cause analysis, and the reasoning behind each possible issue. That approach matters because AI-generated code can be fast, but fast isn’t the same as correct. When I give the model the full error trace, surrounding context, and what I’ve already ruled out, the quality of the output improves significantly. What I’m optimizing for now is not just resolving the bug, but tightening my understanding of the system: data flow, state transitions, API behavior, and failure modes across the stack. That’s where AI becomes genuinely useful — not as a replacement for engineering judgment, but as a force multiplier for it. AI-supported debugging works best when you lead with context and validate the fix like you would any other production change. #100DaysOfCode #AI #FullStackDevelopment #WebDevelopment #Consistency #PostpartumLearning #TechJourney

When your AI tools break, your roadmap breaks. Anthropic admitted it yesterday. They published a postmortem naming three silent changes that stacked for over a month. A reasoning-effort downgrade on March 4. A caching bug on March 26 that cleared the model's thinking every turn instead of once. A verbosity prompt on April 16 that cost three percent on a coding evaluation. None of it carried a version number. None was announced. Users felt it. Anthropic's own team mostly did not, because they were not running the exact public build. Three lessons for founders building on models that move underneath them. 1). The model you picked is not the model you get. Default settings, system prompts, caching logic, and inference stacks can shift without a version bump. Pin the version. If your product starts failing the same prompts it passed last week, suspect the model before you suspect your team. 2). Evaluate the public endpoint, not the internal build. If the people shipping the model are not feeling the regressions, no one is catching them. Run your golden prompt evals daily against the exact API you call in production. Three. Your product is the stack, not the model. Fallbacks, cache resets, multi-provider routing, and a graceful degradation path. None of it is optional. It is the product. This postmortem changes nothing about that decision of building with AI. It changes everything about how we watch it. AI is infrastructure with weather. Build a roof. #AI · #Founders · #Engineering . #Wiremi

When your AI tools break, your roadmap breaks. Anthropic admitted it yesterday. They published a postmortem naming three silent changes that stacked for over a month. A reasoning-effort downgrade on March 4. A caching bug on March 26 that cleared the model's thinking every turn instead of once. A verbosity prompt on April 16 that cost three percent on a coding evaluation. None of it carried a version number. None was announced. Users felt it. Anthropic's own team mostly did not, because they were not running the exact public build. Three lessons for founders building on models that move underneath them. 1). The model you picked is not the model you get. Default settings, system prompts, caching logic, and inference stacks can shift without a version bump. Pin the version. If your product starts failing the same prompts it passed last week, suspect the model before you suspect your team. 2). Evaluate the public endpoint, not the internal build. If the people shipping the model are not feeling the regressions, no one is catching them. Run your golden prompt evals daily against the exact API you call in production. Three. Your product is the stack, not the model. Fallbacks, cache resets, multi-provider routing, and a graceful degradation path. None of it is optional. It is the product. This postmortem changes nothing about that decision of building with AI. It changes everything about how we watch it. AI is infrastructure with weather. Build a roof. #AI · #Founders · #Engineering . #Wiremi