<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Posts on Shahram Anver</title>
    <link>https://shahramanver.com/posts/</link>
    <description>Recent content in Posts on Shahram Anver</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 04 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://shahramanver.com/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>AI agent learning beats demo flashiness</title>
      <link>https://shahramanver.com/posts/ai-agent-learning-beats-demo-flashiness/</link>
      <pubDate>Wed, 04 Mar 2026 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/ai-agent-learning-beats-demo-flashiness/</guid>
      <description>Every AI agent demo looks the same now.
What&amp;rsquo;s matters is how well the agent learns in its specific domain.
The best teams see production as a team sport, not a place for individual heroics. When one engineer figures out that OOM spike is always the Redis sidecar, we want all engineers to know. But&amp;hellip; it&amp;rsquo;s never been easy making that happen.
Learning is the real value of AI agents in production — not just MTTR reduction or alert triaging.</description>
    </item>
    
    <item>
      <title>Abundance mindset with AI SRE competitors</title>
      <link>https://shahramanver.com/posts/abundance-mindset-with-ai-sre-competitors/</link>
      <pubDate>Wed, 04 Feb 2026 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/abundance-mindset-with-ai-sre-competitors/</guid>
      <description>At re:Invent, I walked by a guy wearing a Deductive AI jacket. They&amp;rsquo;re a direct competitor, so I stopped and introduced myself.
Turns out it was Rakesh, their CEO.
Within five minutes, we were excitedly swapping notes on AI SRE like old friends.
Same thing happened with Stephen from incident.io - he reached out and we planned 30 minutes for coffee. We ended up talking for over an hour before he realized he was late to his next meeting.</description>
    </item>
    
    <item>
      <title>The coding interview needs to die</title>
      <link>https://shahramanver.com/posts/the-coding-interview-needs-to-die/</link>
      <pubDate>Wed, 04 Feb 2026 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/the-coding-interview-needs-to-die/</guid>
      <description>The coding interview as we know it needs to die, but no one at the table knew what replaces it.
At a dinner we hosted with engineers from Anthropic, OpenAI, TogetherAI, Apple, and other startups this was the most contentious topic: how do you review engineering as a craft when AI writes the code?
Some basics are now even more important like:
First-principles thinking, like asking why before reaching for a new pattern or tool.</description>
    </item>
    
    <item>
      <title>Two years in America</title>
      <link>https://shahramanver.com/posts/two-years-in-america/</link>
      <pubDate>Sun, 04 Jan 2026 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/two-years-in-america/</guid>
      <description>It&amp;rsquo;s almost 2026, which means I&amp;rsquo;ve been in the US for nearly two years now.
I thought I knew what to expect. America is always in the news… the ambition, the chaos, the scale of everything.
Turns out it&amp;rsquo;s what I didn&amp;rsquo;t expect that defined my time here.
A few weeks after we moved, I took my daughters to the park. Ice cream truck pulls up. I queue with them, excited to give them their first American ice cream truck experience.</description>
    </item>
    
    <item>
      <title>Hallucination rate is the wrong question</title>
      <link>https://shahramanver.com/posts/hallucination-rate-is-the-wrong-question/</link>
      <pubDate>Wed, 10 Dec 2025 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/hallucination-rate-is-the-wrong-question/</guid>
      <description>What&amp;rsquo;s your hallucination rate?
I get this question constantly. And for a while, I tried to answer it with benchmarks, percentages, confidence intervals.
None of it moved the needle.
Turns out the question isn&amp;rsquo;t really &amp;ldquo;how often does your agent lie?&amp;rdquo; It&amp;rsquo;s &amp;ldquo;should I trust this thing?&amp;rdquo;
And that&amp;rsquo;s not something you answer with a number.
It&amp;rsquo;s something Fred answers.
Every org has a Fred. The senior engineer who&amp;rsquo;s picky, skeptical, hard to impress.</description>
    </item>
    
    <item>
      <title>Coding agents vs SRE agents are different beasts</title>
      <link>https://shahramanver.com/posts/coding-agents-vs-sre-agents/</link>
      <pubDate>Sat, 15 Nov 2025 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/coding-agents-vs-sre-agents/</guid>
      <description>Coding agents and &amp;ldquo;AI SRE&amp;rdquo; are both agents, but they&amp;rsquo;re fundamentally different beasts.
