Cómo hemos reinventado la criba de currículums con un flujo de trabajo nativo en IA

Este artículo trata sobre un pequeño experimento: conectar nuestra base de datos de contratación de Notion a Claude Code y ejecutar un flujo de trabajo dinámico que despliega más de 100 agentes de IA en paralelo para leer currículums, puntuarlos según una rúbrica coherente y contrastar los juicios entre sí, generando una lista corta clasificada sobre la que podíamos actuar de inmediato.

Todo el proceso costó 65 $ y se completó en unos 13 minutos con 115 candidatos. Pero más interesante que el coste fueron las cuestiones metodológicas que surgieron: cuándo usar una flota de agentes en lugar de uno solo, cómo evitar la inflación de puntuaciones de la IA y qué significa codificar la "excelencia" en algo que una máquina pueda realmente ejecutar.

1. Qué es un flujo de trabajo dinámico

Empecemos por el concepto, porque es la base sobre la que se sustenta todo lo demás.

La mayor parte del uso actual de la IA sigue un patrón de prompt y respuesta: envías un mensaje, obtienes una respuesta, iteras. Esto funciona bien para tareas puntuales, pero se vuelve incómodo cuando necesitas hacer lo mismo con 115 objetos: o bien copias y pegas 115 veces, o le pides a una sola conversación que los procese secuencialmente, lo cual se vuelve más lento y más ruidoso a medida que avanza.

Un flujo de trabajo dinámico es un modelo diferente: código que orquesta una flota de agentes de IA. Sus propiedades definitorias son:

• Flujo de control determinista + criterio de la IA, mantenidos por separado. Los bucles, la distribución de tareas, la agregación y la aplicación de cuotas los gestiona el código (reproducible, auditable); el juicio subjetivo (¿es este currículum lo bastante sólido?) se delega en agentes de IA.
• Paralelismo en abanico (fan-out). Una sola llamada parallel(...) puede poner en marcha decenas o cientos de agentes independientes de forma simultánea, cada uno trabajando en su propia porción sin contaminar a los demás.
• Canalizaciones multietapa. La salida de una etapa alimenta la siguiente. El código se encarga del filtrado, la clasificación y la eliminación de duplicados entre etapas.
• Salida estructurada. Cada agente devuelve JSON conforme a un esquema, no texto de chat libre, de modo que el código posterior puede consumirlo directamente.

Una analogía: una única conversación es como consultar a un experto durante una tarde. Un flujo de trabajo dinámico es como reunir un panel de revisión de 125 personas, entregar a cada miembro una rúbrica y el expediente de un candidato, ejecutar todas las revisiones en paralelo, contrastar los mejores resultados y agregarlos en una lista clasificada, con la lógica de composición, distribución y agregación incorporada en el script.

La selección de currículums encaja de forma natural en este patrón: alto volumen, criterios uniformes, juicio subjetivo, requisito de equidad.

Para una introducción técnica más profunda: A harness for every task: dynamic workflows in Claude Code

2. El flujo de trabajo de contratación: objetivos y diseño

El problema

Teníamos un punto de dolor concreto: más de cien candidatos en estado de "revisión inicial" en nuestra base de datos de contratación de Notion, sin ninguna forma realista de procesarlos manualmente sin que se produjera una deriva del estándar: el listón que aplicas en el currículum 80 casi nunca es el mismo que en el currículum 5.

Quería poner a prueba una idea concreta: ¿podemos abstraer "cómo es la excelencia en la era de los agentes de IA" en una rúbrica ejecutable por una máquina y legible por humanos, y después pasar a los 115 candidatos por esa misma calibración?

El objetivo era explícitamente no dejar que la IA tomara decisiones de contratación. El objetivo era:

1. Comprimir 115 candidatos en una lista corta clasificada y justificada, para que la atención humana se dirija a las personas que realmente la merecen.
2. Hacer que los criterios sean transparentes e iterables: si el resultado es incorrecto, cambias un archivo Markdown, no el código ni la intuición.

Tres decisiones clave de diseño

Decisión 1: los criterios y el código están completamente separados

Los criterios de evaluación viven en archivos Markdown independientes (criteria/), no incrustados en el código del flujo de trabajo. Cualquiera —incluidos compañeros de equipo sin perfil técnico— puede cambiar el comportamiento de la selección editando estos archivos:

