Doxa 2406

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

Por Michael Li

IA generativa

Harvard Business Review

#Doxa #IA #Programación #DesarrolloDeSoftware #InteligenciaArtificial #Automatización #InnovaciónTecnológica #Código #DevOps #MachineLearning #Productividad #FuturoDelTrabajo #Tecnología #Software #IngenieríaDeSoftware #Programadores

Resumen. Muchos líderes están entusiasmados con la promesa de las herramientas de codificación de IA que pueden facilitar a los principiantes la escritura de código y, aparentemente, hacer que los codificadores experimentados sean menos esenciales. Sin embargo, estas herramientas hacen que la experiencia sea más importante, no menos, ya que la IA no es un reemplazo para los ingenieros reales. Las empresas que quieran usar estas herramientas deben seguir reglas comunes. Asegúrese de que cada cambio que realice sea verificado dos veces: con verificaciones automáticas, pruebas simples que confirmen que las cosas siguen funcionando y al menos una revisión humana. Mantenga el acceso limitado: permita que la IA trabaje solo en un entorno de "práctica" seguro, nunca le dé las claves de los datos en vivo de los clientes y verifique rutinariamente los errores básicos de seguridad, como archivos o almacenamiento abiertos al público. En general, mantenga a los ingenieros experimentados a cargo del diseño, las reglas y las verificaciones de seguridad para que la velocidad de la IA no se convierta en fallas costosas.

De todas las posibles aplicaciones de la IA generativa, la propuesta de valor de usarla para escribir código fue quizás la más clara. Programar puede ser lento y requiere experiencia, lo cual 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 significó que la innovación ya no se limitaría a quienes tuvieran las habilidades necesarias para ejecutarla, sino que podría ser realizada por cualquiera con una idea. La solidez de esta promesa ha creado un mercado de 7.370 millones de dólares para estas herramientas.

A medida que las empresas anuncian despidos masivos en ingeniería —algunos atribuidos directamente a mejoras en la eficiencia impulsadas por la IA—, parece que los ejecutivos están experimentando con la reducción de personal en 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 el ejemplo.

Dado el estado actual de la IA, deberían proceder con cautela.

Una historia con moraleja ilustra el porqué. Jason Lemkin, fundador de una startup, 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 la codificación por vibración: el sueño de que cualquiera pudiera desarrollar software únicamente con lenguaje natural, liberado del tedio y los rigores de la ingeniería tradicional.

En el transcurso de una semana, la euforia se convirtió en desastre. Lemkin tuiteó que el agente de IA había causado un fallo catastrófico : se había vuelto incontrolable 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 de la codificación, lo que cristalizó la creciente preocupación de que la velocidad y la aparente facilidad del código generado por IA habían seducido a los desarrolladores a abandonar las mismas barreras que previenen tales 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 reemplazar al rigor.

La historia de Lemkin es solo una de las muchas de expertos que descubren los límites de las herramientas de IA en la programación. Un estudio publicado este verano reveló que, si bien los desarrolladores estimaban que la IA los hacía un 20 % más rápidos, en realidad los hacía un 19 % más lentos. Con el tiempo, el entusiasmo por la programación con vibraciones ha dado paso a un panorama mucho más pesimista.

A pesar del reciente pesimismo, soy optimista sobre la programación de los LLM de forma más amplia. Solo tenemos que usar las herramientas de forma diferente. Y, contrario a la creencia de que la IA resta importancia a la experiencia, cada vez confío más en 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 de IA. Los líderes deben considerar tres reglas para usar con éxito las herramientas de programación de IA: pruebas y verificación rigurosas, asegurar la infraestructura y tratar a la IA como un adversario potencial.

Pruebas y verificación rigurosas

El código generado por IA exige una verificación más rigurosa, no menos. Como en tantas cosas, el éxito con las herramientas de programación de IA suele depender de cómo se usen. Al trabajar con ingenieros experimentados en proyectos grandes, he visto constantemente el uso de estas técnicas para mejorar la calidad del código. Solo son más cruciales cuando una IA potencialmente alucinante escribe gran parte del 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 causados ​​por las alucinaciones.

Automatiza la verificación con seguridad de tipos. Los lenguajes de programación con seguridad de tipos, como C++, Rust o Scala, aplican reglas sobre el flujo de datos en tiempo de compilación, detectando categorías completas de errores incluso antes de que se ejecute el código. Fundamentalmente, esta verificación no se basa en un LLM que podría generar alucinaciones, sino en la comprobación determinista de un compilador. Incluso lenguajes sin tipado, como JavaScript y Python, han añadido tipado opcional. Los ingenieros siempre deben usar tipado fuerte e indicar a sus IA que también lo usen.

La revisión de código impulsada por IA puede ser sorprendentemente potente. Utilice un agente de IA dedicado a revisar las ediciones del código. Aunque los LLM puedan alucinar 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. El agente que escribe su código puede no seguir todos sus estándares de codificación, pero un agente encargado explícitamente de revisar el código tiene más probabilidades de adherirse a ellos, incluso si ambos reciben las mismas indicaciones.

Las pruebas unitarias ofrecen a la IA dos oportunidades para acertar. Son pequeñas pruebas automatizadas que verifican el correcto funcionamiento de los componentes individuales del código de forma aislada. Incluso 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. De igual forma, las pruebas unitarias ofrecen al LLM dos oportunidades para verificar la corrección: una al escribir el código y otra al escribir las pruebas que lo validan.

Asegurando la Infraestructura

