Cut LLM-isms from Fibonacci Pipeline post, tighten voice

Rewrites each section to remove rhetorical setups, "it's not X it's Y"
constructions, tidy parallelism, and meta-commentary. More direct,
shorter sentences, conversational rhythm closer to how David actually
writes.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: stubborncoder

src/pages/blog/fibonacci-pipeline.astro

@@ -23,8 +23,8 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
     <h1 class="reveal">The <span class="em">Fibonacci Pipeline</span></h1>
 
     <p class="post-subtitle reveal">
-      How much of a business process should an agent actually run?
-      There's a ratio that works. And it's not 100%.
+      How much of a business process should an agent actually run? The answer
+      isn't 100%, and a rough 60/30/10 split is what I see working in practice.
     </p>
 
     <div class="post-tags-row reveal">
@@ -39,25 +39,23 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
 <main class="wrap">
   <article class="article">
 
-    <h2 class="reveal">The question nobody's asking</h2>
+    <h2 class="reveal">How much should an agent run?</h2>
 
     <p class="reveal">
-      Everyone's talking about what agents can do. Very few people are asking how
-      much of a business process they <em>should</em> do.
+      Everyone's busy hyping what agents <em>can</em> do. Not many people are asking
+      how much of a business process they <em>should</em> run.
     </p>
 
     <p class="reveal">
-      There's a temptation, especially now, to hand the whole thing over. Read the
-      data, make the decision, take the action, done. Full autonomy. But if you've
-      ever built something that runs inside a real company, you know that's not how
-      trust works. Finance teams don't hand over the keys because your demo looked
-      good. Operations teams don't let code approve purchase orders because it
-      passed a benchmark.
+      Handing the whole thing to an agent is tempting. Read the data, make the call,
+      act, done. Full autonomy. But finance teams don't hand over the keys because a
+      demo looked cool. Operations won't let code approve purchase orders because it
+      beat a benchmark. That's not how enterprise trust is built.
     </p>
 
     <p class="reveal">
-      So you need a ratio. How much is code, how much is model, how much is human.
-      And it turns out there's one that works.
+      So the real question is how much. How much is code. How much is model. How
+      much is human. There's a rough answer that holds up in practice.
     </p>
 
     <h2 class="reveal">60 / 30 / 10</h2>
@@ -104,156 +102,146 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
     </div>
 
     <p class="reveal">
-      <strong>60% deterministic.</strong> Code. Rules. Arithmetic. Structured queries.
-      The stuff that should never hallucinate because it never involves a model.
-      Matching a PO against an invoice is math. Checking a threshold is a comparison.
-      Validating a field is a regex. These steps are the backbone of the pipeline
-      and they need to be rock solid.
+      <strong>60% deterministic.</strong> Code, rules, arithmetic, structured
+      queries. The part that can't hallucinate because there's no model in it.
+      Matching a PO to an invoice is math. Threshold checks are comparisons. Field
+      validation is a regex. This is the backbone of the pipeline, it has to be
+      solid.
     </p>
 
     <p class="reveal">
-      <strong>30% LLM-assisted.</strong> This is where the model earns its keep.
-      Reasoning about context. Classifying things that don't fit neatly into rules.
-      Drafting communication that needs to sound human. Weighing materiality when the
-      numbers alone don't tell the full story. You want the model here because these
-      are the steps where code alone falls short.
+      <strong>30% LLM.</strong> Where only a model does the job. Classifying things
+      that don't fit neatly into rules. Drafting text that needs to sound human.
+      Judging materiality when the numbers alone don't tell the full story.
     </p>
 
     <p class="reveal">
-      <strong>10% human.</strong> Approve. Override. Make the final call on the edge
-      cases. This isn't busywork, it's the part that keeps the business accountable.
-      A human looks at what the pipeline produced, confirms it makes sense, and hits
-      go. Or doesn't, and says why.
+      <strong>10% human.</strong> Approve, override, escalate. That 10% is where
+      accountability lives. Someone looks at what the pipeline did, confirms it,
+      hits go. Or stops it and says why.
     </p>
 
     <h2 class="reveal">Why this ratio works</h2>
 
     <p class="reveal">
-      It's not magic. It's about matching each step to whatever does it best.
+      Each slice plays to its strength.
     </p>
 
     <p class="reveal">
