La crisis de la 'programación por vibraciones': Por qué los graduados de CS ya no pueden programar sin IA

En un hilo de Reddit de marzo de 2026 que superó rápidamente los 8,000 votos a favor, un ingeniero senior en una startup en etapa de Serie B publicó capturas de pantalla de una entrevista técnica para llevar a casa que acababa de rechazar. El candidato, un graduado reciente de CS con un GPA de 3.9 de un programa respetado, había entregado código que se ejecutaba perfectamente en el camino feliz y corrompía datos silenciosamente en cada caso extremo. Cuando se le pidió que explicara la lógica en una llamada de seguimiento, el candidato no pudo explicar por qué una de sus propias funciones utilizaba recursividad. La línea que rompió el hilo fue su respuesta honesta: “Solo le dije a Claude lo que necesitábamos y escribió esto. Por lo general, solo leo el código si no funciona”.

Esta es la crisis de la programación por vibraciones y, para 2026, ha migrado de Twitter de desarrolladores a las líneas de contratación de recursos humanos, debates de contratación y cada vez más a las oficinas de los directores de departamento de CS que intentan descubrir qué les sucedió a sus graduados. El término fue acuñado por Andrej Karpathy en febrero de 2025 para describir un nuevo modo positivo de trabajar: describe su intención, acepta lo que produce el modelo, envía. En un año, la misma frase se convirtió en la abreviatura del campo para una generación de programadores que pueden escribir instrucciones con fluidez pero no pueden razonar sobre lo que realmente hace su código.

Para los educadores de programación, este no es un problema hipotético sobre el futuro del trabajo. Es una emergencia pedagógica en tiempo presente sobre los estudiantes que se están graduando en este momento. Este artículo analiza lo que muestran las investigaciones y los informes de campo sobre la atrofia de habilidades inducida por la IA, por qué CS1 hasta el proyecto final de último año es excepcionalmente vulnerable, y cómo un grupo pequeño pero creciente de educadores está reestructurando los cursos para garantizar que los estudiantes se gradúen sabiendo programar — no solo sabiendo dar instrucciones.

Lo que realmente significa la programación por vibraciones (y por qué Karpathy dijo que debería ser divertido)

El encuadre original de Karpathy fue específico. La programación por vibraciones significaba aceptar que la programación para proyectos personales ahora podía sentirse como un juego creativo: le dices al modelo lo que quieres, produce código, ajustas la instrucción en lugar del código y envías algo que funciona. Señaló explícitamente que ya no leía el código línea por línea para sus propios proyectos paralelos. El encuadre trataba sobre el disfrute, la productividad y la observación legítima de que, para el código desechable de bajo riesgo, la revisión manual cuidadosa es exagerada.

Luego, el término se escapó al campo más amplio, donde aterrizó en dos contextos muy diferentes:

• Ingenieros senior usándolo deliberadamente: Tratando el código generado por IA como un borrador, leyéndolo y refactorizándolo antes de confirmarlo, usando la IA para omitir la plantilla pero aplicando décadas de reconocimiento de patrones para evaluar la salida. Esto es lo que describía Karpathy, y funciona.
• Ingenieros junior y estudiantes adoptándolo como su modo predeterminado: Tratando el código generado por IA como un artefacto terminado, aceptándolo sin leer, depurando solo cuando las pruebas fallan, escalando a un senior o instructor solo cuando la IA no puede corregir su propia salida. Esto es lo que Karpathy no estaba describiendo, y no funciona.

El problema pedagógico es el segundo grupo, y constituyen la mayoría de los estudiantes que ingresan a los programas de CS en 2026. El propio Karpathy retiró su encuadre más adelante en 2025, señalando que la programación por vibraciones tiene sentido para expertos en proyectos personales y es corrosiva para todos los demás.

El patrón de atrofia de habilidades en números reales

La evidencia es ahora sustancial y apunta en una dirección. Un análisis de diciembre de 2025 publicado por CodeRabbit, que examinó las solicitudes de extracción en cientos de repositorios de código abierto, encontró que el código coescrito por IA generativa contenía aproximadamente 1.7 veces más problemas “importantes” que el código escrito por humanos. Los errores de lógica (dependencias incorrectas, flujo de control defectuoso) y las vulnerabilidades de seguridad estaban significativamente elevados, y los defectos de seguridad aparecieron a 2.74 veces la tasa de código solo humano.

