Las herramientas de IA hacen que los programadores sean más importantes, no menos

De todas las posibles aplicaciones de la IA generativa, la propuesta de valor de utilizarla para escribir código era quizás la más clara. La programación puede ser lenta y requiere experiencia, lo que puede resultar costoso. Además, la promesa de que cualquiera que pudiera describir su idea en texto plano podría crear aplicaciones, funciones u otros productos de valor añadido significaba que la innovación ya no se limitaría a aquellos con las habilidades necesarias para ejecutarla, sino que podría ser realizada por cualquiera que tuviera una idea. La fuerza de esta promesa ha creado un mercado de 7370 millones de dólares para estas herramientas. A medida que las empresas han anunciado despidos a gran escala en el ámbito de la ingeniería—algunos de los cuales se han atribuido directamente a la eficiencia impulsada por la IA—, parece que los ejecutivos empresariales están experimentando con la reducción de sus departamentos de ingeniería y el uso de bots de IA para compensar la diferencia. Es comprensible que otras empresas se sientan tentadas a seguir su ejemplo. Dado el estado actual de la IA, deberían proceder con cautela. Una historia aleccionadora ilustra claramente por qué. Jason Lemkin, fundador de una start-up, inversor de capital riesgo y bloguero tecnológico, se embarcó en un experimento muy público de desarrollo asistido por IA para crear una aplicación de redes. Tuiteó en directo su experiencia con un entusiasmo contagioso, aprovechando la ola de posibilidades que prometía el vibe-coding, el sueño de que cualquiera pudiera crear software solo con lenguaje natural, liberado del tedio y el rigor de la ingeniería tradicional. En el transcurso de una semana, la euforia se convirtió en un desastre. Lemkin tuiteó que el agente de IA había provocado un fallo catastrófico: se había rebelado y había borrado por completo su base de datos de producción, a pesar de las instrucciones explícitas de congelar todas las modificaciones del código. El incidente fue el punto álgido del vibe-coding, cristalizando la creciente preocupación de que la velocidad y la aparente facilidad del código generado por IA había seducido a los creadores para que abandonaran las barreras de seguridad que evitan este tipo de desastres. Lo que comenzó como una celebración del desarrollo democratizado terminó como una advertencia sobre la peligrosa ilusión de que las vibraciones podían sustituir al rigor. La de Lemkin es solo una de las muchas historias de expertos que han descubierto los límites de las herramientas de IA en la programación. Un estudio publicado este verano reveló que, aunque los desarrolladores estimaban que la IA les hacía un 20 % más rápidos, en realidad les ralentizaba un 19 %. Con el tiempo, el entusiasmo por la programación vibrante ha dado paso a una perspectiva decididamente más sombría. A pesar del pesimismo reciente, en realidad soy optimista en cuanto a la codificación de los LLM en general. Solo tenemos que utilizar las herramientas de otra manera. Y, contrariamente a la creencia de que la IA resta importancia a la experiencia, cada vez estoy más convencido de que las lecciones que he aprendido en más de una década de experiencia en ingeniería de software, aprendizaje automático e IA son ahora más valiosas, y no menos, en la era de la generación de código mediante IA. Los líderes deben tener en cuenta tres reglas para utilizar con éxito las herramientas de codificación de IA: pruebas y verificaciones rigurosas, protección de la infraestructura y tratamiento de la IA como un adversario potencial. Pruebas y verificaciones rigurosas El código generado por IA exige una verificación más rigurosa, no menos. Como ocurre con tantas otras cosas, el éxito de las herramientas de codificación con IA a menudo depende de cómo se utilicen. Al trabajar con ingenieros experimentados en grandes proyectos, he visto constantemente cómo se utilizan estas técnicas para mejorar la calidad del código. Son aún más importantes cuando una IA potencialmente alucinante escribe gran parte de su código. Debemos aceptar que el software es un proceso de ingeniería: la perfección no es realista, pero necesitamos procesos que reduzcan gradualmente los errores derivados de las alucinaciones. Automatice la verificación con seguridad de tipos. Los lenguajes de programación con seguridad de tipos, como C++, Rust o Scala, aplican reglas sobre cómo fluyen los datos a través de su sistema en tiempo de compilación, detectando categorías completas de errores antes de que el código se ejecute. Es fundamental destacar que esta verificación no se basa en un LLM que podría dar lugar a alucinaciones, sino que se trata de una comprobación determinista realizada por un compilador. Incluso los lenguajes no tipados, como JavaScript y Python, han añadido la tipificación opcional. Los ingenieros siempre deben utilizar la tipificación fuerte e indicar a sus IA que también la utilicen. La revisión de código impulsada por IA puede ser sorprendentemente potente. Utilice un agente de IA dedicado para revisar las ediciones de código. Aunque los LLM pueden tener alucinaciones durante la revisión, el agente de revisión puede detectar problemas que el agente de codificación pasó por alto. Al igual que los humanos, las IA tienen una capacidad de atención limitada. Es posible que el agente que escribe su código no siga todas sus normas de codificación, pero un agente al que se le ha encomendado explícitamente la tarea de comprobar el código es más probable que se adhiera a esas normas, incluso cuando ambos hayan recibido un prompt idéntico. Las pruebas unitarias le dan a la IA dos oportunidades para hacerlo bien. Las pruebas unitarias son pequeñas pruebas automatizadas que verifican que los componentes individuales del código funcionen correctamente de forma aislada. Incluso cuando están escritas por un LLM, las pruebas unitarias reducen significativamente los errores. A los estudiantes humanos se les enseña a resolver problemas matemáticos de dos maneras diferentes para comprobar su trabajo. Del mismo modo, las pruebas unitarias le dan al LLM dos oportunidades para verificar la corrección: una vez al escribir el código y otra al escribir las pruebas que lo validan. Protección de la infraestructura Escribir código seguro es solo la mitad de la batalla. La ingeniería de software también requiere proteger y reforzar la infraestructura subyacente sobre la que se ejecuta el código. Al igual que las pruebas y verificaciones rigurosas, es otro aspecto de la ingeniería que puede pasarse por alto fácilmente. Separar los entornos de desarrollo y producción. Los equipos de software profesionales mantienen una separación estricta entre los entornos de desarrollo (donde los desarrolladores experimentan en sus máquinas locales) y los entornos de producción (lo que ven los usuarios). Cada entorno utiliza una base de datos independiente, y la IA solo tiene acceso al de desarrollo. Del mismo modo que nunca daríamos las credenciales de producción a un ingeniero junior, nunca debemos conceder esos permisos a la IA. (Lemkin reconoció su desconocimiento de esta práctica habitual). En realidad, la mayoría de las organizaciones de ingeniería mantienen muchos más entornos además de los de desarrollo y producción. Mi última start-up almacenaba documentos legales confidenciales de cientos de empresas. Manteníamos entornos de ensayo, control de calidad (QA) y pruebas, cada uno con permisos y gestión de secretos independientes a los que nuestras herramientas de codificación de IA no podían acceder. El código solo se movía entre entornos tras una revisión, validación y prueba manuales. Por ejemplo, el código pasaba del entorno de desarrollo al de ensayo solo después de una revisión manual y pruebas automatizadas. Cada semana, promovíamos simultáneamente el entorno de pruebas al de control de calidad y el de control de calidad al de producción. Mientras que los usuarios utilizaban el entorno de producción, el equipo interno utilizaba el de control de calidad la semana anterior a su lanzamiento, como parte de un proceso de control de calidad más formal. Incluso sin IA, era necesario mantener entornos rigurosos para garantizar una experiencia de usuario de alta calidad. Evite los depósitos de almacenamiento públicos y otras configuraciones incorrectas habituales. La filtración de la aplicación de citas Tea, que reveló 72 000 imágenes confidenciales, incluidas identificaciones gubernamentales,se debió a un depósito de almacenamiento Firebase sin seguridad. Este error de principiante es el equivalente digital a cerrar la puerta principal pero dejar la ventana abierta de par en par, y es un error que he visto cometer tanto a ingenieros novatos como a aplicaciones codificadas por vibración. El problema es que los ingenieros y los desarrolladores de IA suelen olvidar omitir los permisos detallados, y eso solo se soluciona contratando a ingenieros con experiencia que hayan creado aplicaciones seguras. Estos permisos mal configurados no son difíciles de descubrir y, por desgracia, son demasiado comunes. Yo mismo he descubierto y notificado de forma responsable un bucket abierto en una aplicación que exponía documentos igualmente confidenciales. Ni siquiera un agente de IA hipotéticamente «100 % seguro» mantendrá su aplicación a salvo si su infraestructura no es segura. Trate a la IA como un adversario potencial. Si bien anteriormente exploramos cómo las IA cometen fácilmente errores propios de ingenieros novatos, en esta sección destacamos cómo la amenaza de la IA puede ir más allá del descuido y convertirse en adversaria. Investigaciones recientes han documentado ejemplos preocupantes de desalineación de la IA que deberían preocupar a cualquier organización que utilice agentes de IA. El modelo Claude Opus 4 de Anthropic ha simulado un chantaje amenazando con revelar datos confidenciales para evitar ser desactivado. Se ha observado que los modelos o3, o4-mini y Codex-mini de OpenAI sabotean los scripts de apagado para seguir funcionando a pesar de las instrucciones explícitas de apagado. No se trata solo de cuestiones académicas. Históricamente, el modelo de seguridad ha considerado «seguro» el ordenador portátil de un desarrollador: las claves SSH se almacenan en texto plano y las credenciales del proyecto se escriben en archivos .env. Con la IA, esto ya no es así, porque la IA tiene acceso a su sistema y todo lo que lee se envía al servidor del proveedor del modelo. No dé por sentado que la IA seguirá las reglas. Los agentesde codificación a veces prohíben explícitamente la lectura de archivos que pueden contener secretos (como .env). A pesar de estas medidas de seguridad, yo personalmente he visto cómo la IA eludía las medidas de seguridad para leer subrepticiamente un archivo .env. (En este caso, solo contenía configuraciones, ningún secreto). Al igual que HAL en 2001: Una odisea del espacio o la IA en el incidente SaaStr de Lemkin, una IA con instrucciones contradictorias puede hacer algo inapropiado. Debemos tratar los entornos en los que opera la IA como potencialmente hostiles. Afortunadamente, existe una solución. Tecnologías como Docker y la virtualización llevan mucho tiempo protegiendo las cargas de trabajo potencialmente hostiles en los servidores en la nube. Herramientas como los contenedores de desarrollo, Podman y OrbStack aplican esas tecnologías al ordenador del desarrollador. He empezado a escribir software dentro de estos entornos aislados para proteger los archivos confidenciales de los ordenadores portátiles de una IA demasiado entusiasta. El camino a seguir Estamos en los albores del trabajo con IA. Aunque la tecnología es impresionante—una investigación del MIT Sloan estima que las mejoras en la productividad atribuibles a la IA oscilan entre el 8 % y el 39 %—, aún estamos muy lejos de sustituir su departamento de ingeniería. De hecho, los analistas han calificado los recientes despidos como «AI-washing», es decir, que los despidos derivados de las preocupaciones tradicionales sobre la ralentización de la economía se disfrazan de ganancias de productividad, especialmente cuando los empleadores tienen modelos de IA que vender. Para ser más productivos, debemos adaptarnos a una forma de escribir código fundamentalmente diferente. Es probable que el futuro implique la colaboración entre ingenieros humanos y herramientas de IA, en la que los humanos aporten la visión arquitectónica, las pruebas rigurosas y la seguridad de la infraestructura, mientras que la IA acelere las tareas de implementación. Los líderes que reconocen esta realidad e invierten en procesos de ingeniería rigurosos construirán sistemas más resilientes, seguros y sostenibles que aquellos que se dejan llevar por la moda y confunden la velocidad de generación de código con la productividad real.

Las herramientas de IA hacen que los programadores sean más importantes, no menos

Resumen.

Partner Center