<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Llm on Robert Terakedis</title>
    <link>https://blog.terakedis.dev/tags/llm/</link>
    <description>Recent content in Llm on Robert Terakedis</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>Copyright © Robert Terakedis; all rights reserved.</copyright>
    <lastBuildDate>Mon, 15 Jun 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.terakedis.dev/tags/llm/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Building a Leaner AI Development Workflow for Claude Pro</title>
      <link>https://blog.terakedis.dev/post/bmad-lite-skills-claude-pro-workflow/</link>
      <pubDate>Mon, 15 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.terakedis.dev/post/bmad-lite-skills-claude-pro-workflow/</guid>
      <description>&lt;p&gt;Earlier this year, I started using &lt;a href=&#34;https://github.com/bmad-method/bmad&#34;&gt;BMAD&lt;/a&gt; as a structured way to build software with Windsurf at work. The basic idea is sound: write planning docs first (PRD, architecture, epic breakdown), then give the AI one well-scoped story at a time to implement. Instead of one giant &amp;quot;build me this app&amp;quot; prompt that wanders off course, you get repeatable cycles with clear checkpoints.&lt;/p&gt;&#xA;&lt;p&gt;It worked well enough that I wanted to use it on everything, including some hobby projects at home. Then I ran into the context budget like a brick wall.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Designing an AI Pipeline That Works Everywhere, All the Time</title>
      <link>https://blog.terakedis.dev/post/ai-pipeline-reliability-9am/</link>
      <pubDate>Sun, 14 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.terakedis.dev/post/ai-pipeline-reliability-9am/</guid>
      <description>&lt;p&gt;I wrote about the &lt;a href=&#34;https://blog.terakedis.dev/post/llms-are-not-magic/&#34;&gt;matching logic behind this system&lt;/a&gt; in an earlier post. That post covers the five-layer architecture: intake, vector search, LLM scoring, threshold routing, and feedback. What it doesn&#39;t cover is the part that took just as much thought: making the whole thing reliable enough that the team can count on it regardless of when or where they&#39;re working.&lt;/p&gt;&#xA;&lt;p&gt;Getting a prototype working on a Friday afternoon is one problem. Getting a system to reliably respond to events around the clock, across a globally distributed team, is a different problem. That&#39;s what this post is about.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Why I Stopped Treating LLMs as Magic and Started Treating Them as Components</title>
      <link>https://blog.terakedis.dev/post/llms-are-not-magic/</link>
      <pubDate>Sat, 16 May 2026 00:00:00 +0000</pubDate>
      <guid>https://blog.terakedis.dev/post/llms-are-not-magic/</guid>
      <description>&lt;p&gt;I recently got the opportunity to build out an AI-powered feature-matching system.  Some of my coworkers had already started mocking the idea - give an LLM a spreadsheet of ideas and features, let it give you back the list of matches.   Feed it the customer&#39;s idea, get back a match. Easy.   I initially made the same assumption a lot of teams make: I treated the LLM as &lt;em&gt;the solution&lt;/em&gt;.&lt;/p&gt;&#xA;&lt;p&gt;It wasn&#39;t easy.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
