HoundDog.ai - Code Context Engine
Stop wasting AI tokens rediscovering your code
530 followers
Stop wasting AI tokens rediscovering your code
530 followers
HoundDog.ai is the deterministic code context engine. Rust scanners map services, APIs, and data flows across monorepos and microservices on every commit.
ProtoMap: maps gRPC service, API, and field names across all call sites and multiple hops. Coding agents get it over MCP, with 13× fewer tokens and 7.7× faster answers in our benchmarks.
Privacy Code Scanner: GDPR data mapping and code-level evidence of sensitive data flows across logs, storage, APIs, third parties, and AI integrations.
This is the 2nd launch from HoundDog.ai - Code Context Engine. View more
ProtoMap
Launched this week
ProtoMap helps engineers and AI coding agents understand how services, APIs, and data fields depend on each other across large codebases. It builds a deterministic dependency map for gRPC and Protobuf systems, updated on every commit and accessible through a web app or MCP. Instead of wasting time and tokens searching code across repositories, agents query ProtoMap directly to understand change impact. One enterprise team reduced change-planning time and tokens by 8×.
Free Options
Launch Team / Built With
LoomShow, don't just tell with Loom
Promoted
Hey Product Hunt! I'm Amjad, co-founder of HoundDog.ai. Today we're launching ProtoMap.
The problem
AI coding agents are writing more of our code every day, and every line adds services, calls and fields that the next agent has to rediscover. In a large gRPC + Protobuf codebase, a simple question like "what breaks if I change this service, RPC or field?" sends an agent off to grep, find and read files across repos, trying to piece together relationships in code that often isn't even checked out on the developer's machine. That's slow and expensive, the answer is often incomplete, and it changes from one run to the next.
How ProtoMap is different 🚀
ProtoMap doesn't replace your coding agent. It gives your agent the context it is missing. A deterministic static-analysis engine maps every service, API and field across your monorepos and microservices, refreshes the map on every commit, and serves it to engineers in a web platform and to coding agents over MCP.
🔹 Multi-hop service dependencies: see the blast radius of a change up to five hops out.
🔹 Method dependencies: find who calls an RPC, plus every call site with its file location.
🔹 Field dependencies: see which services and repos send or receive a field like credit_card.
🔹 Code owners: see every inbound service, plus the maintainers and dependents to notify.
🔹 Unused RPCs: find dead RPCs, orphaned calls, and proto messages declared differently in two repos.
Because agents query the graph instead of re-reading code, the cost of an answer depends on the question, not on the size of your codebase. For one enterprise customer with a monorepo of millions of lines and a complex web of gRPC services, ProtoMap reduced the time and tokens required for change planning by 8×.
Who is it for?
Engineering teams running gRPC + Protobuf at scale, and the AI coding agents working alongside them.
Benchmark
In the gallery video, you’ll see two live Claude Code sessions (Opus 5.5, high effort) running side by side, given the same prompt at the same moment and recorded on one screen.
The prompt:
"We want to remove the RPC acme.documents.v1.DocumentQueryService/ResolveDocuments. Find every place in every repo that calls it, including indirect calls through helpers, method names built from strings, registries, or reflection, and give file:line and the calling service for each so we can migrate them."
On this prompt, ProtoMap was 7× faster and 36× cheaper, and used 93× fewer tokens:
■ Claude Code alone (no MCP): 6:01 · $14.44 · 24.5M tokens
■ Claude Code + ProtoMap MCP: 0:50 · $0.40 · 262K tokens
For more detailed benchmarks across 20 prompts on 9 gRPC repositories, see our benchmark page: https://hounddog.ai/protomap-benchmark/
Live Demo
Visit https://hounddog.ai/videos/protomap-demo/ to see our live demo at MozFest, which includes querying the service graph in our web platform to track dependencies for services, APIs and fields across multiple hops, including callers, callees and call sites. The demo also walks through our detailed benchmarks.
🔗 Get started
ProtoMap is free to run on your machine: the self-hosted web platform and CLI scanner. When you're ready to roll it out org-wide, the Enterprise plan keeps the graph fresh across every repo, with CI scans on every pull request and GitHub, Bitbucket and GitLab integrations. Get started at https://github.com/hounddogai/protomap
We'd love your feedback, especially from anyone managing a large gRPC codebase!
i like the idea of asking questions directly from the data map. Can non-technical privacy teams use it without developer help?
@velvet_trace yes, absolutely! ProtoMap has a chat interface where you can ask questions in plain English, and answers come with interactive diagrams that help you explore your gRPC and Protobuf data flows.
Can ProtoMap detect what can break before I merge a PR?
@bengeekly Absolutely! Before you merge, your AI coding agent gets the service graph from the main branch via MCP, with your changes layered on top. This lets your agent quickly see if changes to an API, service, or field impact other dependencies, without wasting tokens on discovery.
the same proto message declared diffrently in two repos is such a real one, nobody notices until something breaks in prod
since the map refreshes on every commit, what does the agent see for a field that only changed on an open branch??? or is it main only for now
@thamibenjelloun thanks for the question! In a nutshell, your team sees the context graph built from main and as you code on a feature branch your agent gets a local copy of the main graph that updates with your changes in real time. Your agent sees your changes, while teammates still see main until you merge.
This hits a pain I feel in basically every coding-agent session — a huge share of the tokens goes to the agent re-reading code just to work out what a change touches, before it does anything useful. A deterministic dependency map it can query instead of grepping through repos feels like the right fix, and your side-by-side says it plainly: 24.5M tokens down to 262K for that RPC removal. Curious whether the payoff holds up on a smaller codebase that isn't a big gRPC estate, or if this is really a scale play?
@jcbuilds Great question! The value of ProtoMap definitely compounds as the codebase and microservices estate grow, but it's not just a scale play. In our detailed benchmark (https://hounddog.ai/protomap-benchmark/), certain queries, like finding all dependents of a service or the blast radius of a field name change, show significantly greater savings than others. For those queries, you can expect substantial ROI (potentially 5X or more in time and cost), even with a relatively smaller codebase of around 200K lines of code. And with AI coding agents accelerating development, what is 200K lines of code today could easily grow to 1M much faster than before.
benchmark is kinda the best case for a graph tho. would be cool to see one where the agent has to actually ship the change after
@igorblink Fair point! Would love to benchmark that too. Generating code is the easy part for agents. Understanding context, service dependencies, and relationships, especially in large monorepos or complex microservices estates, is where agents waste a ton of tokens on discovery. That's the problem we're tackling with ProtoMap.
Showing the code owners next to each dependency is the part I would use most. Does the field-level view, like where credit_card flows, work across repos or only inside one monorepo?
@neerajnathany It works across repos for sure! Even if your org has hundreds of microservices spread across different repos, ProtoMap captures all those dependencies and their code owners. So when you ask your agent to change an API, service, or field, it already understands the relationships, potential impact, and who owns what, without wasting tokens on discovery.
@amjad_afanah1 makes sense! does the map pick up a brand new repo on its own, or does someone need to kick off a re-scan?