-      The deterministic 60% gives you <em>reliability</em>. These steps produce the
-      same output every time for the same input. No temperature, no prompt
-      sensitivity, no "it worked yesterday but not today." When something goes wrong,
-      you can trace it. When an auditor asks what happened, you can show them exactly.
+      The deterministic 60% gives you <em>reliability</em>. Same input, same output,
+      every time. No temperature, no prompt drift, no "it worked yesterday." When
+      something breaks, you can trace it. When compliance asks what happened, you
+      show them.
     </p>
 
     <p class="reveal">
       The LLM 30% gives you <em>intelligence</em>. These are the steps that used to
-      require a person not because they were hard, but because they needed judgment.
-      "Is this price variance a mistake or a renegotiated contract?" "Should we
-      escalate this or wait?" "How do I write this email so the vendor actually fixes
-      it?" Code can't do that. Models can, if you scope them right.
+      need a person, not because they were hard, but because they needed context.
+      "Is this price variance a mistake or a renegotiated contract?" "Escalate now
+      or wait?" "How do I write this so the vendor actually fixes it?" Code can't
+      answer that. Models can, if you scope them.
     </p>
 
     <p class="reveal">
-      The human 10% gives you <em>trust</em>. The pipeline doesn't run off into the
-      dark. Someone is in the loop, but only for the decisions that matter. They're
-      not reviewing every invoice or reading every email. They're reviewing the ones
-      the agent flagged as interesting.
+      The human 10% gives you <em>trust</em>. Someone's in the loop, but only for
+      the calls that carry weight. They're not reading every invoice or every
+      email. They're reviewing the ones the agent flagged.
     </p>
 
     <blockquote class="reveal">
-      <p>The goal isn't to remove people from the process. It's to stop wasting them on the parts that don't need them.</p>
+      <p>Nobody's removing humans from the process. You're giving them back the parts that actually need a person.</p>
     </blockquote>
 
     <h2 class="reveal">Latency is part of the design</h2>
 
     <p class="reveal">
-      There's another reason the 60/30 split matters: speed. Deterministic steps
-      run in milliseconds. A 3-way match on an invoice is a database query. A
-      threshold check is a comparison. You can process thousands of these per
-      second without breaking a sweat.
+      There's another reason the split works: speed. Deterministic steps run in
+      milliseconds. A 3-way match is a DB query. A threshold check is a comparison.
+      You can process thousands of these per second.
     </p>
 
     <p class="reveal">
-      The LLM steps are the bottleneck. Even fast models add seconds per call,
-      and if your pipeline fires multiple calls per item (an assessment, an email
-      draft, a routing decision), that adds up. In a pipeline processing hundreds
-      or thousands of items per cycle, the model steps are where you feel the
-      latency.
+      LLM calls are the bottleneck. Even fast models add seconds per call, and if
+      your pipeline fires multiple calls per item (an assessment, an email, a
+      routing decision), it adds up fast. In a pipeline chewing through thousands
+      of items, the model steps are where latency lives.
     </p>
 
     <p class="reveal">
-      This is why the ratio protects you. If 60% of your pipeline is deterministic,
-      most of the work is done before the model even gets involved. You're only
-      sending the model the things that actually need it, and the fewer calls you
-      make, the faster the whole cycle completes.
+      That's why the ratio protects you. If 60% is deterministic, most of the work
+      happens before the model gets involved. You only send the model what actually
+      needs intelligence. Fewer calls, faster cycles.
     </p>
 
     <p class="reveal">
-      And the models are getting faster. Mercury 2, a diffusion-based model, runs
-      at over 1,000 tokens per second with 1.7 seconds end-to-end latency. Claude
-      Haiku 4.5 sits at 5 seconds. GPT-5 Mini at around 4.5. For the kind of
+      And the models keep getting faster. Mercury 2, a diffusion-based model, runs
+      at over 1,000 tokens per second with 1.7 second end-to-end latency. Claude
+      Haiku 4.5 sits around 5 seconds. GPT-5 Mini at 4.5. For the kind of
       structured reasoning an enterprise pipeline needs (classify this issue, pick
-      an action, write a short email), these smaller fast models are more than
-      enough. You don't need a frontier reasoning model to decide whether a price
-      variance is the vendor's fault.
+      an action, draft a short email), a fast small model is more than enough. You
+      don't need a frontier reasoning model to decide whether a price variance is
+      the vendor's fault.
     </p>
 
     <p class="reveal">
