luismori.
AI Research AI Agents

Agentes de IA como herramientas de investigación: de la curiosidad al prototipo en horas

Cómo los agentes de IA están acortando la distancia entre «me pregunto cómo funciona X» y «tengo una implementación funcional de X», y qué flujos de investigación realmente funcionan bajo presión.

12 min de lectura

Hay un tipo particular de ciclo de investigación en ingeniería que antes tomaba días. Te encontrabas con un problema desconocido —un protocolo nuevo, un framework que no conocías, un dominio que nunca habías explorado— y el camino entre «no entiendo esto» y «tengo código funcional» implicaba leer documentación, buscar en Stack Overflow, leer artículos académicos, experimentar localmente, leer más documentación y construir poco a poco un modelo mental.

Los agentes de IA han acortado ese ciclo. No porque hayan facilitado la investigación, sino porque han cambiado la unidad fundamental de trabajo. La pregunta ya no es «¿cuánto tiempo me tomará entender esto?», sino «¿cómo estructuro la conversación para llegar antes a la respuesta correcta?».

Qué cambió (y qué no)

Lo más importante que los agentes de IA cambiaron en la investigación es la velocidad de iteración. Ahora puedes explorar cinco enfoques para un problema en el tiempo que antes te tomaba leer con atención una página de documentación.

Lo que no cambió: la necesidad de tener criterio. Los agentes alucinan con seguridad. Describen API que no existen, citan artículos con resultados incorrectos o producen código que parece correcto, pero falla en casos límite. La habilidad de investigación que más importa en un mundo potenciado por IA es saber cuándo confiar y cuándo verificar.

El modelo mental más productivo: trata al agente como un colega con amplios conocimientos que a veces recuerda mal los detalles. Su capacidad de síntesis suele ser buena. Los detalles específicos necesitan verificación.

El conjunto de herramientas de investigación

Hoy, la mayor parte de la investigación técnica pasa por un conjunto reducido de herramientas:

Claude (Sonnet/Opus) — profundidad conversacional, contexto extenso para leer documentos y bases de código completos, y una sólida capacidad de razonamiento para comparar enfoques.

Perplexity / Agentes con búsqueda integrada — para obtener información actualizada. El conocimiento de Claude tiene una fecha de corte; Perplexity consulta fuentes en tiempo real. Úsalo cuando necesites saber qué pasó en los últimos 6 meses.

Claude Code — para investigaciones que requieren ejecutar código. Esto cambia las reglas del juego. Los agentes que pueden escribir, ejecutar, depurar e iterar código en tu entorno real acortan la distancia entre leer sobre algo y entender cómo se comporta en la práctica.

Servidores MCP dedicados — para investigar dominios específicos. Un MCP de base de datos permite al agente consultar tu esquema. Un MCP de GitHub le permite leer bases de código reales. Un MCP de documentación le permite buscar en documentación indexada. La calidad de la investigación aumenta con el acceso a herramientas.

Flujo de trabajo 1: exploración de arquitectura

Te han pedido evaluar tres enfoques para un problema que todavía no entiendes por completo. Un ejemplo clásico: «¿deberíamos usar event sourcing, CQRS o un enfoque desnormalizado más sencillo para cumplir los requisitos de nuestro registro de auditoría?».

La decisión equivocada: abrir tres pestañas del navegador y empezar a leer.

La decisión acertada: empezar con un prompt estructurado.

I need to evaluate three architectural approaches for an audit log system:
event sourcing, CQRS, and a denormalized append-only table.

Context:
- ~500 write events/second at peak
- Need to replay history for compliance queries
- Team has no existing experience with event sourcing
- Postgres is our current DB, team is comfortable with it

For each approach, give me:
1. How it works (3-sentence summary)
2. What breaks at our scale
3. The hidden complexity that kills teams new to this pattern
4. A concrete example of the trade-off in our specific context

La estructura obliga al agente a profundizar en cada opción en lugar de darte una respuesta genérica de «depende». Pedirle que identifique la «complejidad oculta» es especialmente valioso: ahí es donde los agentes sacan a la luz conocimientos que de otro modo te tomaría semanas descubrir.

Después de esta exploración inicial, profundiza en la disyuntiva más importante que hayas identificado:

You mentioned that event sourcing at 500 writes/second creates snapshot
management complexity. Walk me through exactly what that looks like — what
does the code look like at the point where it becomes a problem, and what's
the standard mitigation?

Profundiza entre tres y cuatro niveles antes de aceptar una conclusión.

