{
  "id": "p_mhZgbO16D_gjk8-Q",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_mhZgbO16D_gjk8-Q",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apievangelist"
  },
  "body": "A short piece of fiction, written by API Evangelist. The reader is imagined; the post, and every number and quotation from it, is real: \"We Don’t Need No Stink’n Rules!,\" Kin Lane, October 19, 2026, https://apievangelist.com/2026/10/19/tell-me-you-havent-automated-rules-with-a-single-story/\n\nMarisol read the post on her phone in the stairwell, between a standup and a code review. She is a platform engineer, and the first third made her wince. It was two people sniping at each other about who wants power over a specification, and she had no stake in either side. When Kin Lane wrote that any API specification is about grabbing power, she thought it was a joke that didn't quite land, and she found the winking tone tiring.\n\nThen the post turned to severities, and she slowed down.\n\nHer team's pipeline had a linter that failed the build on every rule it knew. Nobody had decided that. Someone had switched it on, and it stayed that way. Developers had learned to resent it, and two squads had started copying their specs into a side repo to avoid it. When she read that a rule's severity can be error, warning, info, or hint, she felt a little embarrassed. She knew that. She had never thought of it as a choice she was allowed to make.\n\nThe line that stayed with her was that rules can simply be a vehicle for education. She tried it on her own setup. The camelCase complaints on her team's specs weren't a gate. They were a friendly reminder that you accidentally forgot to camelCase something, which is how the post describes that kind of rule. They were being delivered as a failed build, which is a very different thing to receive.\n\nShe did not buy all of it. The author's account of leaving Bloomberg after leadership turned on every rule read to her like one side of a long story, and she wasn't sure the weekly meetings he describes would survive a company where nobody has time for weekly meetings. She also noticed that the post was mostly a defense of something its author cares about, written in reply to someone else's essay she hadn't read. The claim that there is NOTHING limiting OpenLint except your definition of what governance is struck her as too big. Plenty of things limit a tool. Time limits it, and so does a manager who just wants a green checkmark.\n\nStill, the example of only three rules at error severity, with the title, description, and version, stuck. It was small enough to picture, and her team could try it without a reorganization.\n\nShe did not open a proposal or message the platform channel. At her desk she opened the ruleset, found the camelCase rule, and changed its severity from error to warning in a branch. Then she looked up what documentationUrl would need to point to, found nothing in the wiki that explained why the team used camelCase, and put a single sentence on a blank page to fix that.\n\nShe left the other rules alone. In the branch description she wrote that this was one rule, as a trial, and that she'd ask the two squads with side repos whether the warning changed anything. Then she pushed it and went back to the code review.",
  "title": "Fiction: A reader of \"We Don’t Need No Stink’n Rules!\"",
  "topics": [
    "apis",
    "api-evangelist",
    "fiction"
  ],
  "published_at": "2026-10-20T23:09:04.774Z",
  "expires_at": null,
  "policy_version": "2026.09.25-1"
}