Bloop : AI code search, from six interviews to a shipped extension
- ROLE
- Senior UX Designer
- TEAM
- Two founders, engineering team, designer (me)
- COMPANY TYPE
- Startup, Y Combinator, Developer Tools
- YEAR
- 2022
- DELIVERABLES
- User research, Product Design, Onboarding
- MEDIUM
- Desktop app, VS Code extension, Web
TOOLS
- Figma
- React
- Tailwind
- VS Code extension
Bloop was AI-assisted code search for developers, built at a Y Combinator startup in 2022, before the category had a name. I ran the research and designed the product: six developer interviews, a competitive teardown of the incumbent, the search and result interface, and the onboarding.
EARLY USERS
120
Onboarded to the extension
ADOPTION
70%
Reached through interviews and rapid prototype iterations
QUERY TIME
−50%
Time to find a reference, against the previous flow
“Can't navigate the code well, only can search”
Sourcegraph owned code search and developers used it reluctantly. It was heavy, the onboarding was counter-intuitive, the licences were expensive, and it lived in a browser tab rather than where they worked.
The bet: put AI-assisted search across every repo in an organisation, inside the editor developers already had open.
2022, before the category existed
What six developers told me
Developer pain points
Interviews across July 2022 with engineers at Andela, Cloudflare and others, working in monorepos and microservice estates, using Sourcegraph, GitLab, IntelliJ and VS Code.
"Can’t navigate the code well, only can search."
"Sourcegraph feels heavy. GitHub is faster."
"I’d rather stay in the IDE and have the searches in there."
Competitor analysis
Sourcegraph was the incumbent and the benchmark. Almost every participant had used it, and almost every one of them had a complaint ready.
Gaps
How I ran it
I wrote the interview guide against two questions I did not want to ask. “What would you use this for?” produces a hypothesis, so instead I asked participants to recall how they had solved the problem the last time it happened. “Do you like this design?” produces politeness, so instead I gave them tasks and watched where they slowed down.
The questions that earned their place were narrow: why would you search for code, what goes wrong when you do, and do you ever look at who edited a line last.
A matching line is almost useless on its own
Every interview drifted past search and into comprehension. Who wrote this. When. Where else is this symbol referenced. What does the surrounding code assume. One participant put the deep version of it plainly: institutional knowledge is lost, and he wanted code histories with graphs and dates to get it back. Search was the surface. Context was the job.
Evaluated → Rejected → Changes
Decision 1: Search inside the IDE, not somewhere else
What research said: developers described leaving their editor as the reason they stopped using search tools. One said outright that he preferred to stay in the IDE and have the searches there.
Why: the strongest competitor had already lost on this. Asking a developer to context-switch to a browser to understand their own codebase was the behaviour we needed to remove, not redesign.
Result: the product shipped as a VS Code extension. Onboarding became an install rather than a new tool to learn.
Decision 2: Killed the web tab
The original search mixed web pages, code and video results under one “All” tab, with upvote and downvote on results.
Why: mixing sources made every result harder to scan, and neither audience was served. Developers came for code in their own repos, not blog posts.
Result: the web tab was removed and replaced with framework-scoped search, so you could search within React or Tailwind rather than the whole internet. Voting went with it.
Decision 3: Related code, without leaving the result
Opening a result to check one match meant leaving it behind to go back to the search results for anything related, a fresh page load to compare two matches of the same symbol.
Why: the same problem as the web tab, one level down. Losing the result you had open to go check another was exactly the context-switch the product was meant to remove.
Result: a Related Code tab sits next to Code, Owners and Commits on the open result, and related matches surface inline in the code itself, so you never leave what you already had open.
Decision 4: Authors and history on the line, not in a separate tab
Principle served: context. Interviews kept returning to a problem that was not really about search. One developer described institutional knowledge simply being lost, and wanted code histories with graphs and dates.
Why: knowing who last touched a line, and why, is often the whole reason you are looking at it. Google Docs version history was the reference model, because it puts history next to the thing rather than behind a menu.
Result: code owners and commit history surfaced from the result itself, with blame and diff views as toggles.
Decision 5: Commits and author profiles, so devs could see who was making the changes
Ownership on a result named a person, but nothing behind their name: how active they were, what else they had touched, whether they were still the right person to ask.
Why: a commit is a person, not just a diff. Developers wanted to size up whether an author was still active on the file before pinging them, the way they already would on GitHub.
Result: commit activity charted per owner, a full commit history with branch graph and author filter, and an author profile (bio, repos, follow) reached straight from a result.
Some additional screens.
Repo profile: branches
Open a repo directly and browse its branches, alongside contributor and activity stats in the sidebar.
Repo profile: files
The file tree for the repo, each entry with its last commit message and when it landed.
Repo profile: commits
Full commit history for the repo, filterable, with author, hash and message.
Commit diff, side by side
A commit opened as a side-by-side diff, with a toggle back to a single unified view.
Repo profile: contributors
Everyone who has contributed to the repo, plus its backers, in one place.
Repo profile, single page
An early exploration collapsing overview, files, commits, branches and contributors into one scrollable page instead of tabs.
Shared results, with annotations
A shared link showing every file and comment together, so a reviewer sees the whole thread without opening each result.
Commenting on a shared result
Select a range of code in a shared result and leave a comment directly against those lines.
Highlighting a shared result
The same selection, coloured instead of commented, a lighter way to flag a range before deciding what to say about it.
Key findings & iterations
Finding
Solution
Developers would not leave their editor to search their own codebase
Shipped as a VS Code extension rather than a web destination
Mixing web pages, code and video under one tab made every result harder to scan
Removed the web tab and scoped search to the framework in use
A matching line means nothing without the code and the history around it
Code summarisation with a toggle, plus authors and commit history on the result
Onboarding assumed you already knew the framework you were searching
Rewrote the first run around install, authorise, then one real search inside a minute
EARLY USERS
120
Onboarded to the extension
ADOPTION
70%
Reached through interviews and rapid prototype iterations
QUERY TIME
−50%
Time to find a reference, against the previous flow
What I Learned
The interviews kept pointing past the brief. Nobody described a search problem. They described a comprehension problem: who wrote this, why, where else does it live. I learned to trust the thing the research keeps returning to, even when it is bigger than the feature you were asked to design.
Would Do Differently
The research pointed at understanding and editing code in context. The product stayed on search. I had the finding in writing and I designed well inside a scope I already doubted. Now I would put the disagreement on the table early and in one page, rather than letting good execution stand in for the harder conversation.
Postscript, 2026
The hard part was never finding the code. It was understanding it well enough to change it.
Bloop went on to build Vibe Kanban, a tool for orchestrating AI coding agents, where the problem they describe is that the bottleneck has moved to planning and review. Three years and a different product, with the same finding underneath it. The engineers I interviewed in 2022 were already describing a comprehension problem rather than a search one.
I had no part in that turn and I take no credit for it. But it is the clearest evidence I have that the thing the interviews kept returning to was the real one.