El programador performativo en la era de la IA y el costo para tu organización

Cuando la demostración de productividad se aleja del trabajo necesario para entregar una solución confiable

Imagina la escena. Una persona comparte su pantalla, muestra un sistema atractivo y anuncia que lo construyó todo en pocas horas. Hay un panel, gráficos, animaciones, integración con IA y una presentación que parece salida de una startup a punto de recibir inversión.

La reunión se anima. Alguien ya empieza a calcular cuántas personas podrían ser reemplazadas por semejante eficiencia.

Entonces surge una pregunta: ¿quién puede acceder a los datos de quién?

Silencio. La demostración estaba preparada para mostrar lo que sucede cuando todo sale bien. Esa parte todavía no había entrado en el guion.

Esta escena imaginaria ayuda a llevar al interior de las organizaciones una provocación que Mano Deyvin hizo sobre el «programador performativo». Su nombre es Deyvid Nascimento, un desarrollador que se presenta como la persona detrás de @manodeyvin y trabaja con Rails. [1]

Mano Deyvin… ¿o sería primo Deyvin? Yo también llevo el apellido Nascimento y mi familia es gigantesca. Quién sabe si esta investigación acaba en un asado familiar, jeje.

En las redes, bromeó con las señas de identidad del programador y también con el «vibe coder performativo», incluyendo la exhibición de equipos, herramientas y consumo de IA. La conversación se convirtió en un tema de su Mano Rage Show. [2][3]

Quiero aprovechar esa provocación para hablar de lo que ocurre cuando una organización empieza a comprar la apariencia de competencia como si ya hubiera recibido una entrega confiable.

Mi tesis es que la IA puede reducir el esfuerzo necesario para producir las señales visibles de productividad. Eso hace todavía más importante verificar el trabajo que esas señales representan.

Cuando el trabajo empieza a convertirse en un personaje

Aquí uso «performativo» en el sentido de una puesta en escena profesional. Es el comportamiento de sostener una imagen de dominio, velocidad o importancia que las evidencias de lo entregado no respaldan.

Puede manifestarse en una promesa exagerada, una demostración que omite limitaciones o una tarea declarada terminada mientras otras personas todavía necesitan descubrir cómo hacerla funcionar.

El teclado, el editor de código y la foto de LinkedIn no permiten hacer ese diagnóstico. Crear contenido, explicar decisiones y presentar bien un proyecto son actividades legítimas. Una persona puede hacer todo eso y entregar un trabajo excelente.

También conviene proteger el trabajo que tiene poca visibilidad. Investigar un defecto, orientar a un compañero, simplificar una solución e impedir un cambio peligroso pueden consumir horas sin producir una pantalla nueva para la próxima reunión.

El criterio debe ser la correspondencia entre lo prometido, lo demostrado y lo que la organización recibió realmente.

Un principiante que explica sus límites y pide una revisión permite que el equipo gestione el riesgo. Un profesional experimentado que oculta sus propias incertidumbres puede hacer lo contrario. Los años de experiencia y la cantidad de seguidores no cierran esta conversación.

La IA también ayuda a producir la presentación

Es fácil entender el atractivo de la IA para quien quiere construir. Puedes explorar una idea, pedir alternativas, generar una primera implementación e iterar sobre ella. Eso abre espacio para aprender y experimentar.

Pero esa misma facilidad puede dar un acabado profesional a algo que todavía no se ha comprendido.

Imagina un proyecto cuyo código, documentación, explicación de la arquitectura y pruebas se producen en una misma secuencia de solicitudes. Cada pieza parece confirmar la anterior. El conjunto resulta convincente, aunque todas puedan compartir una premisa equivocada sobre el problema.

Si la persona responsable conoce los límites, verifica las decisiones y corrige los fallos, ese material puede ser muy útil. Si lo acepta todo porque «la IA lo explicó muy bien», la organización obtiene un relato de seguridad antes de contar con evidencias suficientes de ella.

La situación se vuelve especialmente delicada cuando una demostración se convierte en un compromiso comercial. El cliente entiende que compró un sistema listo; quien lo presentó todavía estaba validando una hipótesis.

Un prototipo puede ser una excelente entrega, siempre que se presente como prototipo. La confusión empieza cuando esa diferencia desaparece de la conversación, del plazo y del precio.

La productividad que sentimos y la que podemos medir

Hay investigaciones que muestran cómo puede fallar nuestra percepción al hacer esta evaluación.

En julio de 2025, METR publicó un experimento con 16 desarrolladores experimentados y 246 tareas en proyectos que conocían. Con las herramientas de IA evaluadas, las tareas consumieron un 19% más de tiempo. Incluso después de la experiencia, los participantes estimaban una mejora de velocidad de alrededor del 20%. El estudio refleja ese contexto y herramientas de principios de 2025. [4]