criteria/
├── 00-philosophy.md          Overall philosophy: what we're hiring for + the "raise the bar" rule
├── 01-pedigree.md            Strong academic / early foundation    (weight 20%)
├── 02-ai-agent-fluency.md    AI-native capability                  (weight 35%)
├── 03-grit-problem-solving.md  Problem-solving & overcoming difficulty  (weight 30%)
├── 04-talent-lens.md         Top-talent signal                     (weight 15%)
└── scoring.md                Scoring formula + grade bands + 5% quota rule

Estas cuatro dimensiones son nuestro "estándar de excelencia para la era de los agentes de IA, v0.1". El razonamiento detrás de cada una:

• La capacidad nativa de IA tiene el peso más alto (35%). En 2026, que alguien use realmente herramientas agénticas como Claude Code como parte central de su forma de trabajar es un factor de productividad determinante. Penalizamos específicamente el "relleno de palabras clave": mencionar "Claude Code" sin evidencia verificable de proyectos se trata como una señal débil.
• Evidencia sólida de resolución de problemas (30%). Buscamos "cicatrices": cosas construidas de forma independiente desde cero, narrativas de haber superado obstáculos reales, no reproducciones de nivel tutorial.
• Base sólida (20%). El historial académico funciona como indicador del potencial en bruto: es una señal, no un requisito. Un título de una universidad selectiva combinado con una producción mediocre se penaliza; un autodidacta sin credenciales prestigiosas pero con trabajo real ya publicado obtiene una bonificación.
• Señal de talento superior (15%). Esta dimensión es deliberadamente subjetiva. La consigna pregunta: ¿un equipo como el de Anthropic o un fundador como Musk querría contactar con esta persona de inmediato? Captura la iniciativa, el criterio y la velocidad que las otras tres dimensiones no recogen.

Decisión 2: codificar "subir el listón" como una restricción rígida, no como un eslogan

scoring.md incluye una regla firme: los candidatos que alcancen el nivel superior (S) deben ser ≤ 5% del total del grupo. Una vez completada toda la puntuación, el código aplica un límite global: aunque muchos candidatos puntúen técnicamente en el rango S, solo se permite el paso al 5% superior. Esto combate directamente un fallo conocido: la puntuación de la IA es naturalmente indulgente. Sin una restricción rígida, calificará como "excelente" a la mitad del grupo.

Decisión 3: añadir una revisión adversarial para detectar puntuaciones infladas

Puntuar por sí solo no es suficiente. Un único agente de puntuación puede dejarse arrastrar por palabras clave que suenan impresionantes: "publicado en revista de primer nivel", "he construido mi propio framework". Por eso los candidatos mejor clasificados pasan por una segunda ronda: un panel de agentes de "abogado del diablo" cuya tarea explícita es argumentar en contra de que "esta persona merece una calificación de primer nivel" y bajar las puntuaciones allí donde la evidencia no las respalde plenamente.

El flujo de trabajo

Configuración 📋 Base de datos de contratación de Notion — extracción mediante Notion CLI → un archivo de datos estructurado por candidato

IA Fase 1: Puntuación (115 agentes en paralelo)

• Lee los 6 archivos MD de criterios + el archivo de datos de ese candidato
• Visita activamente los enlaces de GitHub / portafolio para verificar la evidencia
• Genera JSON estructurado: puntuaciones en 4 dimensiones + razonamiento + aspectos destacados + señales de riesgo

Código Síntesis determinista

• Calcula los totales ponderados
• Ordena por clasificación global, calcula las plazas de la cuota del 5%
• Selecciona a los mejores candidatos para la cola de revisión adversarial

IA Fase 2: Revisión adversarial (agentes en paralelo)

• El personaje "abogado del diablo" revisa a cada candidato destacado
• Argumenta en contra de la designación de primer nivel
• Baja las puntuaciones donde la evidencia sea insuficiente

Código Veredicto determinista

• Reordena usando las puntuaciones calibradas
• Aplica el límite rígido del 5%
• Asigna las bandas de calificación finales: S / A / B / C / D

Salida: informe clasificado Markdown estructurado con puntuaciones por candidato, razonamiento y veredicto de la revisión adversarial

Las etapas azules (puntuación / revisión) son de IA. Las etapas grises (síntesis / veredicto) son de código. Esta separación es intencionada: todo lo que es matemático —ponderación, clasificación, aplicación de cuotas— va al código, por reproducibilidad; todo lo que requiere criterio —¿es esta persona lo bastante sólida?— va a la IA.

3. Lo que vimos: resultados y hallazgos

Todos los candidatos que se mencionan a continuación han sido anonimizados. Describimos el tipo de trabajo, no nombres ni datos identificativos.

Lo que ejecutamos

Distribución

