Búsqueda entre herramientas: el código es el lugar erróneo
La mayoría de decisiones del desarrollador viven fuera del código. Cómo construir búsqueda entre herramientas con Slack, Linear, GitHub y Notion.
By Ellis Keane · 2026-03-17
Tu codebase es el lugar menos útil para buscar por qué se tomó una decisión.
Sé que suena al revés. Pasamos años aprendiendo flags de ripgrep, configurando búsquedas en el IDE, memorizando patrones de regex – y nada de eso ayuda cuando la pregunta no es "¿dónde está esta función?" sino "¿por qué elegimos este enfoque en lugar de las tres alternativas que discutimos?" La respuesta a esa segunda pregunta casi nunca está en el código. Está en un hilo de Slack de hace cuatro meses, un comentario de Linear enterrado bajo actualizaciones de estado, un doc de Notion que alguien empezó y nunca terminó, y una revisión de PR donde el debate real ocurrió en una respuesta a una respuesta a una respuesta.
Ese es el problema de la búsqueda entre herramientas para los desarrolladores – el contexto de las decisiones está dividido entre herramientas sin una ruta de consulta unificada. Tenemos búsqueda que funciona bien dentro de cada herramienta – la búsqueda de Slack es decente, la búsqueda de código de GitHub es excelente, Linear tiene filtros para todo – pero nada que busque en todas ellas. Las decisiones que dieron forma a tu arquitectura viven en cinco lugares diferentes, y se espera que recuerdes en cuál buscar.
Bien – así es como construir una búsqueda entre herramientas con lo que ya tienes. No se necesitan herramientas nuevas (bueno, casi – mencionaré una al final, pero esto funciona sin ella).
La anatomía de una decisión dispersa
Déjame repasar algo concreto. El año pasado, estábamos decidiendo si usar BullMQ o Temporal para nuestra cola de trabajos. Aquí es donde esa decisión realmente vivía:
- Slack (#engineering): Tres hilos separados a lo largo de dos días. El primero era un enlace que alguien compartió a una entrada del blog de Temporal. El segundo era un debate sobre si necesitábamos ejecución durable. El tercero (una semana después, canal diferente) era alguien preguntando "espera, ¿decidimos lo de la cola?"
- Linear: Un issue titulado "Evaluate job queue options" con seis comentarios, incluyendo una tabla comparativa que uno de nuestros ingenieros pasó una tarde escribiendo.
- GitHub: Una descripción de PR para la implementación de BullMQ que decía "as discussed" con cero enlaces a dónde se había discutido.
- Notion: Un architecture decision record a medias que cubría los pros de Temporal pero que nunca se actualizó con la elección final.
- Google Docs: Notas de una reunión donde realmente tomamos la decisión, enterradas en puntos entre dos temas de agenda no relacionados.
Cinco herramientas. Una decisión. Y si hubieras buscado en cualquier herramienta individual, habrías encontrado un fragmento – nunca la imagen completa. El PR te dice qué elegimos. Los hilos de Slack te dicen qué consideramos. El issue de Linear te dice las concesiones. El doc de Notion te dice la mitad del razonamiento. Las notas de la reunión te dicen el momento en que se finalizó.
Esto no es inusual. Este es, de alguna manera, el estado del arte de cómo los equipos de ingeniería hacen seguimiento de decisiones en 2026. Tenemos IA que genera código y motores de búsqueda que indexan todo Internet, pero descubrir por qué tu equipo eligió BullMQ sobre Temporal requiere revisar cinco aplicaciones y esperar que la memoria de alguien aguante.
Por qué la búsqueda entre herramientas es difícil para los desarrolladores
No es un problema de API – cada herramienta que usamos tiene una API de búsqueda perfectamente buena. El problema es más raro que eso:
Formas de datos diferentes. Slack devuelve mensajes con marcas de tiempo e IDs de canal. Linear devuelve issues con estados y etiquetas. GitHub devuelve commits, PRs y coincidencias de código en formatos de respuesta completamente diferentes. Fusionar estos en una línea de tiempo coherente requiere una normalización que nadie se molesta en construir (porque, honestamente, es el tipo de trabajo que no aparece en las demos de sprint).
Fragmentación del contexto. Un mensaje de Slack que dice "vamos con la opción B" no tiene sentido sin el hilo que definió las opciones A, B y C. Pero la búsqueda de Slack devuelve mensajes individuales, no arcos de conversación. Encuentras la conclusión sin el razonamiento.
Deriva temporal. El proceso de decisión a menudo abarca días o semanas, con lagunas donde nada ocurrió porque todos estaban concentrados en otro trabajo. Una búsqueda por palabras clave podría mostrar el principio y el final de una conversación mientras se pierde el crucial punto intermedio, simplemente porque se usaron palabras diferentes en diferentes etapas.
La búsqueda entre herramientas para desarrolladores no es un problema de API – cada herramienta tiene un endpoint de búsqueda perfectamente bueno. Es un problema de contexto: las decisiones están dispersas entre herramientas en formatos incompatibles, fragmentadas por arcos de conversación y separadas por deriva temporal. La búsqueda por palabras clave encuentra fragmentos; solo el contexto conectado encuentra la imagen completa.
Construir búsqueda entre herramientas con lo que tienes
Aquí viene la parte práctica. Para tres o cuatro herramientas con búsqueda de solo lectura, espera medio día para tener una versión MVP funcionando – la mayor parte dedicada a la configuración de autenticación y la normalización de respuestas en lugar de la lógica de búsqueda en sí.
Configurar el acceso a la API
Necesitarás tokens para cada herramienta:
- Slack: Un token de usuario con scope
search:read (los métodos de búsqueda de Slack requieren tokens de usuario, no de bot – créalos en la página de aplicaciones de la API de Slack)
- Linear: Una clave de API personal desde Configuración, luego API
- GitHub: Un PAT de grano fino con acceso de lectura a tus repositorios
- Notion: Un token de integración interna desde Configuración, luego Conexiones
El script de consulta fan-out
El patrón básico es vergonzosamente simple – enviar la misma consulta de búsqueda a cada API y recopilar los resultados:
```typescript interface SearchResult { source: 'slack' | 'linear' | 'github' | 'notion'; title: string; snippet: string; url: string; timestamp: Date; }
async function crossToolSearch(query: string): Promise<SearchResult[]> { const results = await Promise.all([ searchSlack(query), searchLinear(query), searchGitHub(query), searchNotion(query), ]);
return results .flat() .sort((a, b) => b.timestamp.getTime() - a.timestamp.getTime()); } ```
Cada función search* envuelve la API respectiva. Para Slack, eso es search.messages. Para Linear, es una consulta GraphQL contra sus campos de búsqueda. Para GitHub, es el endpoint de búsqueda REST. Para Notion, es el endpoint de búsqueda con un parámetro query.
Normalizar y deduplicar
La parte complicada no es la búsqueda – es hacer útiles los resultados. Querrás:
- Normalizar las marcas de tiempo entre herramientas (Slack usa épocas Unix, Linear usa strings ISO, GitHub usa ISO con desplazamientos de zona horaria)
- Agrupar resultados relacionados – si el mismo hilo de Slack aparece tres veces porque coincidieron tres mensajes, colapsarlos en un resultado con la URL del hilo
- Ordenar por relevancia – la mayoría de las APIs devuelven sus propias puntuaciones de relevancia, pero no son comparables entre herramientas. Una heurística simple: las coincidencias exactas de palabras clave en títulos se ordenan antes que las coincidencias en el cuerpo, y los resultados más recientes se ordenan antes que los más antiguos con igual relevancia
Envolver en un CLI
Yo uso Commander.js para esto (principalmente por costumbre, pero cualquier cosa funciona):
```bash $ cross-search "bullmq vs temporal"
Found 14 results across 4 tools:
[Slack] #engineering – 2025-11-14 "I've been comparing BullMQ and Temporal for the job queue..." https://myteam.slack.com/archives/C0X.../p17318...
[Linear] ENG-342 – 2025-11-15 "Evaluate job queue options – BullMQ vs Temporal" https://linear.app/myteam/issue/ENG-342
[GitHub] PR #289 – 2025-11-22 "feat: implement BullMQ job queue (as discussed)" https://github.com/myorg/myrepo/pull/289
[Notion] Architecture Decisions – 2025-11-13 "Job Queue Evaluation: Temporal vs BullMQ" https://notion.so/myteam/abc123... ```
Catorce resultados, ordenados por tiempo, de cuatro herramientas. Puedes ver el arco completo de la decisión en un solo lugar: el doc de Notion se inició primero, luego ocurrió la discusión en Slack, luego se creó el issue de Linear para el seguimiento, y finalmente el PR llegó una semana después.
Hacerlo realmente bueno
La versión básica anterior funciona, pero tiene algunas aristas frustrantes. Cómo mejorarla:
Expansión de hilos para Slack. Cuando encuentras un mensaje coincidente, obtén el hilo completo con conversations.replies. El mensaje coincidente podría ser "sí, vamos con BullMQ" – no útil sin los 40 mensajes previos de debate. Muestra un fragmento del hilo, no solo el mensaje coincidente.
Comentarios de revisión de PR. La API de búsqueda de GitHub no muestra los comentarios de revisión cuando buscas PRs – necesitarás una llamada separada al endpoint de revisiones de pull requests para obtenerlos. Ahí es donde vive la discusión técnica real.
Backlinks. Cuando encuentras un issue de Linear, verifica si algún mensaje de Slack contiene la URL de ese issue. La búsqueda de Slack admite filtros has:link combinados con palabras clave. Esto saca a la superficie la discusión informal que ocurrió alrededor del seguimiento formal.
Caché. Si tu equipo genera mucho contenido (¿y qué equipo no?), alcanzarás los límites de tasa rápidamente. Almacena en caché los resultados localmente con un TTL de 30 minutos – la mayoría de las decisiones históricas no cambian tan rápido.
Cuando la búsqueda de texto falla
Aquí seré honesto sobre las limitaciones. La búsqueda por palabras clave entre herramientas te lleva sorprendentemente lejos, y luego choca contra un muro.
El muro es este: las decisiones evolucionan. El hilo de Slack sobre "colas de trabajos" podría nunca mencionar "BullMQ" por nombre – en cambio, alguien compartió un enlace, alguien más dijo "me gusta la opción respaldada por Redis," y una tercera persona dijo "de acuerdo, vamos con eso." Tu búsqueda de "BullMQ" pierde todo el hilo porque la palabra nunca se usó. Las personas en el hilo sabían lo que significaba "la opción respaldada por Redis." Tu búsqueda no.
Este es fundamentalmente un problema de grafo de conocimiento, no de texto. Lo que realmente quieres es: "muéstrame todo lo conectado a la decisión que llevó al PR #289." Eso significa entender que el PR referencia un issue de Linear, que se creó después de una discusión en Slack, que comenzó porque alguien leyó un doc de Notion. Las conexiones son implícitas – los humanos las hicieron copiando URLs y diciendo "as discussed" – y una búsqueda por palabras clave no puede reconstruirlas.
Puedes resolverlo parcialmente siguiendo enlaces. Parsear URLs de mensajes de Slack, descripciones de PRs y comentarios de Linear. Construir una lista de adyacencia simple: este hilo de Slack enlaza a este issue de Linear, que está referenciado en este PR. Luego cuando alguien busca, puedes expandir los resultados para incluir elementos vinculados incluso si no coinciden con la palabra clave.
Ese enfoque de lista de adyacencia es esencialmente un grafo de conocimiento rudimentario – y ahí es donde vive el valor real de la búsqueda entre herramientas para desarrolladores. No en encontrar mensajes individuales, sino en seguir el hilo de una decisión a través de cada herramienta que tocó. Es menos "búsqueda" y más gestión del conocimiento para desarrolladores – entender cómo fluye la información entre tus herramientas para que puedas reconstruir el contexto cuando lo necesites.
El problema del mantenimiento (y un atajo)
El enfoque de script funciona brillantemente durante unos tres meses, y luego alguien cambia el espacio de trabajo de Slack, o Linear actualiza su esquema GraphQL, o agregas una nueva herramienta y nadie recuerda actualizar el script de búsqueda. He construido exactamente esto dos veces y lo he abandonado dos veces (lo que probablemente dice más sobre mi compromiso con el mantenimiento que sobre el enfoque en sí).
Si quieres una búsqueda entre herramientas para desarrolladores que se mantenga actualizada sin supervisión constante, para eso están construidas herramientas como Sugarbug – mantiene el grafo de conocimiento automáticamente y mantiene las conexiones vivas a medida que cambian tus herramientas. Pero la versión DIY anterior es genuinamente útil si estás dispuesto a mantenerla.
Deja de buscar en cinco herramientas por separado. Sugarbug construye el grafo de conocimiento para que puedas encontrar cualquier decisión, discusión o commit en un solo lugar.
Q: ¿Cómo busco en varias herramientas de desarrollo a la vez? A: Puedes construir una búsqueda entre herramientas combinando la API de cada herramienta – search.messages de Slack, issueSearch de Linear y el endpoint de búsqueda de código de GitHub – en un único script que distribuye las consultas y fusiona los resultados por marca de tiempo. Los ejemplos de código anteriores te pondrán en marcha en una tarde. El principal reto no es la búsqueda en sí, sino la normalización de los diferentes formatos de respuesta en una línea de tiempo coherente.
Q: ¿Ofrece Sugarbug búsqueda entre herramientas para desarrolladores? A: Sí. Sugarbug ingesta señales de Linear, GitHub, Slack, Figma, Notion y otras herramientas en un grafo de conocimiento, para que puedas buscar una decisión o discusión y encontrar cada hilo, issue y commit relacionado en un solo lugar. Gestiona la normalización, la deduplicación y el seguimiento de enlaces automáticamente – las partes que hacen que el enfoque DIY sea frágil con el tiempo.
Q: ¿Por qué no encuentro decisiones de arquitectura en mi codebase? A: Porque la mayoría de las decisiones ocurren en hilos de Slack, comentarios de Linear, docs de Notion y revisiones de PRs – no en el código en sí. El código registra el resultado de una decisión (la función existe, la biblioteca fue elegida), pero el razonamiento, las concesiones y las alternativas discutidas viven dispersos entre tus herramientas de comunicación. Un git blame te dice quién cambió una línea y cuándo, pero no por qué eligieron ese enfoque sobre las alternativas.
Q: ¿Puede Sugarbug reemplazar los documentos ADR para el seguimiento de decisiones? A: Sugarbug no reemplaza los ADRs, pero captura las decisiones que nunca llegan a un ADR. La mayoría de los equipos escriben ADRs para quizás el 10% de sus decisiones arquitectónicas – el resto se disuelve en hilos de Slack y comentarios de PRs. Sugarbug las saca a la superficie conectando conversaciones con los cambios de código que produjeron, para que obtengas seguimiento de decisiones para el otro 90% sin cambiar el flujo de trabajo de nadie.