<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Neeraj Yadav</title>
    <description>The latest articles on DEV Community by Neeraj Yadav (@yadu989).</description>
    <link>https://dev.to/yadu989</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4004750%2F4f0d0c2a-951c-4271-a08c-c68c3376362c.jpg</url>
      <title>DEV Community: Neeraj Yadav</title>
      <link>https://dev.to/yadu989</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/yadu989"/>
    <language>en</language>
    <item>
      <title>Post 4 - Building AI You Can Trust</title>
      <dc:creator>Neeraj Yadav</dc:creator>
      <pubDate>Thu, 16 Jul 2026 03:34:56 +0000</pubDate>
      <link>https://dev.to/yadu989/post-4-building-ai-you-can-trust-11al</link>
      <guid>https://dev.to/yadu989/post-4-building-ai-you-can-trust-11al</guid>
      <description>&lt;p&gt;"Move fast and break things" is terrible advice for anything that touches money, health, or safety.&lt;/p&gt;

&lt;p&gt;In six years building product in auto-finance, the discipline that mattered most wasn't speed. It was: prove it's safe before you ship it, and build the proof into the system so it can't be skipped.&lt;/p&gt;

&lt;p&gt;When I build AI products now, I use the same rule. Every new capability ships turned off by default. It only gets turned on after it passes a gate that proves it didn't break the thing that already worked. Not "I think it's fine", a measured, automated check that fails loudly if I'm wrong.&lt;/p&gt;

&lt;p&gt;It feels slower. It's actually faster, because you never spend three weeks debugging a regression you shipped a month ago and forgot about.&lt;/p&gt;

&lt;p&gt;Guardrails aren't the opposite of velocity. They're what lets you go fast without being reckless.&lt;/p&gt;

&lt;h1&gt;
  
  
  Leadership #ProductManagement #AI
&lt;/h1&gt;

</description>
      <category>ai</category>
      <category>automation</category>
      <category>softwareengineering</category>
      <category>testing</category>
    </item>
    <item>
      <title>Post 3 - Building AI You Can Trust</title>
      <dc:creator>Neeraj Yadav</dc:creator>
      <pubDate>Fri, 10 Jul 2026 14:57:08 +0000</pubDate>
      <link>https://dev.to/yadu989/post-3-building-ai-you-can-trust-4352</link>
      <guid>https://dev.to/yadu989/post-3-building-ai-you-can-trust-4352</guid>
      <description>&lt;p&gt;Here's a problem that sounds simple and isn't:&lt;br&gt;
Your AI coding assistant learned last month that your service runs on port 8000. Yesterday you changed it to 8080. Today you ask it about the port.&lt;/p&gt;

&lt;p&gt;A normal retrieval system stores both facts. They look almost identical to it - one word different. When you ask, it retrieves both and has no idea which one is current. So it either guesses or confidently gives you the old answer.&lt;/p&gt;

&lt;p&gt;This is the thing I've been working on: memory for AI that knows which facts are still true, not just which ones are similar. It turns out "similar" and "current" are completely different problems, and almost everyone conflates them.&lt;/p&gt;

&lt;p&gt;I'll go deeper on the how in future posts. For now: this single blind spot is behind a huge amount of "why did the AI confidently tell me something outdated."&lt;/p&gt;

&lt;p&gt;Has an AI assistant ever given you a confidently wrong answer that used to be right?&lt;/p&gt;

&lt;h1&gt;
  
  
  AI #MachineLearning #BuildInPublic
&lt;/h1&gt;

</description>
      <category>ai</category>
      <category>programming</category>
      <category>python</category>
      <category>machinelearning</category>
    </item>
    <item>
      <title>Not many know which part of the process needs AI!</title>
      <dc:creator>Neeraj Yadav</dc:creator>
      <pubDate>Fri, 03 Jul 2026 21:48:12 +0000</pubDate>
      <link>https://dev.to/yadu989/ai-context-and-memory-management-chapter-2-3ihn</link>
      <guid>https://dev.to/yadu989/ai-context-and-memory-management-chapter-2-3ihn</guid>
      <description>&lt;p&gt;A process that took 2–3 weeks and produced a 40-page document is the kind of thing everyone wants to "AI-ify."&lt;br&gt;
Here's what most people get wrong about it: they reach for the LLM first.&lt;/p&gt;

&lt;p&gt;In regulated lending, the LLM is the &lt;em&gt;last&lt;/em&gt; and &lt;em&gt;smallest&lt;/em&gt; part of the pipeline. The hard parts are: ingesting messy documents reliably, extracting data into a canonical model, validating and cross-reconciling it, and doing the actual financial calculations - and those calculations must be done in deterministic code, never by a language model that might quietly round a number wrong.&lt;/p&gt;

&lt;p&gt;The LLM drafts prose. Code does the math. A human owns the risk decision. That ordering isn't a limitation - under OSFI E-21 it's the only design that's allowed to exist.&lt;/p&gt;

&lt;p&gt;The teams that win with AI in banking aren't the ones using the biggest model. They're the ones who know which 10% of the problem the model should touch.&lt;/p&gt;

&lt;p&gt;Where have you seen an LLM used for something that should have been deterministic code?&lt;/p&gt;

&lt;h1&gt;
  
  
  FinancialServices #AI #Lending
&lt;/h1&gt;

</description>
    </item>
    <item>
      <title>MemStrata Beats RAG comprehensively on mutating code content - http://arxiv.org/abs/2606.26511</title>
      <dc:creator>Neeraj Yadav</dc:creator>
      <pubDate>Sat, 27 Jun 2026 04:54:18 +0000</pubDate>
      <link>https://dev.to/yadu989/memstrata-beats-rag-comprehensively-on-mutating-code-content-httparxivorgabs260626511-1md4</link>
      <guid>https://dev.to/yadu989/memstrata-beats-rag-comprehensively-on-mutating-code-content-httparxivorgabs260626511-1md4</guid>
      <description>&lt;p&gt;I've spent the last several months building an AI memory system on nights and weekends, and the most valuable thing I learned has nothing to do with AI.&lt;/p&gt;

&lt;p&gt;It's this: the moment you let what you hope is true override what you measured, you stop doing engineering and start doing marketing.&lt;/p&gt;

&lt;p&gt;I caught myself doing it more than once. I had a headline result I loved - and the data quietly didn't support it. I had a clever feature I'd already written up as the fix - and when I finally measured it, it made things 25% worse. Each time, the honest move was to kill the thing I was attached to.&lt;/p&gt;

&lt;p&gt;That's uncomfortable. It's also the only thing that makes a result trustworthy.&lt;/p&gt;

&lt;p&gt;I'm going to spend the next 90 days here writing about building AI you can actually trust - the failures included, because the failures are where the truth is. If you work in AI, in financial services, or you're building something hard on the side, I'd love for you to follow along.&lt;/p&gt;

&lt;p&gt;What's a result you were sure of that the data later overturned?&lt;/p&gt;

&lt;h1&gt;
  
  
  AI #ProductManagement #BuildInPublic
&lt;/h1&gt;

</description>
      <category>ai</category>
      <category>programming</category>
      <category>machinelearning</category>
      <category>software</category>
    </item>
  </channel>
</rss>