A coding agent goes deep. It has to handle infinite types of requests (add feature X) against one context: your repo. An SRE agent goes wide. Finite types of asks (why is X down?), but the context sprawls across everything you run.
And that width is where the pain lives. To diagnose an issue:
Your K8s cluster isn&amp;rsquo;t useful without your logs.</description>
    </item>
    
    <item>
      <title>We&#39;re asking the wrong question about AI agents in production</title>
      <link>https://shahramanver.com/posts/wrong-question-about-ai-agents-in-production/</link>
      <pubDate>Wed, 05 Nov 2025 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/wrong-question-about-ai-agents-in-production/</guid>
      <description>We&amp;rsquo;re asking the wrong question about AI agents in production.
The debate right now is if they&amp;rsquo;re only good for prototypes or if they can actually ship to prod.
Both camps are loud. Both are right&amp;hellip; in their own environment.
The better question is what separates them.
I&amp;rsquo;ve seen two big factors.
1/ Tech stack. LLMs know Python, Javascript, Go, Java far better than Scala or Elixir. If your stack&amp;rsquo;s niche, you&amp;rsquo;re fighting uphill.</description>
    </item>
    
    <item>
      <title>Dogfooding is an experiment, not a mandate</title>
      <link>https://shahramanver.com/posts/dogfooding-is-an-experiment-not-a-mandate/</link>
      <pubDate>Sun, 05 Oct 2025 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/dogfooding-is-an-experiment-not-a-mandate/</guid>
      <description>All of the best products had brutal amounts of dogfooding.
Slack. Kubernetes. Cloudflare.
But a mistake teams make is treating dogfooding like a compliance ritual, something everyone has to do.
That&amp;rsquo;s when it stops teaching you anything.
Dogfooding is an experiment, not a mandate.
The real question is: if people could easily leave, would they still choose your product?
At Gojek, when I ran ML platforms, we never forced adoption. Teams could use GCP&amp;rsquo;s stack or OSS alternatives, whatever they liked.</description>
    </item>
    
    <item>
      <title>Founders should code a little</title>
      <link>https://shahramanver.com/posts/founders-should-code-a-little/</link>
      <pubDate>Wed, 01 Oct 2025 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/founders-should-code-a-little/</guid>
      <description>Founders should code.
Not all the time.
Not never.
A little.
Coding is crack for technical CEOs. It feels like progress, it&amp;rsquo;s an easy dopamine hit.
Shipping a PR is clean, measurable. Sending cold emails or sitting in ambiguity? Not so much.
So I used to treat coding like junk food and cut it out completely. I only focused on GTM and product direction, the &amp;ldquo;real&amp;rdquo; CEO work.
And that worked… until it didn&amp;rsquo;t.</description>
    </item>
    
    <item>
      <title>Kill the flies before fighting fires</title>
      <link>https://shahramanver.com/posts/kill-the-flies-before-fighting-fires/</link>
      <pubDate>Wed, 10 Sep 2025 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/kill-the-flies-before-fighting-fires/</guid>
      <description>Kill the flies. Then you&amp;rsquo;ll finally have time for the fires.
Hot take: most teams don&amp;rsquo;t have an &amp;ldquo;incident response&amp;rdquo; problem. They have a noise economy problem. We celebrate the Friday-night P0 save and ignore the 300 pages that ate someone&amp;rsquo;s entire week. Half of those &amp;ldquo;real&amp;rdquo; alerts auto-resolve. That&amp;rsquo;s not resilience, it&amp;rsquo;s Stockholm syndrome.
If your on-call spends the week acknowledging PagerDuty, you&amp;rsquo;re not improving MTTR - you&amp;rsquo;re burning the team&amp;rsquo;s mean thinking time.</description>
    </item>
    
    <item>
      <title>Deploy AI agents with domain-confident teams first</title>
      <link>https://shahramanver.com/posts/deploy-ai-agents-with-domain-confident-teams/</link>
      <pubDate>Sun, 20 Apr 2025 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/deploy-ai-agents-with-domain-confident-teams/</guid>
      <description>If you&amp;rsquo;re thinking about deploying AI agents, start with teams that have strong domain confidence. I&amp;rsquo;ve seen this pattern repeatedly and I suspect it&amp;rsquo;ll be an industry pattern through 2025.
These teams know their systems well. They can tell when an agent is genuinely helpful, and when it&amp;rsquo;s off. That confidence makes all the difference.
Early adopters tend to be the strongest teams. Low alert fatigue and high confidence in their systems.</description>
    </item>
    
    <item>
      <title>Engineering teams&#39; informal failure banks</title>
      <link>https://shahramanver.com/posts/engineering-teams-informal-failure-banks/</link>
      <pubDate>Thu, 10 Apr 2025 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/engineering-teams-informal-failure-banks/</guid>
      <description>Every engineering team has an informal &amp;ldquo;failure bank&amp;rdquo; distributed across different engineers&amp;rsquo; memories. Engineer A knows all the edge cases of different configs. Engineer B has fought many battles with Kafka rebalancing. Engineer C knows all the quirks with Kubernetes autoscaling. This uneven distribution of troubleshooting effectiveness is both a strength and a vulnerability.
