La ilusión de la velocidad
La ilusión de la velocidad en la era de la IA
En un mundo cambiante, donde cada día llegan nuevas herramientas de inteligencia artificial, la promesa de velocidad y productividad parece ser la nueva frontera para los CTO y los departamentos de TI.
El mantra que resuena en la cabeza de los directivos en este periodo es:
tenemos que ser más rápidos
El VibeCoding, la promesa de que cualquiera puede ser capaz de crear software sin saber programar, es la herramienta principal de esta velocidad y los vasallos de esta herramienta son los agentes de decodificación: un pelotón de profesionales virtuales que pueden llegar en oleadas a nuestros proyectos, generando código y deuda técnica a velocidades impresionantes.
Sin embargo, esta aceleración podría ocultar un peligro insidioso: la creación de una generación de "seniors virtuales", profesionales que, aun siendo capaces de realizar productos rápidamente gracias a la IA, carecen de las competencias profundas necesarias para afrontar los desafíos técnicos más complejos.
¿Un daño o una broma pesada?
Si hasta hoy el crecimiento profesional, de junior a senior, era un camino largo y tortuoso, hecho de errores, correcciones y aprendizaje manual, la IA corre el riesgo de saltarse esta fase crucial, dando a todos herramientas que permiten evitar el "rodaje" y volverse inmediatamente hiperproductivos.
Ya he hablado en el pasado de lo importante que es el rodaje para el crecimiento profesional, pero ahora esta fase corre el riesgo de ser completamente eludida, y no por un curso, sino por un apuntador que nos da la respuesta en cada paso.
Un mecanismo perverso camuflado de productividad, que podría transformarse en un arma apuntada contra la misma empresa que requiere velocidad, creando profesionalidades aparentes: personas capaces de alcanzar enseguida excelentes resultados, pero luego incapaces de adecuar lo solicitado a las exigencias de negocio más o menos complejas que llegan desde la dirección.
La pregunta que deberíamos hacernos es: ¿cómo pueden los CTO evitar esta deriva? ¿Cómo podemos contrarrestar el proceso de desprofesionalización en acto en este momento histórico? ¿Cuáles son las herramientas que nos pueden permitir evitar llenar las empresas de cajas vacías?
Rediseñar la mentoría técnica para evitar el colapso de las competencias
Hay un gran entusiasmo por cómo la IA acelera todo: desde la escritura del código, a la creación de documentos, de planes de trabajo, etc., pero esta aceleración no permite una cosa muy importante: el error.
Es inútil negar que un error enseña más que mil líneas generadas por la IA. Cuando delegamos todo a un agente, por demasiado tiempo, solo corremos el riesgo de perder la capacidad de aprender, porque no hay tiempo material para asimilar, estudiar, equivocarse y aprender.
Esto crea un colapso de competencias que corre el riesgo de ser sistémico para las empresas tecnológicas. Los datos hablan claro: según la Stack Overflow Developer Survey 2025, el 84% de los desarrolladores está usando o planea usar herramientas de IA (creciendo desde el 76% de 2024), con el 51% de los profesionales que las usan diariamente. Sin embargo, la confianza se ha desplomado: solo el 33% confía en la precisión del output de la IA, mientras que el 46% activamente desconfía (aumentando desde el 31% de 2024). Solo el 3% reporta "alta confianza" en los resultados. ¿La frustración principal? El 66% de los desarrolladores lamenta que "las soluciones de IA son casi correctas, pero no del todo", y el 45% encuentra que depurar código generado por la IA requiere más tiempo del que se necesitaría para escribirlo desde cero.
Venimos de años donde era necesario arremangarse y aprender, verificar los errores, estudiar nuevamente y mejorar. Si pensamos en los próximos 5 años, el riesgo es que las competencias no se formen más porque la IA hará el trabajo por nosotros: en caso de error se continuará reiterando hasta un presunto resultado aceptable (o al menos hasta que una IA nos diga que el resultado es aceptable, o hasta que el presupuesto nos lo permita).
Pero en ese punto: ¿quién evaluará la calidad del resultado? Hacer evaluar un resultado a quien ha alcanzado el resultado es un contrasentido. ¿Quién entenderá si ese producto es adecuado al contexto empresarial?
Mientras tengamos personas criadas con la vieja escuela de aprendizaje, quizás irá bien y lograremos hacer un análisis correcto, ¿pero dentro de 5 años? ¿Y dentro de 10? Y no, la respuesta no es hacer evaluar el producto de una IA por otra IA, porque esto no resuelve el problema de la competencia humana.
Teniendo que ser previsores, debemos pensar en cómo evitar que las empresas tecnológicas se encuentren con una generación de seniors vacíos, incapaces de gestionar sistemas complejos.
Por lo tanto, no debemos concentrar nuestras competencias en crear productos, sino en mitigar el riesgo de que las IA absorban todas las competencias empresariales vaciando, de hecho, la competencia de las personas y siendo así insertadas dentro de los procesos empresariales hasta el punto de no poder ser más supervisadas o evitadas.
Outsourcing digital
La dirección hacia la que vamos es un outsourcing digital, donde estamos dando nuestros activos empresariales en gran parte a terceros: estamos malvendiendo cultura a cambio de una apariencia de velocidad.
¿Estamos listos para dar este paso? ¿Estamos listos para delegar nuestro know-how a un software que no sabemos cómo funciona? Pero sobre todo, en el momento en que ese software se equivoca, ¿cómo hacemos para entender dónde se ha equivocado si no tenemos las competencias para hacerlo? ¿Cómo hacemos para corregir los errores que ha cometido si ya no somos dueños de la tecnología?
Reflexionemos sobre esta frase:
Las startups pueden lanzar con código generado por IA, pero no pueden escalar sin desarrolladores expertos
Si tenemos que realizar una POC: la IA va muy bien, si tenemos que crear un MVP quizás empezamos a tener un problema, pero si tenemos que construir una empresa sólida, con bases robustas, no podemos confiarnos a quien no tiene las competencias para entender qué está haciendo.
Estrategias proactivas para CTO: creemos anticuerpos
La solución no es prohibir el uso de la IA, sino repensar el camino de crecimiento de nuestros desarrolladores con una ingeniería inversa de las competencias. Debemos diseñar fricciones positivas en el flujo de trabajo que obliguen al cerebro a no apagarse.
Intentemos hacer un ejercicio de estilo y dar algunas ideas a un CTO que quiere evitar la desertificación de las competencias:
1. Zonas libres de IA
Antiguamente el hombre tenía que correr detrás de los animales para cazar, ahora para mantenerse en forma pasa horas en una cinta de correr. Puede parecer un paralelo forzado, pero es necesario definir contornos donde el uso de las IA sea deliberadamente prohibido. Los CTO deberían designar áreas específicas de trabajo, quizás en contextos críticos como los sistemas legacy, como gimnasios cognitivos. En estas zonas, para quien debe formarse, el uso de la IA está prohibido o limitado a la sola consulta de la documentación. Esto no ralentiza ningún proyecto, lo asegura. Obliga a leer, comprender y describir la lógica, creando esa memoria muscular que de otro modo se perdería.
2. Repensemos las revisiones de código: preguntémonos "¿Por qué?"
Cada modificación de software no deberá ser evaluada solo por el hecho de que funcione, que esté limpia, que responda a los requisitos: es fácil crear tests que respeten cuando se hace por el código que deben validar, pero la nueva pregunta debe ser: "¿Por qué?". ¿Por qué has elegido este patrón específico en lugar de otro? Cuando la respuesta sea "Lo ha sugerido la IA", la modificación será rechazada. Debemos evaluar la capacidad de defender las elecciones arquitectónicas, no solo la capacidad de producir output.
Recuerdo un curso universitario en el que enseñé en el pasado: después de haber evaluado la calidad de los trabajos preguntaba siempre el motivo de las elecciones hechas. A veces los estudiantes respondían "Porque me lo ha sugerido ChatGPT". En ese momento sabía que el fruto del trabajo era producido por una máquina y no por ellos, y exigía que fuese reescrito, analizado y comprendido.
La capacidad de argumentar las propias elecciones es fundamental para crecer y será aún más importante en un mundo donde la IA puede sugerir mil alternativas diferentes en pocos segundos, pero no todas serán útiles al contexto.
3. Juguemos a wargames
La IA es buenísima diagnosticando errores comunes, ¿pero qué sucede cuando el sistema colapsa de una manera que el modelo nunca ha visto? Un límite de las actuales soluciones es la visión holística, el lograr integrar de modo correcto varios aspectos de los proyectos: no solo el pequeño contexto dado en pasto por un prompt más o menos largo.
Organizad sesiones de juego donde se rompen intencionalmente partes en el entorno de staging de modos sibilinos (problemas de red, condiciones de carrera, fugas de memoria) y se pide al equipo resolver el problema sin herramientas de IA. La capacidad de rastrear un error a través del stack mental es la habilidad que distingue a un profesional de un simple prompt engineer.
4. Arqueología digital
Asignad tareas, dejando la posibilidad de utilizar una IA, pero en contextos donde para las IA no existe información, de modo que las respuestas sean ampliamente erróneas y las personas se vean obligadas a estudiar mejor lo solicitado.
Un ejemplo es la gestión de código legacy, sobre plataformas propietarias, mal documentadas, o con parte de documentación ausente. Esto obliga a las personas a estudiar mejor cómo pensaba el viejo programador y es un ejercicio de empatía técnica fundamental para el diseño de sistemas robustos.
5. Hablemos primero de diseño y luego de prompts
Es inútil y contraproducente lanzarse al teclado a escribir prompts si no tenemos bien en mente el proyecto sobre el cual queremos poner las manos. Obliguemos a las personas a escribir primero un documento de diseño, una arquitectura general, un documento que describa la visión global.
El pensamiento debe preceder la generación del resultado, que es solo una consecuencia. Si la IA escribe el código, el humano debe escribir la arquitectura. Si el humano abdica también de esto, se convierte en un pasapapeles inútil y probablemente dañino.
Recruiting 2.0: contratemos capacidad cognitiva
Si la forma de trabajar cambia, debe cambiar también la forma en que contratamos. Los viejos tests algorítmicos son ya inútiles: cualquier modelo de IA los resuelve en un puñado de segundos.
¿Qué debemos buscar entonces?
La capacidad de hacer preguntas: mi hijo de 7 años me bombardea a preguntas, pero por cómo me las hace entiendo qué está aprendiendo, qué ha entendido y en qué dirección está yendo. Haced lo mismo con los candidatos: describid un problema vago y mal definido. No evaluéis la solución, sino el camino y las preguntas que hace para aclarar los requisitos. La IA es pésima gestionando la ambigüedad humana: no aclara, sigue un camino como el más lógico o probable, y comienza el trabajo. Para quien tiene un poco de cultura de ciencia ficción: es como hablar con un vulcaniano.
Haced hacer debug sobre código roto: la capacidad que sirve es la de entender los errores. Dad a los candidatos un sistema complejo que falla de modo intermitente. Observad el proceso mental de investigación.
Arquitecturas offline: dad en mano al candidato una tiza y una pizarra, lo sé: suena muy boomer, pero es una técnica que todavía funciona. Hacedle dibujar una posible arquitectura para un proyecto de cualquier naturaleza, luego aumentad los requisitos y seguid los razonamientos que usa para adecuar la arquitectura.
Distinguir qué es producido por una máquina y qué por un humano
Es importante entender la fuente de un dato, distinguiendo qué es producido por una máquina y qué es producido por un humano. La razón es simple: los propósitos son diferentes. Una persona tiene un objetivo específico mientras una máquina se basa en probabilidades e iteración.
Si no imponemos reglas para entender de qué fuente llega el dato que estamos tratando, corremos el riesgo de abordar de modo equivocado datos que, por su naturaleza, nacen de modo diferente. Un CTO debe tener bien presente este aspecto, circunscribir el área de acción de máquinas y personas e introducir un código de conducta.
Cuando se habla de desarrollo de software, esto se traduce en algunas reglas prácticas, que por traslación pueden ser aplicadas en otros ámbitos empresariales. Las principales son: etiquetado y cuarentena.
El etiquetado sirve para comprender de forma inmediata la fuente de algo: si vuestro código, vuestros documentos, vuestros procedimientos, son generados en más del 50% por una máquina, introducid anotaciones específicas "AI GENERATED" y quizás indicad el modelo que ha estado involucrado en la realización. Si en el futuro hay un problema, tendremos que ir a hacer controles, y este tipo de etiquetado nos ayudará a remontarnos a la fuente del problema. Como todos los softwares, también las IA no son perfectas, cometen errores y alucinaciones y, en base al contexto y a la versión, tienen comportamientos diferentes. Etiquetar lo que producen nos ayuda a rastrear la fuente de un problema.
La cuarentena nos permite no dar por bueno inmediatamente lo que se nos propone. Si se trata de código, evitad que las IA se ocupen directamente del CORE de producto. Utilizadlas para escribir tests, utilidades, para criticar el código realizado, para hacer análisis, para daros ideas, pero no para ocuparse pesadamente de lo que debéis escribir: en este momento histórico las IA usadas como ayuda son un bien, utilizadas para gestionar el core business corren el riesgo de transformarlo en una masa informe sin un verdadero propietario.
¿Qué deberán hacer los nuevos seniors?
Estamos inmersos en una verdadera revolución industrial y es importante razonar a medio plazo y no a corto. Sin ser futurólogos, pensemos en qué ha sucedido en los últimos 5 años e intentemos trasladarlo a los próximos 5. El rol de los seniors cambia. No es más aquel que escribe código más velozmente o conoce de memoria las API. No es el que sabe resolver los problemas más velozmente. La velocidad llegará de las herramientas, que serán siempre más eficientes respecto a una persona. Por este motivo es necesaria una evolución.
Los nuevos seniors deberán desarrollar capacidades holísticas transversales, deberán entender si se encuentran ante una alucinación o una verdad. Deberán entender de modo correcto las especificaciones humanas, superando lo que dice el texto, y entendiendo el verdadero sentido de lo que se nos pide, que no es siempre literal, pero muchas veces tiene matices implícitos que una máquina, por ahora, no es capaz de comprender.
Tendremos entonces que premiar a quien sea capaz de prevenir una deuda técnica generada por la IA, no a quien hace más commits de features. Los KPI deben desplazarse de la velocidad a la estabilidad y a la gestión de la complejidad y del caos.
No debemos ser más rápidos, sino más resilientes
Desenamorémonos entonces de la velocidad: no es el objetivo de nuestro trabajo. Como CTO debemos pensar en un crecimiento sostenible, en un modelo de empresa capaz de ser expandida y entendida, debemos evitar ser esclavos de tecnologías que no somos capaces de gobernar, poniéndonos en una situación donde las tecnologías están al servicio de la empresa y no al contrario.
Invirtamos en formación, en la comprensión de los procesos, en la comprensión de las arquitecturas, hagamos que las personas se especialicen en materias humanísticas capaces de comprender a las personas, haciéndolas capaces de entender las exigencias del género humano y de poder criticar de modo inteligente lo que es propuesto y realizado por las máquinas.
Si la IA debe entrar en los procesos empresariales, hagámoslo de modo consciente, no como una ola que arrasa todo sin dejar nada detrás de sí. Hagamos que la IA sea ella misma instrumento de crecimiento y no de destrucción de las competencias: no basta crear, es necesario explicar cómo y por qué se ha creado, de lo contrario se corre el riesgo de construir castillos de arena destinados a derrumbarse al primer soplo de viento.