La actualización de febrero de 2026 aportó indicios de mejora, pero la propia METR explicó que la selección de participantes y tareas, entre otros problemas de medición, impedía estimar con confianza el efecto actual. Usar aquel 19% como sentencia sobre toda la programación con IA en 2026 sería extrapolar el resultado. [5]

En mayo de 2026, otra encuesta de METR reunió a 349 trabajadores técnicos y encontró mejoras declaradas por los propios participantes. Los investigadores distinguieron la percepción de velocidad de la del valor producido, además de señalar limitaciones de la muestra y de las estimaciones personales. Este tipo de investigación ayuda a entender la experiencia de las personas, pero no demuestra la mejora mediante una medición directa. [6]

También hay evidencia positiva importante. Tres experimentos empresariales, que reunieron a 4.867 desarrolladores, estimaron un aumento de aproximadamente el 26% en las tareas completadas como efecto de la adopción de GitHub Copilot. La medida se apoyaba principalmente en solicitudes de cambios de código completadas, los pull requests. El artículo se publicó en Management Science en febrero de 2026; sus resultados variaron entre empresas. Ese indicador no equivale automáticamente a beneficios económicos ni a calidad duradera. [7][8]

Estos trabajos estudian condiciones diferentes. Y ninguno identifica una categoría de «programadores performativos» ni calcula cuánto cuesta.

Lo que sí ayudan a respaldar es una exigencia más razonable: debemos observar el resultado, además de la sensación de velocidad.

Alguien puede creer sinceramente que está produciendo mucho más. Incluso puede estar haciéndolo. La responsabilidad de la dirección es crear condiciones para comprobarlo sin depender exclusivamente del entusiasmo de quien presenta o de la desconfianza de quien observa.

El costo que cambia de escritorio

Una manera de parecer extremadamente productivo es dar por terminada la parte propia de una tarea antes de que se haya contabilizado todo el trabajo necesario.

Imagina a alguien que entrega un cambio enorme, celebra el plazo y pasa al siguiente. Otro profesional necesita entender qué cambió, comprobar si el comportamiento tiene sentido, pedir correcciones y averiguar cómo encaja la novedad con el resto del sistema.

Revisar forma parte del desarrollo. El problema aparece cuando la entrega se anunció como terminada y ese esfuerzo pendiente quedó invisible en la cuenta de quien recibió el reconocimiento.

El trabajo puede seguir migrando: del desarrollo a la revisión, de la revisión al soporte, del soporte a quien tiene que explicarle el problema al cliente.

Después viene el mantenimiento. Una decisión que nadie sabe justificar, una dependencia innecesaria o una integración sin gestión de fallos pueden hacer más laboriosos los próximos cambios. La cuenta acompaña al sistema durante mucho más tiempo que el entusiasmo del lanzamiento.

En la presentación, una persona parece haber ahorrado dos días. En la operación, varias personas pueden haber consumido tres para completar lo que faltaba. Esa hipótesis necesita medirse en el proyecto, pero ya muestra por qué evaluar únicamente la velocidad de implementación es insuficiente.

También existe el costo de oportunidad. Mientras un profesional experimentado reconstruye decisiones que deberían estar claras, otra mejora queda esperando. Conviene medir ese retraso con cuidado para no contabilizar la misma pérdida dos veces al sumar horas y oportunidades aplazadas.

La pregunta útil pasa a ser: ¿cuánto esfuerzo tuvo que invertir todo el equipo hasta que esa entrega pudo utilizarse con confianza?

La pantalla atractiva y el administrador por contraseña mágica

Ya me he encontrado con una situación en la que la condición para que alguien fuera administrador se reducía a comprobar si la contraseña era admin123.

Esa era la lógica utilizada para definir el acceso administrativo. Una regla así puede parecer que funciona en una demostración: alguien introduce la contraseña y se abre el panel. Pero el éxito de la demostración no convierte ese control de acceso en uno adecuado.

El caso, por sí solo, no permite concluir que una IA escribió el código ni que su autor intentó engañar a nadie. Ilustra cómo se puede demostrar una funcionalidad sin resolver correctamente la responsabilidad que conlleva.

Las recomendaciones de OWASP sobre autorización incluyen conceder únicamente los privilegios necesarios, denegar el acceso de forma predeterminada y verificar los permisos en cada solicitud. La validación debe producirse en un componente confiable del sistema; ocultar un botón en el navegador no basta. [9]

Para una organización, las posibles consecuencias de un control inadecuado van más allá de «hay un bug». Pueden incluir accesos indebidos, alteración de registros, interrupción de actividades y trabajo para investigar y corregir la exposición. Su alcance depende de los datos, de los permisos y de lo que realmente haya ocurrido.