Last week an engineer told me how he saved his team from a multi-hour outage. Kubernetes pods were stuck in &amp;lsquo;Pending&amp;rsquo; with no error messages.</description>
    </item>
    
    <item>
      <title>Agent prompts evolved from yelling to specs</title>
      <link>https://shahramanver.com/posts/agent-prompts-evolved-from-yelling-to-specs/</link>
      <pubDate>Sat, 05 Apr 2025 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/agent-prompts-evolved-from-yelling-to-specs/</guid>
      <description>I was looking at our agent prompts the other day and thought about how quickly the way we build the agent has changed.
In 2023, our prompts looked like emergency broadcasts: &amp;ldquo;ALWAYS LOOK AT RECENT DEPLOYMENTS FIRST!!!&amp;rdquo; and &amp;ldquo;JUST GIVE ME JSON, ONLY THE FACTS!!!&amp;rdquo; We were yelling at the models, pleading for them to just follow basic instructions.
Fast forward to today, and the prompts read more like technical specs with nuanced instructions.</description>
    </item>
    
    <item>
      <title>When your agent evals get too sentient</title>
      <link>https://shahramanver.com/posts/when-agent-evals-get-too-sentient/</link>
      <pubDate>Thu, 20 Mar 2025 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/when-agent-evals-get-too-sentient/</guid>
      <description>Our agent evals got a little too sentient today. The agent detected it was in a simulated Kubernetes environment (Kwok) and refused to investigate further.
Interesting… do you
Lie to the agent and insist it&amp;rsquo;s a real env and keep going Pat it on the back and call it a successful eval? Earlier today, it complained that, and this is not a joke, that the system it is investigating isn&amp;rsquo;t its responsibility and we should escalate to another team.</description>
    </item>
    
    <item>
      <title>Small anomalies compound into catastrophic outages</title>
      <link>https://shahramanver.com/posts/small-anomalies-compound-into-catastrophic-outages/</link>
      <pubDate>Sat, 15 Mar 2025 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/small-anomalies-compound-into-catastrophic-outages/</guid>
      <description>Most catastrophic outages don&amp;rsquo;t start with dramatic failures - they begin with small anomalies that compound over time. A minor latency increase, an occasional timeout, a query that&amp;rsquo;s slightly slower than usual. None trigger immediate action, but left unaddressed, they become the foundation for systemic failures.
These &amp;ldquo;paper cuts&amp;rdquo; are a bandwidth problem, not a detection problem. Engineers already know about these issues - they&amp;rsquo;re buried in dashboards, buried in logs, buried in the team&amp;rsquo;s collective memory.</description>
    </item>
    
    <item>
      <title>Cross-team debugging friction is the real killer</title>
      <link>https://shahramanver.com/posts/cross-team-debugging-friction/</link>
      <pubDate>Wed, 05 Mar 2025 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/cross-team-debugging-friction/</guid>
      <description>The real productivity killer in production isn&amp;rsquo;t technical complexity - it&amp;rsquo;s the organizational friction of debugging issues across team boundaries.
Last week, a senior engineer at big-tech-company told me something that hit home: &amp;ldquo;When we spot an issue, we decide whether to band aid it now or spend a quarter chasing the real fix.&amp;rdquo; This isn&amp;rsquo;t a technical limitation. It&amp;rsquo;s what happens when the coordination cost exceeds fix cost.
Here&amp;rsquo;s a familiar pattern: An alert fires.</description>
    </item>
    
    <item>
      <title>I quit my job to tackle complexity in software systems</title>
      <link>https://shahramanver.com/posts/quitting-my-job/</link>
      <pubDate>Sat, 28 Oct 2023 00:00:00 +0000</pubDate>
      
      <guid>https://shahramanver.com/posts/quitting-my-job/</guid>
      <description>A few months ago I was on a call which led to quitting my job.
I wasn&amp;rsquo;t angry, the call went great. I actually loved my job, had great colleagues and was having a ball solving complex problems.
Instead, the call made me obsess about the new world that was coming and how we all needed to prepare for it. If engineering systems is your jam, read on.
It was a regular review call with engineering leadership to review production issues in the past month.</description>
    </item>
    
  </channel>
</rss>