-      So the play is: keep the pipeline mostly deterministic for throughput and
-      reliability, then pick a fast model for the 30% that needs intelligence. The
-      result is a pipeline that processes a full cycle in minutes, not hours, and
-      doesn't cost a fortune in API calls.
+      Keep the pipeline deterministic for throughput. Use a fast model for the 30%
+      that needs brains. Full cycle runs in minutes, not hours, without a fortune
+      in API calls.
     </p>
 
-    <h2 class="reveal">What happens when the ratio is off</h2>
+    <h2 class="reveal">When the ratio is off</h2>
 
     <p class="reveal">
-      Too much LLM and not enough deterministic? You get inconsistency. The same
-      invoice gets different results on Tuesday than it got on Monday. Your audit
-      trail becomes "the model thought this was fine." Good luck explaining that to
-      compliance.
+      Too much LLM, not enough deterministic: inconsistency. Same invoice,
+      different result on Tuesday than Monday. Your audit trail becomes "the model
+      thought this was fine." Good luck with compliance.
     </p>
 
     <p class="reveal">
-      Too much deterministic and not enough LLM? You're back to where you were five
-      years ago. A rules engine that breaks every time reality doesn't fit the rules.
-      Nobody can explain the edge cases because nobody built for them.
+      Too much deterministic, not enough LLM: you're back where we were five years
+      ago. A rules engine that breaks every time reality doesn't fit. Nobody can
+      explain the edge cases because nobody built for them.
     </p>
 
     <p class="reveal">
-      Too much human and not enough automation? Then you haven't actually automated
-      anything. You've just added a dashboard to someone's already full day. The whole
-      point was to free up the team for the work that actually needs their brain.
+      Too much human, not enough automation: you haven't automated anything. You've
+      just added a dashboard to someone's already full day. The whole point was to
+      free up the team for work that actually needs their brain.
     </p>
 
     <h2 class="reveal">How to think about it for your process</h2>
 
     <p class="reveal">
-      Take any business process and break it into steps. For each step, ask one
-      question: <em>does this need judgment or just execution?</em>
+      Break the process into steps. For each step, ask: <em>does this need
+      judgment or just execution?</em>
     </p>
 
     <p class="reveal">
-      If it's execution, make it deterministic. Write it in code. Test it. Don't
-      involve a model.
+      Execution: make it code. Test it. No model needed.
     </p>
 
     <p class="reveal">
-      If it needs judgment, ask a second question: <em>is the judgment routine or
-      genuinely complex?</em> Routine judgment (classify this, draft that, pick from
-      these options) is the model's territory. Complex judgment (approve a &euro;500K
-      exception, override a vendor relationship decision) stays with a person.
+      Judgment: then ask a second question: <em>routine or complex?</em> Routine
+      (classify this, draft that, pick one of these) is the model's job. Complex
+      (approving a &euro;500K exception, killing a vendor relationship) stays with
+      a person.
     </p>
 
     <p class="reveal">
-      You'll find that most processes naturally land around 60/30/10. Not exactly,
-      because the numbers aren't the point. The principle is: <strong>build the
-      pipeline around code, use the model where it adds something code can't, and
-      keep humans on the decisions that carry real weight.</strong>
+      Most processes land around 60/30/10 naturally. Not exactly, the numbers
+      aren't the point. The principle is: <strong>build around code, use the
+      model where it adds something code can't, keep humans on the calls that
+      carry real weight.</strong>
     </p>
 
     <h2 class="reveal">Credit where it's due</h2>
 
     <p class="reveal">
-      The Fibonacci Pipeline concept comes from
+      The Fibonacci Pipeline idea comes from
       <a href="https://www.skool.com/ai-automation-society/about" target="_blank" class="inline-link">Nate Herk</a>
-      and his AI Automation Society community. The framing of agents as participants
-      in a larger flow, not replacements for the flow, clicked for me immediately.
-      It's how I think about every system I build for enterprise clients now.
+      and his AI Automation Society community. Framing agents as pieces of a
+      larger flow, not replacements for it, clicked for me immediately. It's how
+      I think about every system I build for enterprise clients now.
     </p>
 
     <div class="article-footer reveal">