<?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: Farzam</title>
    <description>The latest articles on DEV Community by Farzam (@farzam_44ff1456106b3913c0).</description>
    <link>https://dev.to/farzam_44ff1456106b3913c0</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%2F4062392%2F4ca5eaff-4201-41a0-9d4d-3f98d4cd2ade.png</url>
      <title>DEV Community: Farzam</title>
      <link>https://dev.to/farzam_44ff1456106b3913c0</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/farzam_44ff1456106b3913c0"/>
    <language>en</language>
    <item>
      <title>What it actually takes to keep an LLM pipeline running for a year, unattended</title>
      <dc:creator>Farzam</dc:creator>
      <pubDate>Thu, 06 Aug 2026 10:11:34 +0000</pubDate>
      <link>https://dev.to/farzam_44ff1456106b3913c0/what-it-actually-takes-to-keep-an-llm-pipeline-running-for-a-year-unattended-3ll2</link>
      <guid>https://dev.to/farzam_44ff1456106b3913c0/what-it-actually-takes-to-keep-an-llm-pipeline-running-for-a-year-unattended-3ll2</guid>
      <description>&lt;p&gt;Most AI document-processing demos fall over on the third weird PDF. Here's a contract-intelligence pipeline I built that's been running in production for over a year the architecture decisions that made that possible.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;The problem&lt;/strong&gt;&lt;br&gt;
A legal team was reading thousands of sponsorship contracts by hand. The obvious fix; throw an LLM at each document breaks in production for a specific reason: a wrong extraction early in the chain propagates into every downstream report, and a job that dies late in a long chain can't afford to re-burn every prior stage of tokens.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;The architecture&lt;/strong&gt;&lt;br&gt;
I modeled each document as a work unit with an explicit status enum, moving through named stages; extraction, citation, deal typing, vendor identification, overlap detection, amendment detection, redaction checks — as separate, idempotent background jobs. A stage only enqueues the next on success. If a job dies mid-chain, it resumes exactly where it broke instead of restarting from zero.&lt;/p&gt;

&lt;p&gt;Every model call routes through a provider gateway with bounded retries, a hard timeout, and typed handling for read/connect timeouts so one provider's bad afternoon doesn't take the whole pipeline down.&lt;/p&gt;

&lt;p&gt;Before anything reaches reporting, the pipeline writes a QA record of the model's disagreements and open issues, then halts at a human review gate. Only the flagged item blocks; the rest of the queue keeps draining.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Stack:&lt;/strong&gt; Ruby on Rails 7.2, Hotwire, Sidekiq, Portkey, OpenAI, Google Drive API, MySQL&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Result:&lt;/strong&gt; live and unattended for over a year, processing documents in batches with a 98%+ classification confidence rate before anything hits human review.&lt;/p&gt;

&lt;p&gt;The pattern that generalizes: write the failure path before the happy path. If you can't answer "what happens when this specific stage fails at 2am," you don't have a production system yet, you have a demo.&lt;/p&gt;

&lt;p&gt;More on how I build these → &lt;a href="https://farzamazhar.com/#work" rel="noopener noreferrer"&gt;https://farzamazhar.com/#work&lt;/a&gt;&lt;/p&gt;

</description>
      <category>ai</category>
      <category>webdev</category>
      <category>productivity</category>
      <category>architecture</category>
    </item>
  </channel>
</rss>