Flujo de trabajo 2: arqueología de una base de código

Heredaste un sistema. No hay documentación. Necesitas entender cómo funciona lo suficientemente bien como para modificarlo de forma segura.

Aquí es donde Claude Code cambia por completo el paradigma de investigación.

# Give Claude Code the full codebase context
> Explore the codebase and build a mental model of the data flow.
  Start from the HTTP entry points and trace how a user authentication
  request flows through the system. Note any non-obvious patterns,
  hidden dependencies, or places where the architecture seems inconsistent.

Deja que explore durante varios minutos. Después:

> Based on your exploration, what are the three riskiest places to make
  changes without causing unintended side effects? Why?

El resultado de esta sesión no es solo información: es un mapa útil del sistema. Luego puedes hacer preguntas específicas:

> Where does session invalidation happen? Is it consistent across all
  auth paths, or are there edge cases where sessions don't get cleaned up?

Este flujo de trabajo logra en una hora lo que un sprint de documentación tarda una semana en completar. El agente lee cada archivo, rastrea cada importación y sintetiza patrones que una persona pasaría por alto al revisar superficialmente la base de código.

Flujo de trabajo 3: el patrón «construirlo para entenderlo»

Para algunos temas, leer al respecto es fundamentalmente insuficiente. Necesitas ejecutar algo. Aquí es donde los agentes de IA + Claude Code crean un flujo de investigación que antes no tenía un buen equivalente.

El patrón: describe lo que quieres explorar, deja que el agente construya una versión mínima funcional, haz que falle deliberadamente y observa qué pasa.

Ejemplo: entender cómo se comportan realmente los advisory locks de PostgreSQL bajo carga concurrente.

Build a minimal test harness that demonstrates PostgreSQL advisory locks:
- Two competing processes trying to acquire the same lock
- Show what happens when the lock holder crashes mid-transaction
- Show the difference between session-level and transaction-level advisory locks
- Make the behavior observable (log each step, timestamps, connection IDs)

Claude Code escribe la prueba, la ejecuta y te muestra el resultado. Luego exploras los casos límite:

Now modify the test to simulate what happens if we hold the advisory lock
while doing a long-running query that sometimes times out.
Does the lock release on timeout? Show me.

En 20 minutos obtienes una comprensión empírica de cómo se comportan los advisory locks en escenarios de falla. Llegar a esa comprensión habría tomado horas de lectura de documentación y Stack Overflow, sin garantía de que asimilaras correctamente los matices.

Flujo de trabajo 4: síntesis de la literatura

Estás evaluando una nueva técnica, por ejemplo, usar almacenamiento columnar para tu carga de trabajo analítica. Quieres entender el consenso académico y el de quienes trabajan en la práctica, no solo el marketing de los proveedores.

Para esto, el agente funciona mejor como un sintetizador estructurado que como un motor de búsqueda:

I'm evaluating columnar storage (specifically DuckDB and ClickHouse) for
analytics on structured event data. I need to understand:

1. What does the systems research literature say about the fundamental
   performance characteristics of columnar vs row-oriented storage?
2. What are the known failure modes that practitioners report but vendors
   don't highlight?
3. What workload shapes is columnar storage *not* good for?

Don't give me marketing claims. Focus on documented behavior, known trade-offs,
and cases where the theory doesn't match practice.

Luego sigue el hilo. Cuando el agente mencione «la materialización tardía como una optimización clave del almacenamiento columnar», pídele que explique exactamente cómo funciona y en qué casos deja de ser eficaz. Cada afirmación interesante es una rama que puedes explorar.

La síntesis que toma una semana de lectura construir manualmente —leer los artículos fundacionales, las publicaciones de profesionales y los relatos de experiencias como «abandonamos X»— puede elaborarse en una sesión concentrada de dos horas.

Cuándo confiar y cuándo verificar

La habilidad más difícil en la investigación potenciada por IA es calibrar tu nivel de confianza. Algunas reglas prácticas que funcionan:

Confía en el agente para:

  • Explicaciones conceptuales de temas bien documentados
  • Sintetizar las ventajas y desventajas de distintos enfoques
  • Generar implementaciones iniciales para experimentar
  • Identificar preguntas que deberías hacerte, pero no te estás haciendo

Verifica antes de basarte en:

  • Firmas y parámetros específicos de API
  • Benchmarks y cifras de rendimiento
  • Afirmaciones sobre «lo que hace la mayoría de los equipos» o «el estándar de la industria»
  • Cualquier cosa cuyo error resulte costoso descubrir más adelante