La cuota del 5% (5 plazas) no se usó en absoluto: no fue la cuota lo que bloqueó a nadie, sino el umbral absoluto de puntuación. Nadie superó por sí solo el suelo de la banda A. Más adelante explicamos por qué eso es en realidad una señal útil.

Cómo era la parte alta de la clasificación (anonimizado)

Sin excepción, los candidatos mejor clasificados eran personas que realmente habían construido agentes, no personas que habían oído hablar de la IA:

• #1: un estudiante de posgrado que construyó desde cero un banco de trabajo multiagente al estilo Claude Code, incluyendo el bucle principal del agente, el análisis de llamadas a herramientas, la compresión de contexto, la creación de subagentes y las barreras de seguridad. Todo código verificable, no descripciones.
• #2: otro estudiante de posgrado que había desplegado un sistema multiagente real y públicamente accesible (aplicación de dominio vertical), con producción académica añadida encima.
• Más abajo: alguien que escribió desde cero un motor de orquestación de agentes en Go; alguien que lanzó un agente de codificación ligero estudiando la arquitectura de Claude Code; alguien que construyó de forma independiente un juego con un LLM local en siete días, usando herramientas de IA en todo el proceso.

Lo que tenían en común: sus señales fuertes casi nunca aparecían en el cuerpo del currículum, estaban en repositorios de GitHub y portafolios. Precisamente por eso se instruyó a cada agente de puntuación para que visitara activamente los enlaces y verificara la evidencia en lugar de limitarse a leer el texto del currículum.

Tres hallazgos

Hallazgo 1: la revisión adversarial detectó de verdad puntuaciones infladas

El ejemplo más claro fueron los dos primeros candidatos. Tras la fase de puntuación, ambos tenían totales ponderados en torno a los 82 puntos, suficiente para entrar en la banda A y rozar el umbral S. Tras la revisión adversarial, ambos quedaron en torno a los 75 puntos, con un razonamiento muy concreto:

"Construyó un banco de trabajo multiagente verificable: la capacidad nativa de IA es una señal sólida. Pero el proyecto tiene ~3 semanas de antigüedad, un único colaborador, 0 estrellas, sin pruebas. Conceptualmente es una reimplementación, no una resolución de problemas original. Casi ninguna evidencia de respaldo más allá de la línea del título: un candidato sólido con alto potencial, pero no excepcional."

"Un constructor nativo de IA genuino y verificable. Pero la publicación reclamada en una revista de primer nivel solo aparece en las notas del reclutador, sin ninguna fuente verificable de forma independiente. El backend del sistema principal es privado; no se puede confirmar la contribución individual. Usar credenciales académicas no verificadas para aspirar al nivel superior es inflación de puntuación impulsada por palabras clave."

Esto es exactamente lo que el diseño pretendía lograr: no descartó a estos candidatos, sino que llevó las puntuaciones de vuelta a lo que la evidencia realmente puede respaldar. Un único agente de puntuación puede dejarse llevar; un panel de agentes independiente cuya tarea es objetar reduce eso de forma fiable.

Hallazgo 2: S:0 / A:0 no es un fallo, es un espejo

El primer instinto es preguntarse si el listón se fijó de forma incorrecta. Pero mirando el grupo con honestidad:

• Una gran parte de los candidatos tenía currículums muy escuetos: faltaban por completo dimensiones clave (experiencia con IA, trabajo verificable).
• Muchos solicitantes para puestos de Agent Engineer no tenían ninguna evidencia de uso de herramientas agénticas ni enlace a GitHub.
• El grupo también contenía correos comerciales de reclutadores y notificaciones automáticas de LinkedIn; se identificaron correctamente como irrelevantes y se puntuaron con 0, lo cual reveló de paso que nuestra base de datos de contratación necesitaba una limpieza.

Dicho de otro modo, una rúbrica estricta separó con claridad la señal del ruido. Los constructores reales (los 6 primeros) y los "generalistas destacados" (nivel intermedio) acabaron en lugares claramente distintos. Ese es el punto: es mejor pasar por alto a unos pocos que inflar a todos.

Esto también plantea una pregunta abierta que merece la pena discutir: ¿es el umbral actual de la banda A (78 puntos) demasiado estricto para candidatos que son estudiantes con un historial sólido en GitHub pero sin trayectoria profesional aún? Curiosamente, los propios agentes de revisión adversarial describieron a los dos primeros candidatos como "candidatos de alto potencial", pero la puntuación ponderada los mantuvo en la banda B. Si conviene relajar ese umbral para candidatos de alto potencial en etapas tempranas de su carrera es una decisión de criterio que se toma mejor después de ver la calidad real de las entrevistas del grupo B. La buena noticia: ese cambio es un número en un archivo Markdown. No requiere código.