Un informe de TechSpot a fines de 2025 encuestó a desarrolladores en activo sobre los efectos cognitivos de los flujos de trabajo de programación por vibraciones forzados. El patrón común reportado: aumento del tiempo de depuración, disminución de la capacidad de simular mentalmente el código y deterioro de la intuición sobre cómo se ve el código de calidad de producción. Un desarrollador describió su experiencia después de seis meses de trabajo en los que la vibración era lo primero como “perder la memoria muscular” para la resolución de problemas por completo.

La ilustración más clara provino de un desarrollador que realizó un experimento de 30 días a principios de 2026: no recibir asistencia de IA durante un mes y luego reflexionar sobre la diferencia. El artículo de dev.to, Programé sin IA durante 30 días: los resultados fueron vergonzosos, se convirtió en uno de los ensayos de desarrolladores más compartidos del año. El hallazgo principal: un ingeniero senior en activo con ocho años de experiencia ya no podía escribir un recorrido de árbol binario simple de memoria. La habilidad se había subcontratado y luego se había erosionado silenciosamente.

Si la fuerza muscular de depuración de un ingeniero senior en activo se deteriora a los pocos meses de la dependencia de la IA, imagine la trayectoria de un estudiante de CS1 que nunca ha tenido ese músculo en primer lugar — cuya experiencia completa de programación ha sido mediada a través de un LLM que produce una solución funcional a los diez segundos de ver el enunciado del problema.

Por qué la educación en programación es excepcionalmente vulnerable

Otros campos están haciendo frente a la IA en la educación de manera imperfecta, pero la mayoría todavía tiene marcos de evaluación intactos. A un estudiante de literatura se le puede pedir que discuta un pasaje en un seminario. A un estudiante de química se le puede pedir que realice un procedimiento de laboratorio. A un estudiante de matemáticas se le puede pedir que derive una prueba en una pizarra. La educación en programación no tiene ninguno de estos modos de evaluación intactos. Casi todas las tareas de programación se realizan para llevar a casa, evaluadas por si el código aprueba las pruebas — y una IA de 2026 las aprueba de forma trivial.

Esto crea tres vulnerabilidades que son específicas de la programación:

• El ciclo de la tarea-prueba es totalmente automatizable. Codex, Claude Code y Cursor leen la tarea, escriben el código, ejecutan la suite de pruebas, iteran sobre las fallas y entregan una solución funcional. El ciclo completo que se supone que debe realizar un estudiante — comprender los requisitos, diseñar una solución, implementarla, depurarla — puede ser realizado por la IA más rápido de lo que el estudiante puede leer la especificación.
• La evaluación en vivo es logísticamente costosa. Una clase de CS1 de 200 estudiantes no puede realizar de manera realista una defensa oral de cinco minutos en cada tarea sin consumir veinte horas de tiempo de los asistentes de enseñanza por ciclo de tarea. El modelo económico de los cursos grandes de CS asume una calificación asincrónica para llevar a casa.
• La trampa es invisible para el estudiante. Un estudiante que copia un ensayo sabe que hizo trampa. Un estudiante que le da instrucciones a una IA para resolver una tarea puede no registrarlo como trampa — la norma social ha cambiado más rápido que la política, y el acto se siente indistinguible de buscar algo. Para cuando llegan al último año y necesitan pensar por sí mismos, han pasado cuatro años sin construir ninguna habilidad relevante.

El resultado es un canal de graduación que produce estudiantes con credenciales que ya no se correlacionan con la habilidad. Los gerentes de contratación en 2026 están superando cada vez más el currículum y el GPA en favor de la evaluación técnica en vivo, exactamente porque el sistema de credenciales se ha desacoplado de la capacidad subyacente.

Cómo se ve “no aprender nada” en las horas de oficina de CS

