Trampas con IA en entrevistas técnicas

La evaluación de código a prueba de IA es un espejismo

German Reyes
German Reyes·20 jul 2026·6 min de lectura
En esta página

Busca "evaluación de código a prueba de IA" ahora mismo y vas a encontrar toda una categoría de producto vendiéndote la misma promesa: una prueba que la IA no puede resolver, para que vuelvas a confiar en la puntuación. Codility anunció una biblioteca de tareas a prueba de IA. CodeSignal lanzó evaluaciones agénticas. Incluso Anthropic, cuyo trabajo entero es construir los modelos que hacen la "trampa", corre un take-home para sus propios ingenieros de rendimiento. Dirijo una empresa de evaluaciones, así que sigo de cerca esta categoría, y creo que la promesa es un espejismo. No porque los proveedores sean flojos, sino porque "resistente" es un estado que vence cada vez que sale un modelo nuevo. Si estás evaluando comprar una este trimestre, este es el argumento para comprar otra cosa.

La prueba de código a prueba de IA tiene fecha de caducidad

Una evaluación a prueba de IA se apoya en un supuesto: que puedes diseñar un problema tan difícil que los modelos actuales fallen, y que el problema siga siendo difícil. La primera mitad es posible. La segunda es donde se cae.

Este es el detalle al que sigo volviendo. El equipo de ingeniería de rendimiento de Anthropic escribió públicamente sobre su take-home, donde los candidatos optimizan código para un acelerador simulado. Más de mil personas lo han hecho. Y han tenido que rediseñarlo tras cada versión de Claude, porque el modelo más nuevo le pasaba por encima a la prueba anterior. Su propio relato describe a Claude Opus 4 superando a la mayoría de los postulantes humanos en él.

Detente en eso. Una empresa que construye modelos de frontera, con todos los incentivos y todo el conocimiento interno para mantener una prueba por delante, aun así tiene que reconstruirla cada pocos meses. Ahora imagina a un proveedor vendiéndole un banco de preguntas estático a unos cientos de clientes. ¿Qué probabilidad hay de que su biblioteca se mantenga por delante de la siguiente versión? La resistencia que compras es real por un tiempo y desaparece con el siguiente modelo.

El proctoring no puede prevenir las trampas con IA de forma confiable

La otra mitad del argumento a prueba de IA es la vigilancia. Detección de pegado, análisis de tecleo, proctoring por webcam, puntuaciones de perplejidad que dicen saber si un humano escribió el código. Aquí es donde la categoría deja de ser meramente inútil y empieza a ser dañina.

La detección de pegado muere en el segundo en que un candidato teclea en lugar de pegar. El análisis de tecleo marca como sospechosos a los que escriben rápido y a los neurodivergentes. El proctoring empuja en silencio a tus candidatos más fuertes fuera del embudo, porque cualquiera con opciones no quiere que lo filmen por webcam durante una hora para probar que no hizo trampa. Así que terminas con un filtro que acusa a la gente que quieres y deja pasar a los motivados que se molestaron en esquivarlo. Eso no es tanto un filtro como un impuesto sobre los candidatos que menos te puedes permitir perder.

Permite la herramienta y observa cómo la usan

Una aclaración rápida antes de seguir. Estoy construyendo Skillvee, una simulación de 60 minutos de un "día de trabajo" que reemplaza el filtro telefónico del recruiter y la primera ronda técnica. Los candidatos resuelven un desafío real, hablan con compañeros de IA y defienden sus decisiones ante un gerente de IA mientras se graba la pantalla. Así que tengo un interés en que rechaces el marco de "a prueba de IA". El argumento se sostiene solo, pero deberías saber que el sesgo está ahí.

Así que dale la vuelta a la pregunta. En lugar de "¿puede esta prueba dejar la IA afuera?", pregunta "¿qué tan bien trabaja esta persona con IA?". Una vez que la IA está permitida y la sesión queda grabada, la carrera armamentista simplemente termina. No hay nada que detectar, porque nada está prohibido. Y lo que obtienes en cambio es la señal que de verdad predice el trabajo hoy: el criterio frente a la máquina.

Ver sesiones reales me enseñó algo que no esperaba. La IA no comprime el rango entre candidatos. Lo estira. Dale a todos el mismo modelo y la brecha entre tus mejores y peores postulantes se hace más grande. Un candidato débil toma la primera respuesta del modelo y la entrega. Uno fuerte trata al modelo como a un junior rápido y seguro que a veces miente: escribe prompts con precisión, atrapa la sugerencia plausible pero incorrecta, y puede decirte después por qué la versión final se ve como se ve. Un detector no puede ver nada de eso. Peor aún, lee al candidato fuerte como más sospechoso, porque usó más la herramienta.

A prueba de IA vs aprovechamiento de IA, lado a lado

Los dos enfoques apuntan en direcciones opuestas. Uno gasta su esfuerzo en dejar la IA afuera. El otro lo gasta en observar cómo se usa la IA.

