AI Code Search · Developer Tools, B2B · 2022
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
At a glance
- Problem
- Developers used the incumbent code search reluctantly: heavy, expensive, and stuck in a browser tab away from their editor.
- What I did
- Ran six developer interviews and a teardown of the incumbent, then designed AI-assisted search inside the IDE, and the onboarding.
- Outcome
- Shipped as a VS Code extension at a Y Combinator startup in 2022, before the category had a name.
- 120
- Early users onboarded to the extension
- 70%
- Adoption, reached through interviews and rapid prototype iterations
- −50%
- Time to find a reference, against the previous flow
Challenge & context
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.
AI code search at a Y Combinator startup, 2022. I ran the research and designed the product, from six developer interviews to a shipped VS Code extension.
“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
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.
Sourcegraph 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.
How I worked
- Research
- I wrote the interview guide and ran six developer interviews. I asked people to recall what they actually did and gave them tasks, rather than asking for opinions.
- Competitor teardown
- I benchmarked Sourcegraph, the tool developers were already using, and turned their complaints about it into design targets.
- Design to shipped
- I designed search, results, code context and onboarding with the two founders, and the engineers built it in React and Tailwind.
Developers did not need better search. They needed the code around the result.
What I did
01Search inside the IDE, not somewhere else
Shipped as a VS Code extension, so developers search without leaving their editor.
02Killed the web tab
Removed the web tab and voting, and replaced them with framework-scoped code search.
03Related code, without leaving the result
A Related Code tab and inline matches, so you never lose the result you have open.
04Authors and history on the line, not in a separate tab Context
Code owners and commit history surfaced on the result itself, with blame and diff toggles.
05Commits and author profiles, so devs could see who was making the changes
Per-owner commit activity and author profiles, reached straight from a result.
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.
01Search inside the IDE, not somewhere else
Shipped as a VS Code extension, so developers search without leaving their editor.
- Problem
- Developers described leaving their editor as the reason they stopped using search tools. One said outright that he preferred to stay in the IDE.
- Shipped
- A VS Code extension, not a web destination.
- Why
- The strongest competitor had already lost on this. Context-switching to a browser to understand your own codebase was the behaviour to remove, not redesign.
- Result
- Onboarding became an install rather than a new tool to learn.
02Killed the web tab
Removed the web tab and voting, and replaced them with framework-scoped code search.
- Problem
- Search mixed web pages, code and video under one “All” tab. Neither audience was served.
- Tried
- One “All” tab for web, code and videoUpvote and downvote on results
- Shipped
- Framework-scoped code search: search within React or Tailwind rather than the whole internet.
- Why
- Mixing sources made every result harder to scan. Developers came for code in their own repos, not blog posts.
03Related code, without leaving the result
A Related Code tab and inline matches, so you never lose the result you have open.
- Problem
- Checking a related match meant leaving the open result for the search results: a fresh page load to compare two matches of the same symbol.
- Shipped
- A Related Code tab beside Code, Owners and Commits, with related matches inline in the code itself.
- Why
- The same problem as the web tab, one level down. Losing the result you had open was exactly the context-switch the product was meant to remove.
04Authors and history on the line, not in a separate tab Context
Code owners and commit history surfaced on the result itself, with blame and diff toggles.
- Problem
- Interviews kept returning to a problem that was not really about search: institutional knowledge being lost. Developers wanted code histories with graphs and dates.
- Shipped
- Code owners and commit history on the result itself, with blame and diff views as toggles.
- 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 model: history next to the thing, not behind a menu.
05Commits and author profiles, so devs could see who was making the changes
Per-owner commit activity and author profiles, reached straight from a result.
- Problem
- Ownership 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.
- Shipped
- Commit activity per owner, a full commit history with branch graph and author filter, and an author profile (bio, repos, follow) reached straight from a result.
- Why
- A commit is a person, not just a diff. Developers wanted to size up an author before pinging them, the way they already would on GitHub.
Supporting screens
Repo profiles, commit diffs and shared results with comments and highlights.
Impact & evidence
120
Early users onboarded to the extension
70%
Adoption, reached through interviews and rapid prototype iterations
−50%
Time to find a reference, against the previous flow
Key findings & iterations
What we found
What changed
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
What I learned
- Nobody described a search problem. They described a comprehension problem: who wrote this, why, where else does it live.
- 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, and I designed well inside a scope I already doubted.
- Now I would put the disagreement on the table early, 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.