“Fake it till you make it” does not work for Developer Tools

Dennis Pilarinos

October 6, 2025

One of the most interesting interaction patterns we’ve seen at Unblocked is that every single new user, without exception, starts in the same way.

The very first question they ask is never a real question, it is always something they already know the answer to.

I suspect this is because most engineers are cautious and somewhat skeptical by nature. They tend to be dubious of new tools and they’ve been burned before by products that overpromise and under deliver (especially given the hype around AI developer tooling).

So the first interaction with Unblocked is a test. They want to know right away whether this system is worth their time and asking a “known” question is the simplest way to do that.

References as a “Trust Signal”

Correspondingly in those early moments, users don’t just look at the answer itself, they want to see the proof.

Our metrics show us that early in the user adoption cycle, we see a high volume of clicks to the references Unblocked provides with its answers. Users are validating not just what the system says, but where it came from.

What’s fascinating is that this behavior changes fairly rapidly. After a few days of consistent use, those clicks drop off and users stop double-checking and start trusting Unblocked’s responses. The references are still there, but they become a safety net rather than a crutch.

This transition tells us the product has crossed an invisible line, moving from “tire kicking” to being relied upon.

You only get one shot

This behaviour highlights something critical about designing developer products like Unblocked. First impressions really count and there is a very small window to establish trust.

If we nail that very first answer, we’ve earned the right to keep going. We passed the “BS test” and the user starts to form a habit (which is another blog post into itself).

However, if the answer is off, incomplete, or confusing, we begin in an (almost insurmountable) deficit. It takes far more effort to recover from that failure than it does to get it right the first time.

For us, that means we can’t think of “trust” as a nice-to-have or something that accrues over months. The very first interaction sets the tone for everything that follows.

Trust is critical for developer adoption

This insight has shaped more than just how we think about references or answer quality. It’s changed how we think about onboarding, product messaging, and even our roadmap. Lose a developer’s trust early, and you won’t get the chance to show the more powerful features that come later.

When you only have one shot to make a first impression, the right product decision isn’t always the most complex or technically impressive one. Sometimes it’s the one that simply proves: you can trust this.