Speaking during a London media and analyst briefing this week on the subject of developer trust, bonding and allegiance, Sanjay Sarathy, VP for self-service and developer experience at Cloudinary shared his thoughts on how to forge bonds with the software engineering community that not only last… but also result in a productive functional inter-relationship. But developers are sceptical beasts that are hard to win over, so do his arguments hold water? With a doubting eye and a raised eyebrow, Techzine tuned in.
Make trust your organisation’s watchword says Sarathy. Why? Because these days, trust is fragile. It’s become necessary to question and verify whether information that we read, hear and see is true and real. That also means that more than ever, trust is a valuable commodity.
A key benchmark, developer trust in AI
It’s true to say that trust can also be complex and nuanced. StackOverflow’s most recent survey suggested that, when it comes to AI, developers are among its most enthusiastic users. On the other hand, developers are highly critical thinkers and among the least likely to put blind faith in the output they get from AI. At the same time, they will actively invest the time to make it better.
“I see this dynamic at work every day. We started in 2012 as a developer-first company and were experimenting with and applying AI from the outset – long before the hype we know today set in. But there’s no room for complacency. In this brave, sceptical new world, you need to keep inviting and acting on developer input on everything from AI capabilities, use cases to solve, APIs and yes, pricing,” said Sarathy.
But failure to engage well and build trust won’t just disappoint community members, i.e. developers are a vocal, passionate bunch and are given to letting their pals and colleagues know you’ve let them down as well.
Sarathy offers some advice that stems from working with his own firm’s community for more than a decade.
Always offer genuinely useful free entry
He suggests that while freemium and ‘open source’ may be a useful marketing move for some software development teams, it can also be a mistake in the AI age, as it’s an incredible trust-building mechanism. When developers can experiment for free and still get real value and ask all the questions they want, they are far more likely to deepen their engagement over time and advocate for the platform when the project moves from PoC to production.
“Great informed support is about as important in building coder trust. From our very first days, we invested in technical support staffed by people who could genuinely speak techie language. At the end of the day, developers trust other developers (I will never forget one who muttered at a trade show that they were sick of speaking to the ‘colouring in department’ on stands), so peer-level support interaction builds confidence in a way no FAQ or at least first-gen chatbot ever could,” said Sarathy.
“For sure, now we offer multilingual AI-assisted documentation to make it fast to get immediate, contextual answers in a visitor’s own language, but we will never, ever sunset human support. If you leave a system builder dangling, you’ve not only failed your side of the trust contract, you’ve probably lost them for good to a rival,” he added.
Trust your AI buddy
We know that developers increasingly rely on AI to interpret APIs and generate code. As we all know, these tools are powerful but can hallucinate, mix up versions, or produce incorrect implementation patterns. When that happens, the developer often attributes the failure to tools, not the model, but teams need to make their codebase as AI-readable as possible.
Sarathy tells us to think about structuring SDKs and documentation so that they’re easier for models to interpret correctly, integrating directly with AI coding assistants and improving how our content is surfaced and versioned so that accurate information is more likely to be retrieved.
Seeing the AI as another developer is the key here.
Honesty is the best policy
“Developers are stressed that vibe coding is coming for them, so they are increasingly sensitive to the gap between what a supplier promises and what is delivered. That’s why it’s important to be explicit about what AI-assisted tools can and cannot do. Sometimes that means flagging their limitations and when human support is needed. We also believe in clear communication around data usage, model behaviour and product changes. A well-maintained changelog is not just documentation but essential respect for the people who are using your app, so keep your standards high,” stated Sarathy.
Dependability also helps with trust here.
Developers build careers on top of platform guarantees, so unexpected/random changes to your APIs, feature sets, SDKs, or behaviour must be handled with care. Backward compatibility, long deprecation windows, and clear migration paths are engineering guarantees of quality that really say ‘You can trust this maker at least.’
“When change is necessary and indeed advantageous for me as a solutions constructor, offer it with ways to make the transition as smooth as possible, if you can,” he advises.
Interestingly, concludes Sarathy, trust shares something in common with AI itself.
He says that, like AI, trust isn’t something you can just decide to bolt on when things aren’t going to plan. Trust needs to be part of a team’s foundation. Organisations will therefore need to build on it slowly with their developer community by delivering consistently, communicating honestly, seeking critical feedback and respecting contributors’ time and effort.
Trust him (he says) – it’s worth the effort.