Recap #
In the last post, I wrote that the next coding agent moat is trust. 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."
I've been thinking about what sits around that trust.
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.
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.
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.
The community should show the work #
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? That is the trust gap.
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.
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.
That kind of proof is much more useful than a polished demo.
A demo says, "Look what the agent can do." A community says, "Here is what people are actually letting it do."
Those are very different things.
Don't hide the failure modes #
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.
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.
This is where I think agent companies can build a lot of trust by being more honest than feels comfortable.
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. That does not weaken the product. It makes the promise believable.
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."
One sounds like a real workflow. The other sounds like a pitch deck.
The best community members might be skeptics #
This part is easy to get wrong.
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.
They are the ones who say things like:
- "This passed CI, but I wouldn't maintain it."
- "The fix works, but the abstraction is wrong."
- "It should have asked before changing this file."
- "The test is just testing the mock."
- "This is useful, but only for this class of issue."
That feedback is not anti-community. That is the community doing its job.
If you're building a coding agent, you probably want those people close. They are pointing directly at the trust gaps. 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.
Build rituals around safe delegation #
Most teams will not go from zero to "let the agent do anything."
Trust starts with small permissions.
First, let it investigate. Then let it suggest a patch. Then let it open a PR. Then, maybe, let it handle that class of work automatically.
That path needs rituals, and a good community can help create them:
- labels for agent-safe issues
- checklists for reviewing agent PRs
- playbooks for dependency upgrades
- examples of good repo instructions
- shared prompts for flaky test triage
- patterns for when the agent should stop and ask
- norms around small, reviewable PRs
- public examples of good agent work
This is not glamorous, but it is probably what adoption looks like.
Nobody wakes up and says, "I trust this autonomous AI engineer now." They say, "This is low risk enough. Let's try it here."
Then the boundary slowly moves.
Community is where taste gets built #
The hardest part of coding agents is not always correctness, it is taste. An evergreen read on this: Taste for Makers by Paul Graham.
Does the change belong in the repo? Did it name things the way the team names things? Did it avoid turning a small bug fix into a tiny architecture project? Did it delete dead code? Did it write tests that prove behavior, or just tests that make coverage go up?
Senior engineers are not only asking, "Does this pass?" They are asking, "Do I want to live with this code six months from now?"
Some of that can be built into the product, but a lot of it is learned socially.
Taste spreads through examples, critique, and shared norms. It spreads when maintainers explain why one PR was accepted and another was rejected. It spreads when people show the difference between a useful agent change and a clever-but-annoying one.
That is why the community around a coding agent matters. Not because community magically creates trust, but because it gives trust somewhere to accumulate.
The mistake is treating community as distribution only #
A lot of companies treat community like a launch channel.
Get people in a Slack. Post updates. Ask for feedback. Announce features. Maybe run office hours.
That is fine, but it undersells what community can do for this category.
For coding agents, community should not just create attention. It should create evidence. Evidence that the agent can handle specific workflows. Evidence that serious engineers are using it. Evidence that failures are understood. Evidence that the team is listening. Evidence that the product is getting better because of real usage, not just benchmark chasing.
That kind of community becomes part of the product's trust layer.
The bar #
I've started to enjoy adding "The bar" to my conversations, it really sets the tone on expecting a minimum quality output but I digress.
The next agent winners probably will not be the companies with the loudest communities. They will be the ones whose communities make adoption feel safer.
Where developers can see real work. Where failures are not hidden. Where skeptics are useful. Where people share small workflows that actually save time.
Where the promise is not "replace your engineers."
It is more like:
"Here are the kinds of work this agent can handle well. Here is how teams are using it. Here is where you should still be careful."
That is much less exciting than "autonomous AI developer." But it is much more believable.
And believable is what this category needs.
This is why I said it before, trust does not come from saying the agent is powerful. Trust comes from teams seeing enough proof to say:
"Yeah, let it handle that."