Hallazgo 3: "criterios como código" hace que el desacuerdo sea productivo

Las conversaciones sobre estándares de contratación suelen quedarse en lo vago: "queremos gente con determinación", "alguien que sepa resolver las cosas". Como esta rúbrica está escrita con pesos y ejemplos de referencia, la conversación se vuelve concreta de inmediato: "¿La capacidad de IA debería ser el 35% o el 40%?" "¿Cuánto gana realmente un constructor atípico sin un título prestigioso?" "¿La cuota debería ser del 5% o del 8%?" Cada desacuerdo corresponde a una línea concreta en un archivo Markdown que se puede cambiar, versionar y debatir. El estándar se convierte en un activo que mantienes, no en un consenso que repites en cada reunión.

4. Coste y retorno de la inversión

Gasto exacto

Usamos Claude Opus 4.8 (el nivel superior). Desglose preciso por categoría de tokens:

Eso equivale a aproximadamente 0,57 $ por candidato.

Un hallazgo contraintuitivo: la escritura en caché es la mayor partida

La suposición natural es que, como los 115 agentes leen todos los mismos 6 archivos de criterios, el almacenamiento en caché de prompts debería ayudar mucho. No lo hace, al menos no de la forma que cabría esperar.

El almacenamiento en caché de prompts funciona por coincidencia exacta de prefijo, y cada sesión de agente es independiente. 125 agentes significan 125 sesiones independientes, cada una con una descripción de tarea distinta (datos de candidato diferentes), así que una caché escrita por el agente A no puede ser aprovechada por el agente B. La caché sí ayuda dentro de la ejecución multi-turno de cada agente individual (leer criterios → visitar GitHub → visitar portafolio → generar salida, releyendo contenido anterior en cada ronda).

Esto revela una compensación arquitectónica: el paralelismo en abanico multiplica los costes de escritura en caché (cada agente construye su propia caché), pero a cambio se obtiene un juicio aislado y no contaminado, y se elimina la acumulación cuadrática de contexto propia del procesamiento secuencial. Para tareas sensibles a la calidad del juicio, esa compensación merece la pena.

Cómo pensar en el retorno de la inversión

Comparación directa con la revisión manual: un responsable de contratación que lee un currículum con atención, comprueba el GitHub y escribe notas —de forma conservadora, entre 5 y 10 minutos por candidato—. En 115 candidatos, eso son entre 10 y 19 horas de trabajo concentrado, con el estándar desviándose durante todo el proceso.

Este flujo de trabajo ofreció:

Pero el retorno más importante es de atención: redirigió el foco humano lejos de los 83 candidatos claramente no aptos y hacia los 6 constructores genuinos en la parte alta. Eso es lo más valioso que puede aportar una selección inicial.

¿Podría ser más barato?

Sí, pero probablemente no haga falta. Si esto se convirtiera en una operación de alta frecuencia y alto volumen (cientos de candidatos al día), la optimización práctica sería:

• Usar Sonnet para la fase de puntuación y Opus solo para la revisión adversarial, con una reducción de coste probablemente de entre el 70 y el 80% y una pérdida mínima de calidad.
• O usar un modelo más económico para una primera pasada rápida, y reservar Opus para la evaluación detallada del grupo superior.

Pero la contratación es de baja frecuencia, alto riesgo y difícil de deshacer. Con 65 $ para procesar todo el proceso con auditabilidad completa y criterios iterables, la conclusión es clara: usa el mejor modelo. No sacrifiques la calidad del juicio por un ahorro marginal de coste.

El panorama general

Lo verdaderamente emocionante de este experimento no es "la IA puede seleccionar currículums"; eso no es una idea nueva. Es que el modelo de flujo de trabajo dinámico —código que orquesta una flota de agentes de IA— hace que ciertas categorías de trabajo sean, por primera vez, estructurables, reproducibles e iterables.

La contratación es solo el punto de entrada. El mismo patrón —criterios como archivos legibles + evaluación paralela en abanico + revisión adversarial + agregación determinista— se traslada a cualquier ámbito donde se necesite emitir juicios subjetivos coherentes y de alto volumen: moderación de contenido, revisión de código, clasificación de comentarios de usuarios, análisis competitivo, diligencia debida.

La rúbrica es la v0.1. No es perfecta. Pero ahora es un activo versionado, debatible y mejorable, no un acuerdo implícito que vive en la cabeza de alguien. Ese cambio, más que cualquier resultado individual, es de lo que trataba realmente este experimento.