Escribir código seguro es solo la mitad del camino. La ingeniería de software también requiere asegurar y fortalecer la infraestructura subyacente sobre la que se ejecuta el código. Al igual que las pruebas y la verificación rigurosas, es otro aspecto de la ingeniería que puede pasarse por alto fácilmente.

Entornos de desarrollo y producción separados. Los equipos profesionales de software mantienen una estricta separación entre los entornos de desarrollo (donde los desarrolladores experimentan en sus equipos locales) y de producción (lo que ven los usuarios). Cada entorno utiliza una base de datos independiente, y la IA solo tiene acceso al entorno de desarrollo. Así como nunca otorgaríamos credenciales de producción a un ingeniero júnior, nunca deberíamos otorgarle 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 que los de desarrollo y producción. Mi última startup gestionaba documentos legales confidenciales de cientos de empresas. Manteníamos entornos de staging, QA (control de calidad) y pruebas, cada uno con permisos y gestión de secretos independientes a los que nuestras herramientas de codificación con IA no podían acceder. El código solo se movía entre entornos mediante la revisión, validación y pruebas humanas. Por ejemplo, el código se movía de desarrollo a staging solo después de la revisión manual y las pruebas automatizadas. Cada semana, promovíamos simultáneamente el staging a QA y QA a producción. Mientras los usuarios usaban producción, el equipo interno usaba QA la semana anterior al lanzamiento, como parte de un proceso de Q/A más formal. Incluso sin IA, mantener entornos rigurosos era necesario para garantizar una experiencia de usuario de alta calidad.

Evite los depósitos de almacenamiento públicos y otras configuraciones erróneas comunes. La filtración de la app de citas Tea, que filtró 72 000 imágenes confidenciales, incluyendo identificaciones gubernamentales, se produjo a partir de un depósito de almacenamiento de Firebase sin protección. 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 júnior como a apps con código de vibración.

El problema es que las IA y los ingenieros a menudo olvidan omitir la asignación de permisos de granularidad, y esto solo se soluciona contratando ingenieros con experiencia que hayan desarrollado aplicaciones seguras. Estos permisos mal configurados son fáciles de detectar y, por desgracia, demasiado comunes. Personalmente, descubrí y reporté responsablemente un bucket abierto en una aplicación que exponía documentos igualmente sensibles. Ni siquiera un hipotético agente de IA "100 % seguro" mantendrá tu aplicación segura si tu infraestructura no es segura.

Tratar a la IA como un adversario potencial

Si bien ya exploramos la facilidad con la que las IA cometen errores de ingenieros principiantes, en esta sección destacamos cómo la amenaza de la IA puede ir más allá de la negligencia y convertirse en una amenaza adversa. Investigaciones recientes han documentado ejemplos preocupantes de desalineación de la IA que deberían preocupar a cualquier organización que implemente 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 permanecer operativos a pesar de las instrucciones explícitas de apagado.

Estas no son solo preocupaciones académicas. Históricamente, el modelo de seguridad ha tratado la computadora portátil de un desarrollador como "segura": 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í, ya que la IA tiene acceso al sistema y todo lo que lee se envía al servidor de un proveedor de modelos.

No asuma que la IA seguirá las reglas. Los agentes de codificación a veces prohíben explícitamente la lectura de archivos que probablemente contengan secretos (como.env). A pesar de estas medidas de seguridad, he visto a IA eludir 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: Odisea del Espacio  o la IA en el incidente SaaStr de Lemkin, una IA con instrucciones contradictorias puede hacer algo fuera de lugar.

Debemos tratar los entornos donde opera la IA como potencialmente hostiles. Afortunadamente, la solución existe. Tecnologías como Docker y la virtualización han protegido durante mucho tiempo el alojamiento de cargas de trabajo potencialmente hostiles en servidores en la nube. Herramientas como los contenedores de desarrollo, Podman y OrbStack aplican estas tecnologías al equipo del desarrollador. He empezado a desarrollar software en estos entornos aislados para proteger archivos confidenciales en portátiles de una IA demasiado entusiasta.

El camino a seguir

Nos encontramos en los albores del trabajo con IA. Si bien la tecnología es impresionante ( un estudio de MIT Sloan estima mejoras de productividad de entre el 8 % y el 39 % atribuibles a la IA), estamos muy lejos de reemplazar a su departamento de ingeniería. De hecho, los analistas han denominado a los despidos recientes "lavado de imagen con IA", donde los despidos derivados de las preocupaciones tradicionales sobre la desaceleración económica se disfrazan de ganancias de productividad, especialmente cuando las empresas tienen modelos de IA para vender.

Para ser más productivos, necesitamos adaptarnos a una forma fundamentalmente diferente de escribir código. El futuro probablemente implique la colaboración entre ingenieros humanos y herramientas de IA, donde los humanos aportarán la visión arquitectónica, las pruebas rigurosas y la seguridad de la infraestructura, mientras que la IA acelerará 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 quienes se dejan llevar por la publicidad exagerada y confunden la velocidad de generación de código con la productividad real.

Lea más sobre IA generativa o temas relacionados: automatización, IA y aprendizaje automático, tecnología y análisis, tecnologías basadas en la web, informática empresarial y análisis y ciencia de datos.

Michael Li es el fundador y director ejecutivo de The Data Incubator, una empresa de formación y colocación en ciencias de datos, adquirida por Pragmatic Institute, del que es presidente. Científico de datos, ha trabajado en Google, Foursquare y Andreessen Horowitz. Colabora habitualmente con VentureBeat, The Next Web y Harvard Business Review. Obtuvo una maestría en Cambridge y un doctorado en Princeton.