<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>case studies on Abbreviatory.com</title>
    <link>https://abbreviatory.com/tags/case-studies/</link>
    <description>Recent content in case studies on Abbreviatory.com</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 19 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://abbreviatory.com/tags/case-studies/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>How to Find the Errors That Matter in a Log of 63 Thousand Lines</title>
      <link>https://abbreviatory.com/how-to-find-the-errors-that-matter-in-a-log-of-63-thousand-lines/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      
      <guid>https://abbreviatory.com/how-to-find-the-errors-that-matter-in-a-log-of-63-thousand-lines/</guid>
      <description>Something went wrong overnight and the service log is 5.6 MB: 63,369 lines. Most of them are cache hits and request logs. Somewhere in there are the errors, each one repeated hundreds of times with a different order number or request ID, so even grep ERROR gives back 4,313 lines. Reading those by hand, or pasting them into a chat with a coding agent, is how an hour disappears.
The log in this example is the generated application log from our test fixtures: Java exceptions with stack traces, Python tracebacks, a Go panic, database errors, in the proportions a busy service produces them.</description>
    </item>
    
    <item>
      <title>How to Give a Coding Agent Short Test Reports Through the Abbreviatory MCP Server</title>
      <link>https://abbreviatory.com/how-to-give-a-coding-agent-short-test-reports-through-the-abbreviatory-mcp-server/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      
      <guid>https://abbreviatory.com/how-to-give-a-coding-agent-short-test-reports-through-the-abbreviatory-mcp-server/</guid>
      <description>A coding agent fixing a bug runs the tests again and again. Change a line, run go test ./..., read the output, change another line. Each run of our sample suite prints 4,882 lines of go test -json events, 808 kB, and almost all of it says a test passed. The agent reads every line, every time, and pays for every line in its context window. By the tenth run most of its context is old test output.</description>
    </item>
    
    <item>
      <title>How to Map an Unfamiliar Repository With find and Abbreviatory</title>
      <link>https://abbreviatory.com/how-to-map-an-unfamiliar-repository-with-find-and-abbreviatory/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      
      <guid>https://abbreviatory.com/how-to-map-an-unfamiliar-repository-with-find-and-abbreviatory/</guid>
      <description>The first thing anyone does in a new repository is look around. A person runs tree and gives up after a few screens. A coding agent runs find . -type f and gets every path, and on a large project that&amp;rsquo;s thousands of lines spent before it has read a single file. Most of them say the same thing: another test fixture, another Go file in the same package.
The listing in this example is find src -type f over Go&amp;rsquo;s own source tree, which is big enough to make the point: 10,703 paths in 1,097 directories, 454.</description>
    </item>
    
    <item>
      <title>How to See the Shape of a Large Git Diff Before Reading Its Lines</title>
      <link>https://abbreviatory.com/how-to-see-the-shape-of-a-large-git-diff-before-reading-its-lines/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      
      <guid>https://abbreviatory.com/how-to-see-the-shape-of-a-large-git-diff-before-reading-its-lines/</guid>
      <description>Reviewing a big change starts with a question the diff doesn&amp;rsquo;t answer up front: what&amp;rsquo;s in here? git diff prints the first file&amp;rsquo;s first hunk and makes you scroll for the rest. A coding agent asked to review the same change reads all of it in order, and a 190 kB diff fills a good part of its context before it has seen the list of files.
The diff in this example is a real one, Abbreviatory&amp;rsquo;s own changes from v0.</description>
    </item>
    
    <item>
      <title>How to Show What Changed Since the Last Run in a GitHub Actions Job Summary</title>
      <link>https://abbreviatory.com/how-to-show-what-changed-since-the-last-run-in-a-github-actions-job-summary/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      
      <guid>https://abbreviatory.com/how-to-show-what-changed-since-the-last-run-in-a-github-actions-job-summary/</guid>
      <description>A red build on GitHub Actions usually means scrolling. The job log holds thousands of lines, the failures are somewhere in the middle, and the first question is always the same: did this break just now, or has it been broken for a week? The log can&amp;rsquo;t say. It only knows about this run.
Abbreviatory can, if it keeps a history. Put abbreviatory run in front of the test command and send its report to the job summary.</description>
    </item>
    
    <item>
      <title>How to Watch an API for New Errors With curl and Run History</title>
      <link>https://abbreviatory.com/how-to-watch-an-api-for-new-errors-with-curl-and-run-history/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      
      <guid>https://abbreviatory.com/how-to-watch-an-api-for-new-errors-with-curl-and-run-history/</guid>
      <description>Plenty of APIs answer 200 OK and put the trouble in the body. A catalogue export says &amp;quot;status&amp;quot;: &amp;quot;partial&amp;quot;, and three of its 2,500 items carry an error object saying the price feed is stale. The status code says all is well, and the 720 kB of JSON is too much to read every time someone checks.
The response in this example is the catalogue export from our test fixtures, fetched with curl -si from a local server: 37,534 lines with the headers.</description>
    </item>
    
  </channel>
</rss>