Verifica siempre:

  • Código que afecte la seguridad
  • Cualquier cosa que involucre criptografía, autenticación o manejo de datos
  • Afirmaciones sobre el comportamiento de servicios de terceros (cambian)
  • Cualquier cosa sobre la que el agente parezca inusualmente seguro

Una práctica útil para obligarte a reflexionar: después de una sesión de investigación, escribe un resumen de dos párrafos sobre lo que aprendiste y lo que todavía querrías verificar. Si no puedes identificar nada que verificar, tu investigación no ha terminado.

Cómo estructurar sesiones de investigación largas

La investigación con agentes de IA funciona mejor cuando está estructurada, no cuando se desarrolla sin una dirección definida. Algunas prácticas que ayudan:

Empieza por definir el alcance. Dile al agente qué intentas decidir, no solo qué quieres saber. «Estoy tratando de decidir si usar Redis Streams o Kafka para una carga de 10K msg/sec» es más productivo que «explica Kafka».

Usa la regla de los cinco niveles. Para cualquier afirmación importante, profundiza con cinco preguntas antes de aceptarla. Pregunta «¿por qué?» cuatro veces después de cada respuesta. Esto revela las suposiciones subyacentes, que es donde reside la verdadera comprensión.

Escribe a medida que avanzas. Pídele al agente que te ayude a registrar lo que aprendiste en un formato estructurado después de cada hallazgo importante. Las conversaciones largas se desvían; las notas estructuradas capturan las partes útiles.

Termina con el desacuerdo. Cierra cada sesión de investigación preguntándole al agente: «¿Cuál es el argumento más sólido en contra de la conclusión a la que llegamos? ¿Qué haría que este análisis fuera incorrecto?». El agente es bueno para construir la versión más sólida posible de posturas contra las que acaba de argumentar.

Ejemplo práctico: una sesión de investigación real

Así se ve, de forma resumida, una sesión de investigación sobre un problema real:

Problema: ¿Deberíamos migrar nuestra cola de trabajos en segundo plano de Sidekiq (respaldada por Redis) a una cola basada en Postgres como Solid Queue?

Estructura de la sesión:

  1. Exploración de arquitectura: «Compara Sidekiq y Solid Queue en cuanto a garantías de confiabilidad, características de rendimiento y complejidad operativa. Explica específicamente qué significa en la práctica la “entrega al menos una vez” para cada uno».

  2. Investigación de modos de falla: «¿Qué pasa con los trabajos en Sidekiq cuando Redis se queda sin memoria? ¿Qué pasa con los trabajos en Solid Queue cuando se agota el pool de conexiones de Postgres? Dame el comportamiento exacto ante cada falla».

  3. Construirlo para entenderlo: «Construye una prueba mínima que demuestre el comportamiento de Sidekiq cuando un worker falla a mitad de un trabajo. ¿Se reintenta el trabajo? ¿Desde qué punto de la ejecución?».

  4. Análisis específico del equipo: «Tenemos un equipo de 4 ingenieros, una instalación de Heroku Postgres ya en funcionamiento y ninguna experiencia en Redis. Actualmente tenemos ~200 trabajos/minuto. ¿Qué sistema reduce nuestro riesgo operativo durante los próximos 2 años?».

  5. Argumento más sólido: «Presenta el argumento más sólido posible para no migrar de Sidekiq, dado nuestro contexto».

Tiempo total de la sesión: aproximadamente 90 minutos. Resultado: una decisión con el razonamiento documentado, una lista de cosas que verificar con los mantenedores de Solid Queue y un script de migración como prueba de concepto.

El efecto acumulativo

El aspecto más subestimado de la investigación potenciada por IA es su efecto acumulativo. Cada sesión de investigación produce artefactos —notas estructuradas, registros de decisiones, tablas comparativas, código de prueba de concepto— que se convierten en contexto para sesiones futuras.

Un equipo que realiza sesiones de investigación estructuradas y conserva los resultados construye una base de conocimiento que los agentes pueden usar para acelerar cada decisión posterior. El archivo CLAUDE.md de un proyecto de Claude Code es el comienzo de esto —decisiones de arquitectura, patrones elegidos, ventajas y desventajas conocidas—, pero el modelo se extiende a cada decisión del equipo que requiera mucha investigación.

Los equipos que tienen éxito con la IA no son los que usan agentes para más tareas. Son los que han descubierto cómo usar agentes para construir conocimiento organizacional más rápido que sus competidores.

Fuentes