En sistemas que apoyan la atención ciudadana, el comercio o las rutinas administrativas, el fallo también puede afectar a personas que nunca participaron en aquella reunión tan animada.

Por eso, una pregunta aparentemente pesada sobre permisos merece espacio antes de los aplausos.

Incluso la prueba necesita demostrar qué está probando

Otro riesgo consiste en tratar una pantalla llena de pruebas superadas como evidencia suficiente de que todo está correcto.

Una prueba puede verificar exactamente el comportamiento implementado y, aun así, dejar sin verificar la regla que el usuario necesitaba. Si el sistema debía impedir una operación, pero la prueba se escribió para confirmar que ocurre, la luz verde sirve de poco.

OWASP advierte sobre agentes que debilitan las comprobaciones o eliminan las pruebas que fallan. También recomienda que las modificaciones generadas con IA tengan una persona responsable. El resultado de la herramienta debe revisarse, incluso cuando ella misma produce su propia validación. [10]

Esto exige preguntas concretas. ¿Qué requisito demuestra la prueba? ¿Qué fallo detectaría? ¿Hay algún escenario importante que haya quedado fuera?

La IA puede ayudar a encontrar esos escenarios. La precaución consiste en mantener una referencia independiente de lo que significa «correcto»: la necesidad del usuario, las reglas del negocio y las restricciones del sistema.

Lo mismo ocurre con la documentación. Un texto elegante sobre la arquitectura adquiere valor cuando corresponde al sistema que otra persona necesitará operar y modificar.

Una simulación para ponerle cifras en reales a esta conversación

Usemos un ejemplo completamente hipotético, con el mismo alcance y el mismo criterio de aceptación. Para simplificar, cada hora de trabajo cuesta R$ 100, independientemente de la función.

Ambas entregas pueden utilizar IA. La comparación siguiente representa una entrega de referencia y otra que se anunció como terminada demasiado pronto.

Trabajo necesario	Entrega de referencia	Entrega anunciada demasiado pronto
Implementación	12 h	4 h
Revisión	3 h	6 h
Correcciones	2 h	10 h
Soporte inicial	1 h	4 h
Total de trabajo	18 h	24 h
Costo de las horas	R$ 1.800	R$ 2.400

Si alguien muestra únicamente la implementación, la segunda entrega parece haber ahorrado R$ 800. Cuando el trabajo restante entra en la cuenta, termina costando R$ 600 más.

Estos valores no son una estimación del mercado. Son una manera de mostrar la cuenta que cada organización debería hacer con sus propios datos. Un uso competente de la IA también puede reducir la revisión, las correcciones y el soporte, mejorando el resultado completo.

El costo real puede incluir además herramientas, infraestructura y consecuencias de incidentes. Cada partida debe calcularse sin mezclar costos ya incurridos con riesgos que quizá nunca se materialicen.

La idea es acompañar la entrega hasta el punto en que pueda confirmarse el ahorro anunciado.

Hay una dirección detrás del espectáculo

Sería cómodo atribuir toda la responsabilidad al profesional que exagera en la presentación. Pero alguien eligió qué señales se iban a premiar.

Si la empresa valora la cantidad de código, las personas tienen un incentivo para producir más código. Si premia las demostraciones constantes, lo que aparece en pantalla gana ventaja sobre el trabajo de mantenimiento que lo sostiene.

Con IA se pueden añadir otros indicadores llamativos: cantidad de agentes, volumen de tokens y porcentaje de código generado automáticamente. Esa información puede ayudar a administrar las herramientas. Por sí sola, dice poco sobre el beneficio entregado al usuario. La captura de la factura demuestra el consumo. El progreso todavía hay que demostrarlo.

El marco SPACE, publicado por investigadores de Microsoft, GitHub y la Universidad de Victoria, aborda la productividad como algo multidimensional. Su propuesta incluye satisfacción y bienestar, desempeño, actividad, comunicación y colaboración, además de eficiencia y flujo de trabajo. Reducirlo todo a un único recuento deja fuera una parte relevante del trabajo. [11]

El DORA 2025 aporta otra perspectiva: presenta la IA como un amplificador de las condiciones existentes en la organización. La retrospectiva oficial señala una mejora en el volumen de entregas, acompañada de un riesgo para la estabilidad cuando la base es frágil. Se trata de investigación organizacional, no de una garantía causal para cualquier equipo. [12][13]

A partir de ello, mi interpretación es que acelerar la generación de cambios sin cuidar la capacidad de evaluarlos puede limitarse a desplazar el cuello de botella. La empresa necesita observar el flujo completo.

A veces, el programador simplemente aprendió a entregar exactamente el espectáculo que la dirección decidió comprar.