Si enseña programación, probablemente haya visto este patrón, incluso si aún no le ha puesto nombre. Hemos recopilado las señales de diagnóstico más comunes de los instructores en CS1, estructuras de datos y cursos de proyectos finales de último año a fines de 2025 y principios de 2026.

• El estudiante no puede encontrar su propio error. La entrega se ejecutó perfectamente. Falla una nueva prueba unitaria. El estudiante abre el archivo, mira el código como si lo viera por primera vez, se desplaza hacia arriba y hacia abajo sin una hipótesis, y finalmente dice: “Solo le preguntaré a Claude qué está mal”. La primera reacción a una prueba fallida es escalar a la IA en lugar de formar una hipótesis.
• El estudiante no puede responder “por qué”. Ante la pregunta “por qué usó un mapa de hash aquí en lugar de una matriz”, la respuesta es “eso es lo que sugirió la IA”. La elección se hizo; el razonamiento detrás de ella nunca se internalizó. No hay un modelo cognitivo debajo del código.
• El estudiante no puede hacer una pequeña variante. “Modifique esto para manejar también números negativos” debería ser una edición de treinta segundos. Para el estudiante dependiente de la IA, se convierte en una sesión de instrucción de cinco minutos porque necesita alimentar la restricción de regreso al modelo en lugar de pensar dónde debe ir la modificación en el código existente.
• El estudiante tiene fluidez en las herramientas, analfabeto en problemas. Pueden configurar Vercel, construir un componente React, configurar una base de datos Postgres, implementar con Docker. Pueden usar toda la cadena de herramientas moderna. Pídales que implementen quicksort. Silencio.
• La revelación del proyecto final. El proyecto final de último año, el momento en que la habilidad acumulada debería dar sus frutos, es cada vez más un momento en el que se revela la ausencia acumulada de habilidad. Los equipos que abrieron camino a través de la programación por vibraciones en CS1 hasta el penúltimo año llegan al proyecto final incapaces de diseñar un sistema, incapaces de desglosar una función, incapaces de manejar las partes de la programación que la IA hace peor.

La solución pedagógica: tratar la fluidez en IA como una habilidad real (y hacerla merecida)

Los educadores que están manejando bien esta transición no son los que tienen las políticas más estrictas de no IA. Son los que han reconstruido los cursos en torno a una distinción clara: la IA es una herramienta que los estudiantes deben aprender a usar bien, Y los estudiantes deben demostrar de forma independiente las habilidades cognitivas que ejercita la IA. Los dos requisitos no están en tensión — son complementarios, y los cursos que hacen esto bien producen graduados que superan tanto a los programadores por vibración como a las cohortes con prohibición de IA.

Los patrones de diseño específicos que vemos funcionar en los cursos de programación de 2026:

• 1. La tarea de doble vía. Cada tarea tiene una parte “en solitario” (no se permite IA, a menudo un pequeño componente en clase) y una parte de “herramientas” (se permite IA pero se documenta). La parte en solitario atrapa lo que el estudiante realmente puede hacer. La parte de herramientas les enseña a hacer más.
• 2. La fluidez en IA como competencia calificada. Los estudiantes entregan las instrucciones de IA que usaron, las respuestas que obtuvieron y un análisis de dónde la IA estuvo equivocada o fue ineficiente. Leer críticamente la salida de la IA se trata como un objetivo del curso, no como una solución alternativa.
• 3. Evaluaciones solo de depuración. A los estudiantes se les da código generado por IA que funciona con errores sutiles (diferencia de uno, caso base incorrecto, verificación nula faltante, vulnerabilidad de seguridad) y se les califica según su capacidad para encontrarlos y corregirlos. Esto entrena la habilidad que la IA realiza de peor manera y que los empleadores más valoran.
• 4. Calificación con proceso visible. Historial de confirmación requerido, comentarios obligatorios que documentan las decisiones de diseño, tutoriales grabados. El artefacto por sí solo ya no es la calificación completa.
• 5. Conversaciones técnicas en vivo. Un componente oral corto y estructurado en cada tarea significativa. Cinco minutos por estudiante, centrado en una o dos preguntas de diagnóstico. La fricción es real; la señal es excelente.
• 6. Verificación de autenticidad a nivel de sistema. Herramientas como Plagly.ai escanean las entregas en busca de patrones de generación de IA, uniformidad estilística a nivel de cohorte y la ausencia de los rastros de autoría iterativos que suele exhibir el trabajo real de los estudiantes. Esta no es la calificación; es una marca que presenta las entregas que vale la pena conversar en las horas de oficina.

