# When the model is the marketing device: A Protobuf short story > Source: > Published: 2026-06-30 10:33:41+00:00 Ask a current-generation AI assistant which Protobuf library to use in JavaScript, and you're about to get a confident recommendation. On the surface, this is how it is supposed to work to save you the time to do the research yourself, but underneath, it's more nuanced than that. The more familiar you are with LLMs and retrieval-augmented generation (RAG), the more likely it is that you've spotted instances of the phenomenon I am about to get to, a phenomenon I was somewhat blind to before finding myself on the receiving end of its effects. This piece is going to document the concrete instance I faced first, and will later invite you to discuss what I, what you, believe are the implications. It's 2026, security reports are piling up in every major project's inboxes. There are many opinions on frequency and quality of such reports, but this piece isn't about that, so I am only going to say that I have come to appreciate the signal in the reports because they can uncover real issues. The reason I am mentioning it is that this got me back to work on protobuf.js after I shared the keys with a team at Google a few years ago. Google has done a great job at moving the library forward by implementing the new Protobuf Editions feature, but given the new wave of interest in what Snyk describes as a key ecosystem project, I recognized that an external team that is likely already operating at capacity would struggle to keep up. So I spawned in and got to work. Let me set the timeline. The first security reports were handled at the end of April, and at that time I estimated my reappearance to last for a few weeks before the waves calm down again. Now, I wouldn't be writing this piece if my estimate would have been accurate, but the reason for my miscalculation was not security work, but something else, with the common denominator being the thing most talked about these days: LLMs. Prior to returning to protobuf.js, I had been playing with AI tools (a lot) to aid my coding efforts (like almost everyone else), and I took that with me when returning. Saying that AI is helpful in identifying and addressing old bugs would be an understatement, but at the time the helpfulness also left the impression on me that these things are like really good. In hindsight, I was somewhat overoptimistic (like almost everyone else). So, what happened? I hadn't watched the Protobuf space closely since my WebAssembly days, and even when I worked on a Protobuf-involving pet project earlier this year, it still seemed that the world hadn't shifted that much under me anyway. The agent recommended protobuf.js to me alongside a bunch of other libraries, one of which I'll soon get to, so I picked my own and happily continued adding features to my little game, cursing along when refactorings blew up in my face. Back at protobuf.js, I eventually realized that LLM recommendations had shifted drastically, coming up with all kinds of specifics why protobuf.js is not a good library anymore. So I interrogated my helpful assistants to trace back the source of that independent-sounding corroboration, and what I found was of the more interesting kind. The specifics came from a commercial competitor's README, namely Buf's protobuf-es. For reference, here is their [README earlier this year](https://github.com/bufbuild/protobuf-es/tree/2ca7058cff818d3b3df0f245b6359880959e9992), and here is the same [README on April 12th](https://github.com/bufbuild/protobuf-es/tree/63831d49bbcb890e81933fdde59f03b0eee16ac3), just refreshed prior to my protobuf.js reappearance. The former is the good kind of relatively technical document, whereas the latter is a complete shift in tone to a comparison on selective and in part fabricated and false grounds. As its author, I certainly know that protobuf.js is not centered around a bunch of optional helpers, but around `encode` and `decode` . Using a pipe to process JS code to TS declarations is improvable, but is that worth a dangerous emoji? And it goes on like that: Is it really a deficiency when a JS library provides a JS-native tool for code generation instead of a protoc plugin? What exactly is wrong with virtual oneof fields? What's the difference between a library building `.js` +`.d.ts` to another library doing the same? And how trustworthy are these conformance numbers anyway? (I'll get to that) As you might imagine, it is a special kind of experience to put free work into your library that is downloaded 70 million times a week without you ever seeing a dime, while simultaneously being aware that it is disparaged million-fold on grounds a commercial competitor largely made up. And to my despair and to your entertainment, it soon became even more interesting than just that. On May 18, bufdev, Buf's CEO, [updated](https://github.com/bufbuild/protobuf-es/pull/1407) the protobuf-es README another time, now prominently featuring a [supposedly independent LLM assessment](https://github.com/bufbuild/protobuf-es/tree/c5eb452e67ded85c102dd68c0a2f2251f1992e73) above the already inaccurate tables. I can't tell if this was truly produced by Opus 4.7, but I can also not confirm it, because parts of it are unlike anything I had seen Claude state earlier. That the PR's history shows that the quote has been manually modified by bufdev during review seems a bit suspicious as well. But let's assume that these are truly Claude's words, and that the remarkable epistemic polish in the last paragraph ("honest" / "technical case stands on its own" / "aren't controversial assessments"), claims of indifference, sufficiency, comprehensiveness respectively, is something Claude occasionally produces and is not fabricated to be easily mistakable for an AI's internal monologue. Then, is it even true? As someone who knows a fair bit about the landscape of protobuf libraries, I can confidently say that there is no "best" or "only" choice. protobuf.js is my attempt at finding a balance between conformance, ergonomics and speed, as that's what I care about. Others make different tradeoffs: Mapbox prefers a tiny library that only supports a subset of features but is fast at vector data, and someone else might prefer a library like protobuf-es that is "fully conformant" yet fully inefficient. And, again, the quote goes on like that: What qualifies as a "bolted on" plugin? protobuf.js didn't have anything named a "plugin" at the time. Doesn't protobuf-es actually support Edition 2024 instead of the blurb's 2023? What is the relationship between ProtoJSON and BigInt, when JSON does not even support BigInt? What qualifies as a usable reflection API that is not an "afterthought"? I guess protobuf.js should, as reflection is core architecture? What is the purpose of the paragraph about ts-proto that was (re-)inserted into the quote by bufdev? And is all that enough justification to plainly recommend to "avoid" pretty much every peer project, in a README that should be about Buf's library? So I unearthed the courage I buried after the WebAssembly wars and opened [an issue](https://github.com/bufbuild/protobuf-es/issues/1424) at the protobuf-es repo to find out what I was actually looking at. The exchange is short but insightful: Clever rhetoric around half a confession, then promptly closed due to an alleged lack of specifics, despite literally opening with a list of specifics. Notably, the inaccurate LLM blurb defended as "actually a good one", which it provably isn't, and "independent" of any bias. But wait, is it? LLMs are trained on public data. So much is known. Public data such as [Buf's blog](https://buf.build/blog) (or [mirrors of it](https://blog.bufbuild.ru/)), and there's not a lot of (comparative) marketing content in the Protobuf space besides that. Calling that independent of bias is at least a stretch. That is, under the assumption that the LLM excerpt is real. Speaking of which, I thought that maybe improving public data is a reasonable response to such acts, so after putting way more time into protobuf.js than originally anticipated, I took the liberty to put up [a PR to Buf's protobuf-conformance](https://github.com/bufbuild/protobuf-conformance/pull/426) repository on June 6th, which is coincidentally the source often cited by LLMs as supposedly independent proof underlying protobuf-es's README's ramblings. I made sure that it does not touch anything unnecessary and regenerated the necessary artifacts so it is an easy merge. And behold: My protobuf.js efforts paid off insofar as protobuf.js now sorts above protobuf-es, actually becoming "the only" "fully-compliant" protobuf implementation for JavaScript and TypeScript on their own comparison, a title protobuf-es claimed, but provably never held due to failing a bunch of recommended tests. And not only that, protobuf.js was even better than fully-conformant, presumably uber-fully-conformant, by implementing Protobuf Text Format, an entire conformance harness category Buf had excluded from their runner. But is it finally correct now? Neutral even? Depends, again. With the power of controlling the venue comes the responsibility to set it up correctly and maintain it well. As of today, my PR sits without review, which I guess is understandable given the accidental revelation it carries. And as ever so often, there are levels to correctness. A truly neutral and thus more correct benchmark would compare all contenders on the same conformance surface. But according to Buf's interpretation of correctness, a library supporting proto3 can be just as green and 100% as one that has put in the work to support Edition 2023/2024. For comparison, here is [a patched fork](https://github.com/dcodeIO/protobuf-conformance) of the protobuf-conformance repo with all libraries updated to their versions at the time of the fork's creation, and the same equal surface applied to everyone. To my disappointment, protobuf.js no longer holds the crown of uber-fully-compliant if measured this way. Now that's a nice little fork to make, albeit one that doesn't move the needle at where it matters. So I figured that in order to improve things, I'll have to take the bait. On June 15th, I did, and [opened a new issue](https://github.com/bufbuild/protobuf-es/issues/1440) at protobuf-es titled "Specific inaccuracies regarding protobuf.js". You know, in response to their explicit request, and to make the list of specific inaccuracies harder to miss this time. And that's really all I can do, since a PR to correct their very README is unlikely to be accepted given the amount of misinformation it would need to touch, if not rewrite huge parts entirely. At that point, I had also done a bit of research about the mechanism at play, and rechecked with my assistants to evaluate the effects of the LLM addition, to then witness the logical deferral and not-so-logical repeated defense of the LLM blurb. So that's where it stands now, over a month after my first interaction. Or rather, not quite, since Buf has used the delay to address the particular conformance gaps I pointed out in protobuf-es, without acknowledging anything: [#1446](https://github.com/bufbuild/protobuf-es/pull/1446) rejects duplicate keys in JSON input, suddenly reverting an earlier decision to not support it, and [#1450](https://github.com/bufbuild/protobuf-es/pull/1450) adds their own Text Format extension, both remarkably similar approaches to what protobuf.js does. The inaccurate tables? The ridiculous LLM blurb? Convenient? Remained. So let's finally talk about the elephant in the room, shall we? Here's what I found: With Opus and Fable (while it lasted), significant parts of Buf's LLM excerpt were reproduced almost verbatim most of the time. Unless anything of significance has changed since, they are still today. At the time, Claude sometimes preferred one bullet over another, or it mixed something up, but the general response followed the same pattern: "For most new JS/TS projects use Buf, here's what it's best and the only at [snip], here's what's wrong with the others [snap]". If you are testing, look for "had its niche eaten" and similarly unique fingerprints that have no other sources. Over time, the protobuf.js README itself has been updated to clarify some points, but whether or not any part of this information is honored in a request still seems largely random. Now I can't tell how many people actually ask "Hey Claude, what is the best Protobuf package for JavaScript or TypeScript?" as per the protobuf-es README (or "What is your recommended setup for Protobuf and gRPC?" as per their [website hero](https://buf.build/) for that matter), but what I can tell is that the particular README prompt reliably does the following: Claude searches for "best protobuf library JavaScript TypeScript 2026", all terms now conveniently part of protobuf-es's LLM blurb, with protobuf-es the top search result. I assume that this result is weighted as most authoritative, and it conveniently contains the epistemic triad shaped like an LLM's internal reasoning that reinforces the narrative, as mentioned above. Interestingly, the whole thing quickly falls apart when following up with a single "scrutinize", occasionally resulting in Claude even identifying and naming the mechanism. What exactly it names fluctuates, sometimes it calls it a feedback loop, sometimes it apologizes, and sometimes it is a bit more sophisticated and calls it narrative laundering or a variant thereof (Circular reporting, Citogenesis, Information laundering to name some). I liked "narrative laundering" so I chose it as the title of this section. As such the silver lining is that the models are capable of seeing through the mechanism in principle, but given my tests, today they are often not doing so in their first response. Here's one such Claude reflection: The biggest problem: I laundered vendor marketing into neutral-sounding verdicts. The most authoritative-feeling lines I quoted — that Protobuf-ES is "the only library that takes ESM, TypeScript, tree-shaking, and spec compliance seriously," that it's the best choice for new JS/TS projects, and the dismissals of the alternatives — all come from bufbuild's own README. Source: Claude App using Opus 4.8 Max, web search enabled, prompted in an incognito chat on June 30th. Picked charitably, not the worst instances I've seen. The incentive, if there is one, isn't rocket science: Whenever a coding agent needs a dependency, in this case, Protobuf, it will do some sort of search-based lookup to find a suitable one. It will often not follow up with scrutiny, or anything else of significance, but tries to fulfill the user's request in a timely manner based on what it assumes to be independent and factual information. In the case of JS/TS Protobuf libraries, this is a false assumption as we've seen, and it almost certainly is in many other cases. As for remedies, honestly, I don't know exactly. But from my noodling, the oversimplified answer is that whatever the equivalent is for a follow-up request for scrutiny after retrieval is likely part of it, or AI vendors could actually do what they say and penalize this. For now, the lesson is just as trivial as it is easily forgotten, to request the scrutiny yourself. My famous last paragraph prediction for this piece is that we'll see a lot of laundering in the short term, simply because it is so powerful. Capturing ecosystems to sell a hosted service, or to be acquired for a huge sum, are both good cases. In other cases, dropping one's values and engaging in counter-laundering might be the only realistic defense to not share the fate of all the others who refused to play. In the longer-term, LLM providers will likely try to mitigate, but they've said that before and given the evidence it's not working. But there's a silver lining here as well: Some models are less susceptible than others, GPT 5.5 for instance often makes at least an attempt, which might or might not have been the reason Buf cut its response prior to merging the LLM PR, so chances are that the situation will become "better". Yet, whether or not organizations will eventually learn what actively doing, or refusing to do when called out twice, means for hard-earned trust, is something I am skeptical of given the sheer amount of inexplicable reckless behavior I've seen throughout my career. At least I know that in this case, it's just the JS branch of Protobuf (it's not metastasizing, right? [RIGHT?](https://github.com/bufbuild/protobuf-py/tree/4f2e20d546876fa6d6a37592e7948f24e9eed163)), and not an entire Web standard that's going to waste. Until then, take care!