Qué conviene preguntar antes de aprobar una entrega

Una organización no necesita convertir cada cambio en una defensa de tesis doctoral. Necesita hacer preguntas proporcionales al riesgo y aceptar respuestas verificables.

Yo empezaría por estas:

1. ¿Qué problema se resolvió para quien lo usa? Una funcionalidad disponible todavía necesita demostrar su utilidad. Conviene observar una tarea real: ¿se volvió más rápida, más clara o menos propensa a errores?
2. ¿Qué está listo y qué sigue siendo una hipótesis? Un prototipo, un piloto y una operación con usuarios reales exigen compromisos diferentes. Esa distinción debe estar clara tanto para quien contrata como para quien va a mantener el sistema.
3. ¿Cómo se verificaron los accesos, los datos y los fallos importantes? La profundidad cambia según el sistema. Un formulario informativo y un proceso que modifica pagos requieren cuidados diferentes.
4. ¿Qué trabajo quedó todavía para otras personas? La revisión, la integración, la documentación y el soporte deben figurar en la planificación y en la evaluación del resultado.
5. ¿Otra persona puede continuar a partir de aquí? La persona responsable debe poder mostrar decisiones, dependencias y limitaciones. La explicación puede ser escrita o demostrada; no necesita convertirse en una competencia de elocuencia durante una reunión.
6. ¿Cómo detectaremos y corregiremos un problema después de la entrega? Según el riesgo, esto implica registros, seguimiento, reversión de cambios y recuperación de la operación.

Estas preguntas también ayudan a contratar. En lugar de premiar únicamente la presentación más impresionante, se puede observar cómo la persona afronta una limitación, explica una elección e incorpora una revisión.

Para seguir el trabajo, combinaría el tiempo que tarda un cambio en llegar al usuario con el trabajo que hay que rehacer, los fallos relevantes, el esfuerzo de mantenimiento y el resultado del servicio. Compararía períodos y entregas similares, teniendo en cuenta la complejidad y la madurez del sistema.

Convertir esos datos en una clasificación automática de empleados recrearía el problema. Su uso más útil consiste en descubrir dónde funciona el proceso y dónde se está ocultando el costo.

La oportunidad sigue siendo enorme

Hay mucho margen para construir mejor con IA. Puede ayudar a quienes empiezan, ampliar la capacidad de profesionales experimentados y hacer viables experimentos que antes habrían consumido demasiados recursos.

Para aprovecharlo, una organización necesita permitir el aprendizaje y admitir la incertidumbre. Si toda duda se trata como incompetencia, la empresa fomenta precisamente la confianza teatral que después se quejará de recibir.

Quiero trabajar con personas capaces de decir «esta parte está validada; esta otra necesita revisión». Esa claridad permite decidir plazos, riesgos y prioridades de una manera más responsable.

Es perfectamente posible utilizar varias IA, presentar bien un proyecto y entregar valor. También es posible hacerlo con una estructura discreta y pocas herramientas. La prueba está en el resultado que la organización puede utilizar, mantener y entender.

Al primo Deyvin le corresponde el crédito por la provocación. El parentesco lo investigamos después.

Para quien contrata tecnología, dejaría una pregunta en la próxima presentación: ¿cuánto trabajo queda después de esta demostración y quién va a asumir esa cuenta?

Fuentes

[1] Deyvid Nascimento. Sitio personal. Identificación y presentación profesional.

[2] Mano Deyvin. Publicación sobre el vibe coder performativo. Publicación en el perfil del autor.

[3] Mano Deyvin. Publicación que anuncia el tema del episodio 262. Episodio Programadores Performáticos de Mano Rage Show.

[4] METR. Measuring the Impact of Early 2025 AI on Experienced Open Source Developer Productivity. 10 de julio de 2025.

[5] METR. We are Changing our Developer Productivity Experiment Design. 24 de febrero de 2026.

[6] METR. Measuring the Self Reported Impact of Early 2026 AI on Technical Worker Productivity. 11 de mayo de 2026.

[7] Cui, Demirer, Jaffe, Musolff, Peng y Salz. The Effects of Generative AI on High Skilled Work. Management Science. Publicación en línea el 27 de febrero de 2026.

[8] Cui y colaboradores. Versión completa disponible en el MIT. Febrero de 2025. Detalles de las medidas de productividad.

[9] OWASP. Authorization Cheat Sheet.

[10] OWASP. Secure Coding with AI Cheat Sheet.

[11] Forsgren y colaboradores. The SPACE of Developer Productivity. ACM Queue, 2021.

[12] DORA. State of AI Assisted Software Development 2025.

[13] DORA. DORA 2025 Year in Review. 7 de enero de 2026.