La capa de herramientas que lo hace práctico

La mayor objeción al modelo anterior es logística. Las clases reales tienen cientos de estudiantes; los instructores reales no tienen tiempo para leer cada entrega línea por línea, realizar una defensa oral de cada tarea o notar patrones a nivel de cohorte a simple vista. Las herramientas deben hacer el escaneo de superficie para que el humano pueda aplicar su juicio a los casos que importan.

Cómo se ve esto en la práctica para una sección de CS1 de 200 estudiantes:

• Escaneo automático de entregas: Cada archivo cargado pasa por una fase de detección de IA que devuelve una puntuación de confianza y marcas por bloque. Plagly.ai realiza este análisis con un 99% de precisión en GPT-5.5, Claude 4.6, Gemini 3.1 y otros modelos importantes, incluidas las variantes de código específicas que prefieren esos modelos.
• Panel de control a nivel de cohorte: El instructor ve una agrupación de patrones estilísticos en toda la sección. Cuando ocho entregas comparten frases idiomáticas, densidad de comentarios idéntica y el mismo patrón de caso extremo defensivo, el grupo surge para su revisión.
• Rastros de autoría: El Agentic Council de Plagly.ai — siete modelos de expertos en el dominio que analizan la entrega en cuanto a calidad de escritura, estructura, detección de IA, originalidad y consistencia — produce un informe referenciado. El informe no afirma la deshonestidad académica; documenta los patrones que el instructor puede investigar.
• Conversaciones dirigidas en horas de oficina: Los estudiantes cuyas entregas surgen reciben el control oral de cinco minutos. La mayoría se aclaran rápidamente; el pequeño número que no lo hace se convierte en los casos que el instructor maneja con cuidado y de manera registrada.

El punto no es atrapar a todos los tramposos. El punto es mantener intacto el ciclo de aprendizaje para los estudiantes que quieren aprender. Una clase sin verificación es una clase en la que los estudiantes que juegan con el sistema marcan la pauta y los estudiantes que trabajan honestamente se convierten en los tontos. Una clase con verificación es una clase en la que se mantiene la norma social — las tareas todavía enseñan, las calificaciones todavía significan algo y los graduados todavía pueden programar.

La perspectiva de 18 meses para la educación en programación

La mayoría de los educadores de programación en activo con los que hablamos en 2026 comparten la sensación de que la configuración actual es inestable. La tarea para llevar a casa evaluada por la aprobación de las pruebas es estructuralmente incompatible con la existencia de herramientas de codificación de agentes. Algo tiene que ceder. Tres direcciones plausibles, en orden aproximado de mayor probabilidad:

• Prohibiciones completas de IA: Algunas instituciones lo intentarán y la mayoría fallará. Las prohibiciones son inaplicables, las políticas se vuelven inconsistentes y los estudiantes que siguen las reglas se gradúan menos capacitados que los estudiantes que no lo hacen. Este es el resultado del peor de los mundos y ya se ha desacreditado en varias universidades que lo intentaron en 2023-2024.
• Cambio de capacidad hacia abajo en el plan de estudios: CS1 comienza más tarde, con más énfasis en los fundamentos conceptuales. CS2 cubre lo que solía cubrir CS1. Los cursos avanzados se vuelven más teóricos porque la parte de implementación ya no es donde ocurre el aprendizaje. Esto está sucediendo, lentamente.
• Cambio de evaluación hacia la demostración en vivo: Las tareas para llevar a casa se vuelven formativas. Las calificaciones sumativas se determinan mediante codificación en vivo bajo supervisión, defensas orales y trabajo con proceso visible. Esta es la dirección en la que ya se están moviendo los programas de CS más sólidos, y es la dirección en la que creemos que la mayoría de los programas se establecerán eventualmente.

