Coding agents need receipts, not fans} --> to load fonts from Google CDN<br>but if you want to switch font this is the easiest way<br>to check how your page will look with the new font.<br>-->

-->

Modes

Off

Snake mode

90s mode

Berlin mode

XP mode

Welcome to my homepage!!! Best viewed at 800x600 &middot; Under construction &middot; Sign my guestbook!!!<br>My Computer<br>Recycle Bin<br>Cool Stuff<br>UNDER CONSTRUCTION

Start

Turn off '90s mode'

S41 S42

My Homepage Internet Explorer My Documents Windows Media Player Outlook Express<br>start<br>Pranshu Khanna<br>Loading…<br>◄◄ ► ►►

Toggle dark mode Close mobile menu li]:p-0 px-6" data-astro-cid-6aabv5oc> Home<br>Blog<br>Work<br>Podcast<br>Consulting

blog-trust-infrastructure.txt - Notepad<br>_ □ ×

FileEditViewHelp

In this post<br>Share this post

Coding agents need receipts, not fans<br>Aug 18, 2026 Recap<br>In the last post, I wrote that the next coding agent moat is trust.<br>Not who writes code fastest. Not who has the cleanest demo. Which agent earns enough trust that a team eventually says, "Yeah, let it handle that."<br>I've been thinking about what sits around that trust.<br>Because it is not built only inside the product, especially in developer tools. If you're asking a team to let an agent touch real code, real issues, real CI failures, and real production workflows, you're not just selling software. You're asking for permission.<br>Developers do not give that permission because a homepage says "autonomous AI engineer." They give it after they've seen enough evidence that the thing behaves well under real conditions.<br>That's where community becomes interesting. Not community as "we launched a Discord" or "come hang out with other AI people." Community needs to be trust infrastructure.<br>The community should show the work<br>For coding agents, the output is not enough. A clean PR is nice, but it does not answer the questions engineers actually care about. Why did it make this change? What context did it read? What tests did it run? Did it follow the repo's patterns? Did it know when to stop? What did it get wrong? What did the human reviewer correct?<br>That is the trust gap.<br>The product can answer some of this with logs, traces, evals, and better UX. A community can answer it another way: by making real usage visible.<br>Show the good PRs. Show the rejected PRs. Show the weird abstraction someone had to clean up. Show the flaky test investigation that actually saved an engineer two hours. Show the dependency upgrade that was boring, scoped, tested, and merged.<br>That kind of proof is much more useful than a polished demo.<br>A demo says, "Look what the agent can do." A community says, "Here is what people are actually letting it do."<br>Those are very different things.<br>Don't hide the failure modes<br>A lot of AI products still market like the model never misses, which is definitely not true. If you have worked with any and every model in the last few years, you probably know and trust certain model with a specific problem. There are a devs I spoke to, who work on Codex writing a test and Fable explaining and sharing tips on improving it, it's just the level of trust they have on a model to perform consistently.<br>Developers know better. The useful question is not whether the agent fails. It will. The question is whether the failure is visible, recoverable, and bounded.<br>This is where I think agent companies can build a lot of trust by being more honest than feels comfortable.<br>If your agent is good at dependency bumps but bad at architecture refactors, say that. If it sometimes over-edits, say that. If it performs better in repos with strong tests, say that. If it should ask before touching auth code, say that too.<br>That does not weaken the product. It makes the promise believable.<br>A narrow, honest promise beats a magical one. "I let this handle our weekly dependency backlog" is a much stronger community story than "AI engineer for everything."<br>One sounds like a real workflow. The other sounds like a pitch deck.<br>The best community members might be skeptics<br>This part is easy to get wrong.<br>A community of trust cannot just be fans posting wins. For developer tools, especially AI developer tools, the skeptics are often the most valuable people in the room.<br>They are the ones who say things like:<br>"This passed CI, but I wouldn't maintain it."<br>"The fix works, but the abstraction is wrong."<br>"It should have asked before changing this file."<br>"The test is just testing the mock."<br>"This is useful, but only for this class of issue."<br>That feedback is not anti-community. That is the community doing its job.<br>If you're building a coding agent, you probably want those people close. They are pointing directly at the trust gaps.<br>The worst version of an AI community is a hype room. The best version is closer to a workshop: people comparing workflows, reviewing outputs, sharing boundaries, and building taste together.<br>Build rituals around safe delegation<br>Most teams will not go from zero to "let the agent do anything."<br>Trust starts with small...