![\"The](\"https://pau.fm/images/blog/ted-cruz-cipher.webp\")
![\"Claude](\"https://pau.fm/images/blog/ted-cruz-cipher-claude.webp\")
I wonder how the Kafka microservices for that low-volume CRUD app are going.
\n", "date_published": "2026-09-15T00:00:00.000Z", "id": "https://pau.fm/blog/2026/09/15/kafka-microservices", "summary": "I wonder how the Kafka microservices for that low-volume CRUD app are going.", "tags": [ "short" ], "title": "I wonder how the Kafka microservices for that low-volume CRUD app are going.", "url": "https://pau.fm/blog/2026/09/15/kafka-microservices" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Inspired by\nClaude Fable 5.1 solving the 370-year-old Cyphral Distich,\nI asked it to decrypt a message from my good friend Ted Cruz.
\nI came up with a phrase recently, while thinking about the price of AI tokens: commodities want to\nbe cheap.
\nI mean it in the neoliberal sense. Once something becomes standardized, substitutable, scalable, and\nwidely produced, competition starts attacking the margin. Producers can differentiate, constrain\nsupply, bundle, brand, regulate, or monopolize, but the underlying pressure remains. A commodity\nwants to collapse toward the lowest sustainable price.
\nThe phrase obviously inherits its structure from Stewart Brand’s “information wants to be free.” I\nhad always understood Brand’s line mostly as a claim about censorship: information is easy to copy\nand distribute, therefore attempts to contain it eventually fail. But the original argument was more\neconomic. Information wants to be expensive because it is valuable, and free because the cost of\nreproducing and distributing it keeps falling.
\nTokens are in exactly that position. They are becoming a commodity. The expensive part is creating\nthe frontier model; once a capability exists, inference gets cheaper, hardware improves, models get\nsmaller, distillation transfers capability downward, and competitors attack whatever margin remains.\nChinese labs add another source of pressure: whatever American frontier labs spend discovering,\nfirms with lower costs and fewer reasons to protect incumbent margins have every incentive to\nreproduce and commoditize.
\nThis is why the current argument over slowing AI development is economically interesting. Dario\nAmodei’s recent call to\n“pace the frontier” explicitly asks\ngovernments to require common standards and enable coordination among frontier labs; a less\ncharitable reading is that the incumbents are asking the state to protect them from the economics of\ntheir own product. Sam Altman and Elon Musk have publicly supported the proposal, which makes sense:\nall three are vulnerable to the same commoditization pressure.
\nThe labs spend enormous amounts of energy resisting this process. They differentiate models, create\nswitching costs, build ecosystems, control distribution, restrict access to weights, and try to\npreserve technological leads. They do this for the same reason every producer resists\ncommoditization: tokens are a commodity, and commodities want to be cheap.
\n", "date_published": "2026-09-14T00:00:00.000Z", "id": "https://pau.fm/blog/2026/09/14/commodities-want-to-be-cheap", "summary": "Frontier models are expensive to create and cheap to reproduce, so tokens are becoming a commodity. Commodities want to be cheap, and the labs know it.", "tags": [ "essay" ], "title": "Commodities want to be cheap", "url": "https://pau.fm/blog/2026/09/14/commodities-want-to-be-cheap" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Software has entered the Slop Era.
\nThe cost of producing plausible code has collapsed, but the cost of knowing whether that code\nbelongs in your system has not. Every engineering team using coding agents now trivially generates\nmore code than it can responsibly absorb.
\nSlop is code that is locally reasonable but globally careless: the fifth copy of a helper function,\na try/catch block that hides an error from the error reporter, a session-scoped lock behind a\ntransaction pool, a migration that runs cleanly yet undermines the application’s security model.\nSlop survives casual review because every line looks plausible, but introduces risk because it lacks\nknowledge of the system around it.
\nThese problems existed before the Cambrian explosion of code generation. The naive response then, as\nnow, was to demand more careful review. That does not scale. The answer to the Slop Era is not\nmore careful engineers, but engineering discipline made executable.
\nBy discipline, I don’t mean heroics, process theater, or a longer approval chain. I mean taking the\njudgment a strong engineer carries in their head and putting it into the environment, dependency\ngraph, lint rules, types, tests, comments, and deployment path. The system should supply missing\ncontext, reject known mistakes, contain the blast radius, and preserve the reason behind old\ndecisions.
\nThe answer to the slop problem ends up looking a lot like what the best engineering teams have been\ndoing for the past decade: turning convention into constraints. This is not a special set of\nguardrails for agents - what’s good for humans is good for machines. Both make locally plausible\nmistakes when they lack context; the difference in the Slop Era is that agents hit these problems\noften enough to make the return on fixing them impossible to ignore.
\nSonora tests whether that discipline can keep up with output. Over the last sixty days, I merged 257\npull requests into main, over six per day on working days. Across the team, 761 PRs landed, an\naverage of sixteen per shipping day, with a peak of 34. We are a team of five engineers. I remember\nentire months at a prior startup, with a much larger team, that did not ship close to what we now do\nin a day.
Six PRs in a day would be meaningless if they were six typo fixes. Sonora’s codebase is barely a\nyear old and already runs close to 1 million lines of TypeScript across thirty packages, and a\nsingle PR routinely spans a migration, worker jobs, UI, tests, and docs. That is the real stress\ntest: can the system absorb a change that wide without requiring me to inspect every boundary by\nhand? I’m not typing six times faster. The repository is doing more of the remembering, checking,\nand rejecting before the change reaches me.
\nThe governing idea is make it cheap to be wrong. AI did not invent this discipline, but it\nchanged the discount rate: work that used to pay back once a sprint now pays back dozens of times a\nday.
\nFast feedback. One command that does the thing. Errors that explain what to do next. Comments that\nrecord why an obvious alternative failed. These were good engineering practices before coding\nagents, but agents make their value visible because they exercise the system far more often.
\nStart with the development environment. An agent will confidently reason from whatever world you\ngive it. If that world has the wrong port, a drifting Node version, or somebody else’s database, a\ngreen test can certify fiction.
\nOur environment is a Nix flake. Node, Postgres, Redis,\nPulumi, gcloud, kubectl, ShellCheck, and the\nrest of the toolchain are pinned. Entering the repo starts its services. Ports are allocated per\ncheckout and exported as environment variables, so multiple copies of Sonora can run side by side\nwithout sharing a database or guessing who owns port 5432.
\nThis is what loading the repo looks like:
\n╭──────────────────────────────────────────────────────────────╮│ 🦊 sonora dev ││ ││ ▴ Postgres 127.0.0.1:5432 ││ ▴ Redis 127.0.0.1:6379 ││ ▴ Mailpit 127.0.0.1:1025 → http://127.0.0.1:8025 ││ ▴ App http://app.sonora.localhost:3000 ││ ▴ Worktrees grove · grove --once snapshot ││ ▴ Turbo shared · read-only ││ ││ ✓ ready to build · run pnpm dev │╰──────────────────────────────────────────────────────────────╯The banner is for humans, and we suppress it in non-interactive shells, but the port assignments are\nstill exported as $PGPORT, $REDISPORT, and $PORT. Our AGENTS.md tells\ncoding agents to use those variables instead of guessing the defaults. Before every shell command, a\nhook puts the agent inside nix develop, so when it runs pnpm test, it gets the same pinned Node\nand dependencies I do, along with that worktree’s own Postgres.
Humans are pretty good at noticing when an environment is wrong. We see an unexpected port or\nversion, swear a little, and adjust. But agents are more likely to accept what they see as fact and\nbuild the next ten steps on top of it. A passing test in the wrong environment is worse than a\nfailing one because it sends the rest of the work in the wrong direction.
\nThis is also why I have become more opinionated about monorepos. An agent can work only with what\nexists in its checkout. Put the worker in one repository and the app in another, and any change that\nspans both becomes a coordination problem. Humans compensate with memory, Slack, and meetings, while\nagents guess. Neither is a good use of time.
\nSonora keeps the application, worker, database package, infrastructure, documentation, supporting\ntools, and marketing site in one repository. Even this post is a Markdown file in the same repo. The\napp, worker, database package, and Pulumi infrastructure are all TypeScript, so changes across those\nboundaries stay in one type system. One recent change added cost visibility to workflows. It touched\n27 files across a database migration, worker code, pricing logic and tests, the workflow builder,\nthe credits settings page, and two architecture docs. It was one product change, so it was one PR. I\ndid not need to coordinate three repositories or remember which part had shipped.
\nKeeping everything together does not mean every change runs every test or deploys every application.\nTurborepo already knows the dependency graph. CI uses it to determine which\npackages need checking, and the deployment pipeline uses it to determine whether production code\nchanged. Editing this post republishes the marketing site and stops there. Without that filtering,\nchanging this sentence would run the entire application suite. We lean on the dependency graph to\nkeep changes isolated and checks targeted.
\nConventions aren’t actionable in their natural state. They’re just a shared understanding; a piece\nof advice. Teams have spent a decade trying to make a codebase read as though one person wrote it.\nThat consistency now has a functional purpose: agents learn from the nearest example. Engineering\ndiscipline becomes executable when violating the convention produces immediate, specific feedback.\nThe job is to move judgment out of reviewers’ heads and into mechanisms that can reject a change. We\nuse this ladder:
\n![\"Five](\"https://pau.fm/images/blog/engineering-discipline-inline.webp\")
A prompt is advice for one task. A skill is reusable advice. A hook runs without being asked. A lint\nrule rejects a bad pattern. A type makes the invalid state unrepresentable. When the same correction\nappears three times in review, I try to move it one\nrung to the right.
\nEvery coding agent starts by reading AGENTS.md. It is the standing prompt for the repository, a\nway to give every agent the same starting context, but still only the first rung on that ladder.\nOurs is 356 lines, most of them recording decisions we do not want to relitigate: /api/* is\nreserved for a future public API; every form prevents duplicate submissions; use this primitive\nrather than inventing another one.
As a prompt, AGENTS.md can explain what to do and why. But it can’t stop anyone from doing the\nopposite. For decisions we care enough about, the build says no. We have 22 custom\noxlint rules in a package called vibes, including:
no-catch-500 stops a handler from swallowing an error and hiding it from Sentry.require-job-group-in-loop catches queue fan-outs that could let one tenant monopolize the\nworkers.no-session-advisory-lock rejects session-scoped Postgres locks because we run\nPgBouncer in transaction mode.no-as-unknown-as rejects the as unknown as T double assertion, which disables type checking\nwithout narrowing anything.any is also an error outside tests. Both are ways to opt out of the type checking we chose\nTypeScript for. The linter does not care whether the code came from me, a teammate, or an agent. It\nfails in the same place and explains both the danger and what to do instead. Once we have paid to\nlearn a rule, enforcing it should not depend on the next reviewer remembering it.
Exceptions are explicit. A one-line suppression names the rule and gives the reason:\n// oxlint-disable-next-line jsx-a11y/no-autofocus -- intentional focus on dialog open.
The most common signature of machine-generated slop is entropy. The fifth copy of a helper function\ncan be correct and still make the system worse because it introduces more maintenance cost, CI\nexecution time and surface area for drift. Yet no human reviewer remembers every similar helper\neither. Our vibedupes utility, built on similarity-ts,\ncompares function syntax trees to detect functionally duplicate code. It checks changed functions on\neach PR and runs a full-repository scan weekly. We tuned it until a match meant “fork” rather than\n“similar shape,” because an ignored check is worse than no check at all.
That tuning threshold is still a judgment call, and the next person needs to know why we drew the\nline at 90% similarity. Which brings me to comments.
\nI owe comments a mea culpa. For most of my career, I believed good code should explain itself and\nthat a long comment was evidence of a bad abstraction. I still believe that when the comment merely\nnarrates what the code does. But no function name can tell you why four test shards are faster than\neight in this repository, why a threshold is 0.90 instead of 0.85, or which production incident\nmade a particular constraint necessary. Some of the comments I value most today are longer than\nyounger me would have tolerated because they preserve history, not mechanics.
There is no clever solution to comment rot. We make comments local, concrete, and falsifiable. A\nuseful comment sits beside the decision and names the benchmark, incident, or rejected alternative\nbehind it. Whenever the constraint can be expressed as a test, lint rule, or type, that mechanism\ndoes the enforcing; the comment explains why it exists. “Be careful here” will rot. “Four shards,\nnot eight, because the critical path moves below 56 seconds” gives the next engineer something they\ncan verify.
\nThe threshold in vibedupes has exactly that kind of comment:
// Tuned against this repo: at 0.85/5 lines the report fills with `toNumber` and// one-line chart validators. Raising both leaves the forked-function findings.// 0.90 is where the pairs still read as copies rather than as functions that// merely share a shape — every fork family we set out to catch scores above it// (the three rate limiters are 99.33%, the four Snowflake JWT builders 99.59%).const DEFAULT_THRESHOLD = \"0.90\";const DEFAULT_MIN_LINES = \"15\";Without that history, lowering the threshold looks prudent. A new engineer and an agent share the\nsame failure mode here: locally sensible reasoning without the history. The comment puts the history\nat the one place both are guaranteed to see it.
\nDocumentation works the same way. It lives beside the code, and source comments link to it by path.\nThe job-group rule points to the concurrency architecture doc. A person or agent can follow that\nlink while working instead of guessing what somebody once wrote in a wiki. Context that cannot be\nreached from the checkout is not dependable context.
\nExecutable discipline has to be fast. When feedback is slow, people batch changes and work around\nchecks; agents burn cycles or form wrong conclusions. A high-output repository must say no quickly,\nspecifically, and as close as possible to the mistake. We make checks fast not by dropping them, but\nby testing the narrowest set of things that a change could break, and by not recomputing answers we\nalready trust.
\npnpm check is one command. CI uses Turborepo’s --filter='...[origin/main]' to test only affected\npackages rather than the entire monorepo. A marketing-site change does not wait for more than a\nthousand application test files. Locally, pnpm check:min applies the same idea to the current\ndiff. It asks Turborepo which packages the change can affect, then lets Vitest follow the module\ngraph to the relevant tests. Changing a single utility might run only one test file, taking just a\nsecond or two, while changing a root configuration file will run the whole suite. Skipping\nunnecessary work is the programmer’s kind of laziness.
When the application suite does need to run, its thousand-plus test files are sharded and run in\nparallel across multiple jobs, each with its own Postgres instance. This gives us parallelism\nwithout shared-database contention or cross-test interference. Nine out of ten PRs are green or red\nin under six minutes; the median CI run takes about three and a half minutes.
\nThe other large win is refusing to repeat work. CI publishes successful task results to a shared\nTurborepo cache that developers and agents can read but not write. A passing check from my Mac\nshould not be allowed to convince Linux CI that it can skip the same check. After every merge,\nanother workflow warms the cache for the exact tree on main, so pulling an unchanged main branch\nand running pnpm check takes about a second.
Fast feedback keeps changes small. Fast checks catch the failures we know how to test. For\neverything else, we bias toward changes we can reverse. Feature flags make large changes reversible\nin production. Every feature flag records the date it entered the registry; after thirty days, an\nexperiment is marked stale unless it is explicitly permanent, a category reserved for entitlements\nand policy controls. The default assumption is ship it, judge it, then delete it or make it the\ndefault.
\nWe apply the same idea to schema changes: add a nullable column, backfill it, then enforce\nNOT NULL. We use two or three PRs even when the whole change would compile as one. Each step is\neasier to test, review, pause, and reverse.
The decomposition that makes a change safe is the same decomposition that makes it\nparallelizable. A change small enough to reason about is small enough to hand to an agent, review\nin minutes, and revert without ceremony. The careful version is the one that moves faster.
\nStatic checks work best when we already know how to name the failure. There is still a middle ground\nbetween “the compiler rejects it” and “a human happens to notice”: a change can compile, pass every\ntest, and still leave a stale assumption somewhere else in the repository. That is where automated\ncode review earns its keep.
\nGreptile reviews every Sonora pull request against the rest of the\nrepository. It reads AGENTS.md, architecture docs, and rules retained from previous reviews\ninstead of treating the diff as its whole world. When a new picker component called the React Router\nfetcher.submit from native buttons, it checked the implementation against the form-submission\nrules in AGENTS.md and caught that duplicate submissions were not prevented. The next commit moved\nthose rows to our shared SubmitButton with an explicit pending state. In another PR, it connected\nan additional database checkout to a previous, documented pool-exhaustion incident and told us to\nshare an existing transaction. Both are mistakes a line-by-line reading of the diff could easily\nmiss.
It also gets things wrong. It once complained that 200ms and 300ms animation durations bypassed our\nmotion vocabulary when those were exactly the values the vocabulary prescribed. We replied, and it\nwithdrew the comment. Automated review is a second reader, not an oracle. A finding has to describe\na real failure mode well enough for us to verify it.
\nReview quality falls when a PR bundles unrelated work. Keeping each change cohesive gives Greptile,\nand the human after it, less irrelevant context to sort through.
\nA good automated-review finding should eventually make itself obsolete. If it catches the same class\nof mistake more than once, that is evidence to move the rule to the right on the ladder: from\nrepository guidance to a hook, lint rule, or type. Automated review is useful in the gap, while the\nrule still depends on context we have not yet learned how to encode.
\nEngineering discipline compounds when each failure changes the path of the next change. On August 3,\nroughly 9,500 ungrouped sibling jobs contended on one database row. They exhausted the statement\ntimeout, and their retained error text filled Valkey until workers could no\nlonger boot.
\nThe postmortem changed the system in several places. The fan-out path got a grouping primitive. The\nconcurrency behavior got an architecture doc. require-job-group-in-loop now rejects the pattern\nthat caused the incident, and its header comment records the date and consequence. The next engineer\nsees that history while writing the loop, not after opening another postmortem.
That is discipline made executable: the incident changed the queue primitive, the documentation, and\nthe set of programs the linter will accept. We paid for the lesson once. Not every failure deserves\na lint rule; the durable response may be a type, a test, a different queue topology, or a smaller\ndeployment. “Be more careful next time” is not durable.
\nThat is how my job has changed. The repository settles formatting, imports, and approved primitives\nbefore a PR reaches me, leaving review for the spec and intent. The more important question is why\nthe repository needed me to catch something.
\nSix merged PRs a day is not the target. It is a side effect of making confidence cheaper. The metric\nI care about is the time between “I know what I want” and “it is in production, and I am not\nnervous.”
\nThe Slop Era will reward the team with the best engineering discipline, not the best prompt. What’s\ngood for humans is good for machines: trustworthy evidence, explicit decisions, fast feedback,\nisolated work, and a codebase that remembers why. Machines do not need a separate discipline. They\nneed ours, made executable. Build the discipline into the system.
\nThanks to Gabriel Al-Harbi and Max Schwenk for providing feedback on drafts of this essay.
\n", "date_published": "2026-09-10T00:00:00.000Z", "id": "https://pau.fm/blog/2026/09/10/engineering-discipline-in-the-slop-era", "summary": "Coding agents produce more code than your team can safely absorb. The answer is not more careful engineers: it is engineering discipline made executable, for humans and machines.", "tags": [ "essay" ], "title": "Constraint over convention", "url": "https://pau.fm/blog/2026/09/10/engineering-discipline-in-the-slop-era" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Paying for Spotify subsidizes Europe for being awful at technology.
\n", "date_published": "2026-09-09T00:00:00.000Z", "id": "https://pau.fm/blog/2026/09/09/subsidizing-europe", "summary": "Paying for Spotify subsidizes Europe for being awful at technology.", "tags": [ "short" ], "title": "Paying for Spotify subsidizes Europe for being awful at technology.", "url": "https://pau.fm/blog/2026/09/09/subsidizing-europe" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "OpenAI’s Millennium Problem result demonstrates\nthat AI is advancing fastest in domains with strong validation. In math, a proposed result can be\nchecked, and formal proofs make that validation nearly perfect. The model can search an enormous\nspace of possible constructions, discard failures, and eventually produce something provably\ncorrect. The same pattern explains progress in coding (the Bun Rust rewrite), games (unambiguous win\nor loss), and other domains where there is a cheap, reliable signal for success.
\nBut validation is not the same thing as understanding. The actual result of Navier–Stokes is\neffectively inconsequential.1 We care because trying to answer the question might produce a\ntheory of why solutions behave as they do. Mathematics, like computing, advances by building\nabstractions that compress many particular observations into a smaller number of concepts: the right\ndefinition, invariant, equivalence, or structure suddenly makes a whole family of results\nintelligible.
\nThis is not what happened here. OpenAI spent an enormous amount on compute, reportedly millions,\npursuing a perfectly verifiable objective, and its model searched its way to a gigantic, bespoke\nproof without discovering much reusable conceptual structure at all. In fact, earlier work reduced\nthe search space enough to make the entire project tractable.2 The result is still\nknowledge—we know something we did not know before—but it may be a strange kind of knowledge:\nexpensive to produce, difficult to understand, and not obviously useful for making future problems\nsubstantially easier.
\nAI seems superhuman in domains with verifiers. It’s far from clear whether it can build useful\nabstractions where no such verifier exists. Human intellectual progress is not usually a sequence of\nisolated correct answers. We invent models that make the world simpler to reason about. If AI can\nreliably discover concepts and theories that reorganize entire fields, it will represent a much\ndeeper form of intelligence than producing arbitrarily difficult, formally validated results.
\nI don’t have code access yet. But I have reason to believe they’re on Ruby 1.9.3 and Rails 2.3.
\n", "date_published": "2026-09-03T00:00:00.000Z", "id": "https://pau.fm/blog/2026/09/03/ruby-1-9-3", "summary": "I don’t have code access yet. But I have reason to believe they’re on Ruby 1.9.3 and Rails 2.3.", "tags": [ "short" ], "title": "I don’t have code access yet.", "url": "https://pau.fm/blog/2026/09/03/ruby-1-9-3" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "I asked Claude to do something and it produced a twelve-week plan. I asked again later. Two and a\nhalf to three and a half hours.
\n", "date_published": "2026-08-28T00:00:00.000Z", "id": "https://pau.fm/blog/2026/08/28/claude-estimates", "summary": "I asked Claude to do something and it produced a twelve-week plan. I asked again later. Two and a half to three and a half hours.", "tags": [ "short" ], "title": "I asked Claude to do something and it produced a twelve-week plan.", "url": "https://pau.fm/blog/2026/08/28/claude-estimates" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Our new quality person believes quality is everyone’s responsibility. I, too, believe that my job is\neveryone else’s responsibility.
\n", "date_published": "2026-08-21T00:00:00.000Z", "id": "https://pau.fm/blog/2026/08/21/quality-is-everyones-responsibility", "summary": "Our new quality person believes quality is everyone’s responsibility. I, too, believe that my job is everyone else’s responsibility.", "tags": [ "short" ], "title": "Our new quality person believes quality is everyone’s responsibility.", "url": "https://pau.fm/blog/2026/08/21/quality-is-everyones-responsibility" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Engineers at Percy got a rubber stamp for their one-year anniversary gift. Perfect.
\n", "date_published": "2026-08-15T00:00:00.000Z", "id": "https://pau.fm/blog/2026/08/15/engineer-anniversary-gift", "summary": "Engineers at Percy got a rubber stamp for their one-year anniversary gift. Perfect.", "tags": [ "short" ], "title": "Engineers at Percy got a rubber stamp for their one-year anniversary gift.", "url": "https://pau.fm/blog/2026/08/15/engineer-anniversary-gift" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "If you ever used data structures and algorithms interviews to hire software engineers, your fraud is\nnow exposed.
\nDSA interviews were never a good proxy for engineering, and this was blindingly obvious to anyone\nwho had ever shipped software. They were a crutch: a way to avoid the hard work of judging whether a\nperson actually brought useful skills to a team. Google designed them for a specific problem—hiring\nengineers at enormous scale to work on enormous-scale problems. You copied the visible part, and\nLeetCode became a substitute for any critical thinking you might otherwise have had to do.
\nCandidates responded rationally, of course. They studied the test. An entire curriculum emerged\naround problems most engineers rarely encountered in actual work and now, increasingly, never will.\nSuccess reflected time, coaching, pedigree, and familiarity with the ritual at least as much as\nengineering ability.
\nThe fact that you could “study” for the interview should have made the farce obvious. Instead,\nprogrammers wrapped the whole thing in meritocratic language and enjoyed the smug satisfaction of\nadmitting only people willing and able to jump through their inane hoops into the little cabal.
\nHow many lines of code have you written in the past year? If it’s more than zero, ask yourself why.\nThe valuable work was already problem framing, systems understanding, judgment, verification, and\ntradeoffs. Now that is increasingly the whole job. Why are you hiring a human based on their ability\nto perform a task that machines have effectively solved?
\nIf you are still running DSA screens in 2026, you are admitting that you never had a serious theory\nof how to hire engineers in the first place.
\nDisclaimer: as a hiring manager, I have never once given a candidate a DSA interview, because I\nalways thought they were incredibly stupid. I was right all along and now there is incontrovertible\nproof.
\n", "date_published": "2026-08-14T00:00:00.000Z", "id": "https://pau.fm/blog/2026/08/14/if-you-ever-used-dsa-interviews-your-fraud-is-now-exposed", "summary": "DSA interviews replaced judgment with ritual. Now that machines have solved the ritual, companies still using it are exposing that they never knew how to hire engineers.", "tags": [ "essay" ], "title": "If you ever used DSA interviews, your fraud is now exposed", "url": "https://pau.fm/blog/2026/08/14/if-you-ever-used-dsa-interviews-your-fraud-is-now-exposed" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Two tech workers live together long enough and their sprints start to synchronize.
\n", "date_published": "2026-08-08T00:00:00.000Z", "id": "https://pau.fm/blog/2026/08/08/sprints-synchronize", "summary": "Two tech workers live together long enough and their sprints start to synchronize.", "tags": [ "short" ], "title": "Two tech workers live together long enough and their sprints start to…", "url": "https://pau.fm/blog/2026/08/08/sprints-synchronize" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "I like to imagine these huts are New York’s solution to the housing crisis.
\n![\"Two](\"https://pau.fm/images/blog/new-york-housing-solution.webp\")
At some point, “tech podcast” came to mean “Android phone show.” Specifically, shitty Android phones\nyou’ll never buy.
\n", "date_published": "2026-07-26T00:00:00.000Z", "id": "https://pau.fm/blog/2026/07/26/tech-podcasts", "summary": "At some point, “tech podcast” came to mean “Android phone show.” Specifically, shitty Android phones you’ll never buy.", "tags": [ "short" ], "title": "At some point, “tech podcast” came to mean “Android phone show.” Specifically…", "url": "https://pau.fm/blog/2026/07/26/tech-podcasts" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Imagine if engineers pretended to be salespeople. They would write random sales pitches they stole\nfrom SEO blogspam, insist they be emailed to customers, then hold a mandatory sales hackathon twice\na year.
\n", "date_published": "2026-07-20T00:00:00.000Z", "id": "https://pau.fm/blog/2026/07/20/mandatory-sales-hackathon", "summary": "Imagine if engineers pretended to be salespeople. They would write random sales pitches they stole from SEO blogspam, insist they be emailed to customers, then hold a mandatory sales hackathon twice a year.", "tags": [ "short" ], "title": "Imagine if engineers pretended to be salespeople.", "url": "https://pau.fm/blog/2026/07/20/mandatory-sales-hackathon" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Python has load-bearing whitespace.
\n", "date_published": "2026-07-13T00:00:00.000Z", "id": "https://pau.fm/blog/2026/07/13/load-bearing-whitespace", "summary": "Python has load-bearing whitespace.", "tags": [ "short" ], "title": "Python has load-bearing whitespace.", "url": "https://pau.fm/blog/2026/07/13/load-bearing-whitespace" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Love hack weeks. Very inspiring to half-ass something you know will get thrown away.
\n", "date_published": "2026-07-07T00:00:00.000Z", "id": "https://pau.fm/blog/2026/07/07/hack-weeks", "summary": "Love hack weeks. Very inspiring to half-ass something you know will get thrown away.", "tags": [ "short" ], "title": "Love hack weeks.", "url": "https://pau.fm/blog/2026/07/07/hack-weeks" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "The received wisdom among enlightened software engineers is that lines of code is a terrible measure\nof engineering productivity. Good engineers produce less code, not more: they delete things, find\nabstractions, avoid unnecessary systems, and spend large amounts of time on work that is not visible\nin diffs. LoC mostly rewards visible activity rather than engineering value.
\nCoding agents change this in an uncomfortable way. The scarce resource is no longer typing code; it\nis specifying, directing, validating, and integrating work. If one engineer can use agents to ship\nfive integrations, migrate a subsystem, add tests, fix a dozen bugs, and clean up old infrastructure\nwhile another ships one feature, the first engineer probably did produce more. The fact that this\noutput materializes as a much larger quantity of code is no longer incidental. My view is that LoC\nis now a rough proxy for how much implementation surface an engineer can successfully orchestrate.
\nIt is probably still not a sufficient metric. Generated code can be redundant, brittle, or wrong,\nand the highest-leverage work still happens one level up: choosing the right architecture, defining\nboundaries, deciding what not to build, and determining whether any of this creates business value.\nBut I think that there is now substantial signal where previously there was not. In an agentic\nengineering environment, once quality and system-level outcomes are held constant, “how much code\ndid this person ship?” is suddenly a much more reasonable question.
\n", "date_published": "2026-07-06T00:00:00.000Z", "id": "https://pau.fm/blog/2026/07/06/lines-of-code-means-something-now", "summary": "When coding agents make typing cheap, code volume becomes a rough measure of how much implementation work an engineer can successfully orchestrate.", "tags": [ "essay" ], "title": "Lines of code means something now", "url": "https://pau.fm/blog/2026/07/06/lines-of-code-means-something-now" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Claude gave me a four-week implementation plan. I knocked it out in two days.
\n", "date_published": "2026-06-30T00:00:00.000Z", "id": "https://pau.fm/blog/2026/06/30/four-week-implementation-plan", "summary": "Claude gave me a four-week implementation plan. I knocked it out in two days.", "tags": [ "short" ], "title": "Claude gave me a four-week implementation plan.", "url": "https://pau.fm/blog/2026/06/30/four-week-implementation-plan" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "I found a venture capitalist with his SAT score on his LinkedIn profile.
\n", "date_published": "2026-06-24T00:00:00.000Z", "id": "https://pau.fm/blog/2026/06/24/sat-score-on-linkedin", "summary": "I found a venture capitalist with his SAT score on his LinkedIn profile.", "tags": [ "short" ], "title": "I found a venture capitalist with his SAT score on his LinkedIn profile.", "url": "https://pau.fm/blog/2026/06/24/sat-score-on-linkedin" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "I asked Google to set a two-minute, thirty-second timer. “Okay, I’ve started a two-minute timer\ncalled ‘30 second.’”
\n", "date_published": "2026-06-17T00:00:00.000Z", "id": "https://pau.fm/blog/2026/06/17/google-timer", "summary": "I asked Google to set a two-minute, thirty-second timer. “Okay, I’ve started a two-minute timer called ‘30 second.’”", "tags": [ "short" ], "title": "I asked Google to set a two-minute, thirty-second timer.", "url": "https://pau.fm/blog/2026/06/17/google-timer" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "The owner of my neighborhood teriyaki restaurant is wearing a GitLab T-shirt. Invest.
\n", "date_published": "2026-06-11T00:00:00.000Z", "id": "https://pau.fm/blog/2026/06/11/gitlab-teriyaki", "summary": "The owner of my neighborhood teriyaki restaurant is wearing a GitLab T-shirt. Invest.", "tags": [ "short" ], "title": "The owner of my neighborhood teriyaki restaurant is wearing a GitLab T-shirt.", "url": "https://pau.fm/blog/2026/06/11/gitlab-teriyaki" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Most software has historically been a database with a user interface. The user does the actual work\n— researching, comparing, deciding, remembering — and the software records the output.
\nThe first generation of AI products mostly preserved this architecture and added a chat box. Instead\nof tracking wines, ask GPT which wine to buy. Instead of maintaining a travel spreadsheet, ask it\nwhere to stay. This is useful, but it is not much of a product idea.
\nClay is interesting because it suggests a different architecture. Airtable gives you rows and\ncolumns and lets you fill in the cells. Clay lets you describe what a column means and has an agent\nfill it in for every row. A task that previously required researching 500 companies, applying the\nsame fuzzy judgment 500 times, and manually recording 500 answers becomes a declarative operation:\ndefine the judgment once, then curate the results. The model is not bolted onto the database; it\nchanges the relationship between the user and the database. Rows are items, columns are jobs, and\ncells are work.
\nThis is roughly the architecture we are building at Sonora. Customer software traditionally stores\naccounts, tickets, calls, notes, product usage, and CRM fields, while humans are still responsible\nfor synthesizing all of it. Is this account actually at risk? Has this problem happened before? Did\nthe champion leave? Is this an escalation or just noise? Which customers are asking for the same\nthing?
\nThose are repeated judgments over a set of customers. Sonora turns them into work the system can\nperform continuously across the customer base, using the underlying calls, tickets, email, CRM, and\nproduct data as its substrate. The user defines what matters, corrects the system when necessary,\nand increasingly curates the output instead of manually producing it.
\nWe celebrated Sonora reaching general availability tonight. A GA party is a chance to stop long\nenough to notice what the team has built, and what we celebrated was not a database with a chatbot\nattached. It was an engine that can do this work across every customer, continuously. There is much\nmore to build, but that shift now feels real.
\nThe interesting transition in AI software is not database → chatbot. It is database → engine.
\nSoftware used to store the output of human judgment. Increasingly, it can store the method.
\n", "date_published": "2026-06-10T00:00:00.000Z", "id": "https://pau.fm/blog/2026/06/10/the-clay-theorem", "summary": "The interesting transition in AI software is not database to chatbot. It is database to engine: software that stores the method of human judgment and performs it continuously.", "tags": [ "essay" ], "title": "The Clay Theorem", "url": "https://pau.fm/blog/2026/06/10/the-clay-theorem" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "I would describe Rippling’s aesthetic as “boomer chain letter.”
\n![\"A](\"https://pau.fm/images/blog/rippling-boomer-chain-letter.webp\")
Crypto is the Agile of real life. Fake work invented to enrich a sleazy grifter class.
\n", "date_published": "2026-05-28T00:00:00.000Z", "id": "https://pau.fm/blog/2026/05/28/crypto-is-the-agile-of-real-life", "summary": "Crypto is the Agile of real life. Fake work invented to enrich a sleazy grifter class.", "tags": [ "short" ], "title": "Crypto is the Agile of real life.", "url": "https://pau.fm/blog/2026/05/28/crypto-is-the-agile-of-real-life" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "I love the term “pre-owned.” Like somebody already did the work for you. What a relief! It’s\npre-owned, so I don’t have to worry about it.
\n", "date_published": "2026-05-22T00:00:00.000Z", "id": "https://pau.fm/blog/2026/05/22/pre-owned", "summary": "I love the term “pre-owned.” Like somebody already did the work for you. What a relief! It’s pre-owned, so I don’t have to worry about it.", "tags": [ "short" ], "title": "I love the term “pre-owned.” Like somebody already did the work for you.", "url": "https://pau.fm/blog/2026/05/22/pre-owned" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "On a long enough timeline, all internet banter is meta-banter.
\n", "date_published": "2026-05-15T00:00:00.000Z", "id": "https://pau.fm/blog/2026/05/15/internet-meta-banter", "summary": "On a long enough timeline, all internet banter is meta-banter.", "tags": [ "short" ], "title": "On a long enough timeline, all internet banter is meta-banter.", "url": "https://pau.fm/blog/2026/05/15/internet-meta-banter" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "MacRumors is stepping in to help people who don’t know when fall is.
\n![\"MacRumors](\"https://pau.fm/images/blog/macrumors-explains-fall.webp\")
I install really basic shit through Homebrew. Then one day I discover I have 248 packages. Love to\nupgrade aws-sdk-cpp.
Losing three percent every day has an upside. The absolute value keeps getting smaller.
\n", "date_published": "2026-04-26T00:00:00.000Z", "id": "https://pau.fm/blog/2026/04/26/the-good-news-about-a-three-percent-drop", "summary": "Losing three percent every day has an upside. The absolute value keeps getting smaller.", "tags": [ "short" ], "title": "Losing three percent every day has an upside.", "url": "https://pau.fm/blog/2026/04/26/the-good-news-about-a-three-percent-drop" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Whenever literally anything happens in the world, I wait for Slack. I’m not okay until I see some VP\npost “it’s okay to take time for yourself.”
\n", "date_published": "2026-04-19T00:00:00.000Z", "id": "https://pau.fm/blog/2026/04/19/take-time-for-yourself", "summary": "Whenever literally anything happens in the world, I wait for Slack. I’m not okay until I see some VP post “it’s okay to take time for yourself.”", "tags": [ "short" ], "title": "Whenever literally anything happens in the world, I wait for Slack.", "url": "https://pau.fm/blog/2026/04/19/take-time-for-yourself" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Hate your career long enough and AI displacement starts to sound pleasant.
\n", "date_published": "2026-04-13T00:00:00.000Z", "id": "https://pau.fm/blog/2026/04/13/quietly-hated-your-career", "summary": "Hate your career long enough and AI displacement starts to sound pleasant.", "tags": [ "short" ], "title": "Hate your career long enough and AI displacement starts to sound pleasant.", "url": "https://pau.fm/blog/2026/04/13/quietly-hated-your-career" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Tradeoffs are real. This is an obvious statement, which makes it strange how much political rhetoric\nis organized around denying it.
\nPolitical scientists usually define populism as a conflict between “the pure people” and “the\ncorrupt elite,” while technocracy claims authority through expertise and problem-solving. But the\nimportant policy consequence is simpler: once every problem has a villain, every constraint starts\nlooking like sabotage.\n(Mudde,\nCaramani)
\nOn the left, corporate power and the rich are why we cannot have generous public services, high\nwages, cheap housing, and cheap energy all at once. On the right, elites, immigrants, bureaucrats,\nand the deep state are why we cannot have low taxes, secure borders, strong communities, cheap\nhousing, and a booming economy all at once. Different enemies, same promise: if the right people\nwere in charge, nothing would have to give.
\nSometimes the villains are real. They still do not repeal budget constraints, supply constraints, or\nsecond-order effects. Scarcity can be distributed unfairly without being invented by the people who\nbenefit from that distribution.
\nPolicy is where denying this gets expensive.
\nIn each case, both things are true. Which matters more is a values question. Pretending one of them\nis not happening is not conviction. It is refusing to do the arithmetic.
\nA tradeoff is not an argument against a policy. It is the argument the policy has to answer.
\nBy a tradeoff sensibility, I do not mean centrism or splitting the difference. Sometimes the right\nanswer is to pay the cost. Sometimes it is to stop paying it. The discipline is to count the cost\nbefore announcing that it is free.
\nThe obvious objection is correct: “it’s complicated” is also the house style of everyone defending a\nstatus quo that suits them. But there is a tell. Deflection invokes complexity and stops. Analysis\nnames the assumptions, the distributional effects, and the evidence that would change the\nconclusion. Nobody hiding behind complexity volunteers to go through the elasticities.
\nThe fiscal debates of 2009 and 2021 show the risks in opposite directions. In early 2009,\ncritics warned\nthat the proposed stimulus might be too weak for the size of the recession. In early 2021,\neconomic analyses\nprojected that the American Rescue Plan could push output above its pre-pandemic potential; San\nFrancisco Fed researchers later\nestimated\nthat it could add about 0.3 percentage points to annual inflation through 2022. Subsequent\nresearch\nattributed the inflation surge to both strong demand and supply disruptions, with their relative\nimportance changing over time.
\nYou can dispute the estimates. That is the point: the dispute is stated in terms that evidence can\nresolve. Output gaps. Multipliers. Supply constraints. Inflation. Put numbers on them and let\nreality grade the test.
\nThe real advantage of a tradeoff sensibility is not that it always gets the answer right. It is that\nwhen it gets the answer wrong, the assumptions are visible, the miss has a size, and the model can\nbe updated.
\nThe anti-tradeoff alternative is emotionally easier. When reality fails to deliver every promised\ngood at once, find another villain.
\nTradeoffs are real. Scarcity is not a conspiracy. A politics that will not say who pays is not\noffering abundance. It is hiding the bill.
\n", "date_published": "2026-04-11T00:00:00.000Z", "id": "https://pau.fm/blog/2026/04/11/tradeoffs-are-real", "summary": "Political rhetoric promises abundance by hiding the bill. A serious policy argument names the benefits, the costs, and who gets each.", "tags": [ "essay" ], "title": "Tradeoffs are real", "url": "https://pau.fm/blog/2026/04/11/tradeoffs-are-real" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "Americans for Common Cents\nwas funded by the zinc lobby.\nOf course it was.
\n", "date_published": "2026-04-06T00:00:00.000Z", "id": "https://pau.fm/blog/2026/04/06/common-cents", "summary": "Americans for Common Cents was funded by the zinc lobby. Of course it was.", "tags": [ "short" ], "title": "Americans for Common Cents was funded by the zinc lobby.", "url": "https://pau.fm/blog/2026/04/06/common-cents" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "WeWork replaced its in-app snack-buying software with a generic Square terminal. It was a hundred\ntimes better. This is why you let technology companies make the software.
\n", "date_published": "2026-03-30T00:00:00.000Z", "id": "https://pau.fm/blog/2026/03/30/wework-snack-terminal", "summary": "WeWork replaced its in-app snack-buying software with a generic Square terminal. It was a hundred times better. This is why you let technology companies make the software.", "tags": [ "short" ], "title": "WeWork replaced its in-app snack-buying software with a generic Square terminal.", "url": "https://pau.fm/blog/2026/03/30/wework-snack-terminal" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "It’s funny when DJs turn every knob while the music is clearly unaffected.
\n", "date_published": "2026-03-24T00:00:00.000Z", "id": "https://pau.fm/blog/2026/03/24/dj-knobs", "summary": "It’s funny when DJs turn every knob while the music is clearly unaffected.", "tags": [ "short" ], "title": "It’s funny when DJs turn every knob while the music is clearly unaffected.", "url": "https://pau.fm/blog/2026/03/24/dj-knobs" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "I’m so market-pilled I don’t think it’s possible to be overpaid. You both agreed to the salary.
\n", "date_published": "2026-03-17T00:00:00.000Z", "id": "https://pau.fm/blog/2026/03/17/marketpilled", "summary": "I’m so market-pilled I don’t think it’s possible to be overpaid. You both agreed to the salary.", "tags": [ "short" ], "title": "I’m so market-pilled I don’t think it’s possible to be overpaid.", "url": "https://pau.fm/blog/2026/03/17/marketpilled" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "htmx has a useful idea called\n“locality of behavior”: the behavior of a piece of\ncode should be obvious from looking at that piece of code. A button that says hx-get=\"/clicked\"\ntells you what clicking it does. You do not need to find the event listener, trace a dispatch into a\nstore, inspect some middleware, and discover that a plugin registered three directories away is what\nactually makes the request.
This is usually framed as a principle for humans. Local behavior is easier to understand because\nless of the program has to fit in your head at once. But coding agents make the idea more\ninteresting, not less. An agent does not begin a task with a mature mental model of the repository.\nIt constructs one by searching, opening files, and deciding which clues deserve another search.\nEvery jump is both a context cost and another chance to miss the mechanism entirely.
\nSeparation of concerns is often implemented as separation by technical category: components over\nhere, state over there, network requests in a service, validation in a schema folder, and side\neffects in middleware. Each directory looks tidy while a single product behavior is smeared across\nall of them. The architecture has separated the code without separating the concern. A concern is\nusually closer to “cancel a subscription” than to “all the functions which issue HTTP requests.”
\nLocality does not require inlining every implementation. The htmx essay makes the useful distinction\nbetween inlining behavior and surfacing its invocation. A function can hide complicated machinery\nwhile its call site still makes the dependency obvious. The same is true of authorization, database\naccess, or a background job: centralize the policy, but make its participation visible where the\nbehavior is defined. Abstraction should hide machinery, not causality.
\nAgents sharpen the economics of that distinction because context is finite. Anthropic describes\neffective context engineering as finding the\nsmallest set of high-signal tokens\nthat produces the desired result. A codebase is therefore not just a program; it is a context\nretrieval system. Co-located tests, nearby comments, explicit dependencies, and feature-oriented\nfolders help an agent retrieve the right evidence cheaply. Registries, implicit conventions, and\nspooky action at a distance force it to reconstruct an invisible graph before it can safely change a\nline.
\nThere are still good reasons to put some things far away. A security invariant should not be copied\ninto every endpoint merely to improve locality; it should be encoded once in a boundary, type, or\ncheck that cannot be bypassed. Shared implementation belongs behind a stable interface. The test is\nnot whether all relevant code occupies one file, but whether the local code reveals which larger\nrules govern it and gives the reader an obvious path to them.
\nSeparation of concerns remains a means, not a goal. The more useful default for a world of coding\nagents is locality of context: code that changes together should be understandable together.\nEvery architectural hop consumes attention; good architecture compresses the explanation of a change\ninto the same neighborhood as the change itself.
\n", "date_published": "2026-03-16T00:00:00.000Z", "id": "https://pau.fm/blog/2026/03/16/locality-of-context-over-separation-of-concerns", "summary": "Coding agents strengthen the case for locality: organize code so the context needed to change it is nearby, rather than scattered across architectural layers.", "tags": [ "essay" ], "title": "Locality of context over separation of concerns", "url": "https://pau.fm/blog/2026/03/16/locality-of-context-over-separation-of-concerns" }, { "authors": [ { "name": "Pau Friedman", "url": "https://pau.fm/" } ], "content_html": "I came of age when blogging was cool. I always wanted to blog consistently, but I squarely fit into\nthe wide swathe of the curve of people that habitually start and abandon blogs every few years.
\nBut these days I’m finding myself with quite a lot to say: software development is evolving rapidly\nbecause of AI, and I want to catalog that shift as it happens. What gets easier and what gets\nharder? What are the limits of the tools, and which of those limits will actually stick around? What\ndoes the work even look like now, or in a decade?
\nExpect essays, notes, links, and occasional updates drawn mostly from my work. There will be lots of\nopinions and maybe some dog photos.
\nThanks for reading, and enjoy your visit to my wobsite.
\n", "date_published": "2026-03-15T00:00:00.000Z", "id": "https://pau.fm/blog/2026/03/15/hello", "summary": "Notes on how AI is changing software development, plus the occasional dog photo.", "tags": [ "essay" ], "title": "Hello.", "url": "https://pau.fm/blog/2026/03/15/hello" } ], "language": "en-US", "title": "Pau Friedman · pau.fm", "version": "https://jsonfeed.org/version/1.1" }