Ninguno de estos resultados resuelve la cuestión de qué hacer este semestre, con los estudiantes que tiene. Para eso, el movimiento práctico es híbrido: mantenga sus tareas actuales, agregue una capa de verificación que atrape los peores casos, agregue uno o dos componentes de evaluación en persona por curso y comience el trabajo más lento de rediseñar el plan de estudios para un mundo donde la IA de agentes es la línea de base. Las herramientas de verificación le compran tiempo para realizar el rediseño del plan de estudios sin perder esta cohorte debido a la programación por vibraciones en el ínterin.

Preguntas frecuentes

¿Es la programación por vibraciones siempre mala, o es a veces legítima?

Es legítima para desarrolladores experimentados que trabajan en proyectos personales de bajo riesgo donde el costo de los errores es bajo y el desarrollador tiene la habilidad subyacente para evaluar el resultado cuando importa. Es corrosivo para los estudiantes que todavía están construyendo la habilidad subyacente, porque interrumpe el trabajo cognitivo que se supone que debe desarrollar la educación en programación. La distinción es aproximadamente la misma que la distinción entre un chef que pide comida para llevar (bien) y un estudiante de cocina que pide comida para llevar para su examen final (no bien). Ambos implican recibir comida que no cocinaron. Solo uno socava el proyecto de aprendizaje.

¿Pueden los estudiantes afirmar que escribieron ellos mismos el código detectado por IA?

Pueden, y a veces tienen razón. Los falsos positivos en la detección de código son más comunes cuando los estudiantes escriben un código muy tipo libro de texto que coincide con los patrones que la IA suele producir. El flujo de trabajo defendible no trata una puntuación de detección como un veredicto — lo trata como una invitación a una conversación de cinco minutos. Un estudiante que escribió su propio código puede explicarlo, modificarlo en el acto y rastrear su ejecución. Un estudiante que lo generó con instrucciones casi nunca puede. La conversación, no la puntuación, es lo que resuelve la pregunta. Los informes de Plagly.ai están diseñados para apoyar esa conversación, no para reemplazarla.

¿En qué se diferencia la detección de IA en código de la detección de IA en prosa?

La detección de código utiliza bases estadísticas similares — perplejidad, ráfaga, huellas dactilares estilísticas — pero las aplica a diferentes características de superficie. En el código, las señales más informativas son estructurales en lugar de léxicas: patrones de nomenclatura de variables, densidad y estilo de comentarios, modismos de uso de bibliotecas, plantillas de manejo de errores y la elección de construcciones idiomáticas. Los detectores de conjuntos de múltiples modelos logran una precisión del 90-95% en entregas de código aisladas en 2026, superando con creces el 95% cuando el análisis de patrones a nivel de cohorte se combina con la puntuación a nivel de archivo.

¿Qué pasa con los estudiantes que realmente usan la IA como tutor sin copiar su salida?

Esta es la población que la capa de verificación está explícitamente diseñada para no penalizar. Un estudiante que usó la IA para comprender un concepto, luego escribió su propia solución, produce un código que no coincide con los patrones de generación de la IA a nivel de línea. Las señales de detección atrapan el artefacto, no el proceso de investigación. Si la política de su curso permite la IA como tutora — y creemos que debería — el flujo de trabajo sigue funcionando. Está comprobando la entrega, no el método de aprendizaje del estudiante.

¿Funciona esto para cursos basados en proyectos y proyectos finales?

Sí, con adaptación. Para el trabajo de proyectos de varias semanas y múltiples archivos, las señales más útiles cambian hacia la visibilidad del proceso: análisis del historial de confirmación (¿apareció el código en una gran confirmación o evolucionó con el tiempo?), consistencia de la autoría en todos los archivos (¿se lee la base de código como si la hubiera escrito una sola persona o como si se hubieran cosido diferentes parches?), y documentación de decisiones de diseño (¿puede el estudiante explicar por qué se tomaron decisiones arquitectónicas específicas?). Los proyectos de estilo proyecto final se benefician más de una defensa oral estructurada más una justificación de diseño escrita, con la detección de IA como una señal terciaria en lugar de la primaria.