Evaluación a prueba de IAEvaluación de aprovechamiento de IA
Supuesto centralPuedes diseñar pruebas que la IA no resuelvaLa IA es parte del trabajo, así que hazla parte de la prueba
Qué mideSi el candidato evitó una herramienta prohibidaQué tan bien dirige el candidato la herramienta
Vida útilSe reinicia con cada nuevo modeloSe vuelve más predictiva a medida que mejoran los modelos
Efecto en los candidatosLa vigilancia expulsa a la gente fuerteTarea realista, sin acusación
Modo de fallaFalsos positivos con tus mejores candidatosNecesita una rúbrica y alguien que observe el trabajo

Ninguna columna es gratis. La correcta solo apunta a la pregunta duradera en lugar de a la que vence. Escribí la versión completa de este argumento en por qué detectar trampas con IA es la pregunta equivocada, y el postmortem del take-home cubre la misma falla desde el lado del formato.

Cómo evaluar una promesa de "a prueba de IA"

Si todavía estás evaluando proveedores en esta categoría, no tomes la etiqueta al pie de la letra. Tres preguntas separan el trabajo real del marketing:

  1. ¿Cada cuánto refrescan el banco de preguntas, y qué lo dispara? Si la respuesta no es "con cada modelo importante, de forma automática", la resistencia ya se está degradando.
  2. ¿Cuál es su tasa de falsos positivos en la detección de IA, y cómo la miden? Un proveedor que no puede responder esto está enviando acusaciones que no ha validado contra tus mejores candidatos.
  3. ¿Qué pasa cuando un candidato teclea de nuevo el output de la IA en lugar de pegarlo? Si toda la historia de detección se cae con ese movimiento, ya sabes qué tan profundo es el foso.

Las respuestas suelen revelar que estás comprando la apariencia de resistencia, con el precio de la real.

Dónde se pone difícil

No voy a fingir que la alternativa no cuesta esfuerzo. Medir el aprovechamiento de IA implica diseñar una tarea realista con suficiente ambigüedad para que el criterio de verdad aparezca, y una simulación floja es solo un take-home con pasos extra. También necesitas una rúbrica escrita, porque un solo manager evaluando una grabación a ojo se va a ir hacia las vibras. Y alguien de tu lado tiene que ver el trabajo o leer el informe, o construiste una señal que nadie consume.

Esa es una decisión real de construir versus comprar, y deberías tomarla con los ojos bien abiertos respecto al ancho de banda de tu equipo. Lo que no es, es una carrera perdida. Estás midiendo algo que se mantiene cierto entre versiones de modelos: cómo trabaja esta persona cuando la herramienta que todos ahora usan está ahí mismo. Esa es la apuesta detrás de cómo Skillvee puntúa una sesión, y es la razón de que nuestros precios sean por volumen y no por asiento con proctoring. La resistencia grava lo equivocado. Ver a la gente trabajar es el punto.

Preguntas frecuentes

¿Existe algo como una evaluación de código a prueba de IA?
Solo de forma temporal. Una prueba que hoy frena a los modelos puede rediseñarse para frenarlos, pero la siguiente versión suele resolverla, así que la resistencia dura poco. Anthropic escribió públicamente sobre rediseñar su propio take-home tras cada versión de Claude, porque el modelo más nuevo superaba a la prueba anterior. Si una empresa que construye modelos de frontera no puede mantener una prueba por delante de sus propias versiones, un proveedor que te vende una prueba estática tampoco puede.
¿Cómo hago que una prueba de código sea a prueba de IA?
En la mayoría de los casos no puedes, y perseguirlo te cuesta buenos candidatos por el proctoring y las acusaciones falsas. La jugada duradera es la contraria: permite la IA, graba la sesión y puntúa cómo dirige el candidato la herramienta. Qué pregunta, en qué output confía, qué corrige y cómo lo explica. Esa señal se vuelve más predictiva a medida que los modelos mejoran, no menos.
Si dejo que los candidatos usen IA, ¿cómo sigo evaluando la capacidad de programar?
Sigues viendo el código que entregan y el razonamiento detrás. Ver a alguien trabajar con IA muestra su criterio técnico con más nitidez que una prueba de laboratorio, porque ves qué sugerencias rechaza y por qué. La calidad del código es una dimensión a puntuar, junto con comunicación, colaboración, autonomía y aprovechamiento de IA.
¿Los proveedores de evaluaciones a prueba de IA sirven de algo?
Sus funciones de detección atrapan los casos flojos y no detectan a los motivados, que es el intercambio equivocado para un filtro de contratación. Un proveedor que invierte en problemas más difíciles hace trabajo real, pero estás comprando una promesa con fecha de caducidad atada al siguiente modelo. Pregunta cada cuánto rediseñan su banco de preguntas y qué pasa con tus datos entre rediseños.
¿Qué debo preguntarle a un proveedor que dice que su prueba es a prueba de IA?
Pregunta tres cosas. Cada cuánto refrescan el banco de preguntas y qué lo dispara. Cuál es su tasa de falsos positivos en la detección de IA y cómo la miden. Y qué pasa cuando un candidato simplemente teclea de nuevo el output de la IA en lugar de pegarlo. Las respuestas te dicen si estás comprando resistencia o su apariencia.
Evaluación de código a prueba de IA: un espejismo