Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Que pronto despidan a todo el mundo por culpa de la IA puede parecer una broma para algunos, pero es una realidad inquietante contra la que luchan muchos desarrolladores. De cara al futuro, la IA ya no escribe código, sino que sustituye a los programadores.
Satya Nadella de Microsoft declaró recientemente que casi el 30% del código de Microsoft está escrito por herramientas de IA como Copilot. Pocos días después de que se hiciera pública esa estadística, llegó el golpe decisivo: Microsoft despidió a 2.000 empleados. ¿Podría tratarse de una coincidencia, o existe alguna relación entre el hecho de que el 30% del código sea IA y el despido de empleados?
Tales coincidencias no sólo están vinculadas a Microsoft. Se puede observar un fenómeno similar en CloudStrike, IBM y otros. Incluso Goldman Sachs predice que hasta 300 millones de puestos de trabajo serán sustituidos por la IA en un sector en el que hace unos años faltaban casi dos millones de ingenieros.
No es la primera vez que el mundo de la tecnología siente pánico ante la extinción de puestos de trabajo.
Ya se trate de los bytecodes de Java o de la migración a la nube, los desarrolladores siempre se han enfrentado al escepticismo, el miedo y la resistencia cuando surge una nueva tecnología. Pero, esta vez, es diferente. ¿Por qué?
Porque, esta vez, se trata de herramientas que no sólo automatizan, sino que generan resultados imprevisibles. Estas herramientas alucinan. Pueden ser rápidas, pero no son fiables. A pesar de ello, se confía en ellas para generar código a nivel de producción.
En este artículo exploraremos esta tensión y veremos por qué algo llamado Cadena de Integridad de la Intención podría ser nuestra mejor opción para sobrevivir a la IA sin perder el control. Empecemos.
Pánico y progreso: el ciclo continúa
El pánico que rodea a la IA en el desarrollo de software puede parecer nuevo, pero no lo es. De hecho, con cada abstracción en tecnología, ya sea Java, el uso de herramientas SaaS o el paso a la nube, siempre surgen dudas.
Hubo un tiempo en que los ingenieros cuestionaban el bytecode de Java, preguntándose si era de fiar. Hubo quienes consideraron que la computación en nube era demasiado arriesgada para los datos sensibles. La resistencia siempre ha existido, pero -a pesar de ello- cada cambio que ha prevalecido hasta ahora ha ayudado a los desarrolladores a construir mejor que antes.
Con el tiempo, las abstracciones han sido la columna vertebral de la escalabilidad, lo que ha llevado al desarrollo de sistemas más rápidos, complejos y resistentes. Pero lo que hace diferente el momento actual es la naturaleza de la IA. Las abstracciones tradicionales consistían más bien en simplificar las complejidades manteniendo un comportamiento coherente y repetible. Sin embargo, avances como los grandes modelos de lenguaje (LLM) dan cabida a la aleatoriedad.
Los LLM están diseñados para basarse en probabilidades, lo que significa que la salida de estos modelos puede ser diferente incluso si se alimentan con entradas idénticas. Esta imprevisibilidad es un punto de ruptura con la abstracción del pasado.
Aunque las herramientas del pasado provocaban miedo y resistencia, venían con un marco que podía determinarse. Con los LLM, los desarrolladores trabajan ahora con sistemas que se comportan de forma diferente cada vez, lo que significa que tienen que enfrentarse a nuevos retos relacionados con la precisión y la fiabilidad del software que generan estos modelos.
¿Son los LLM un mono con una GPU?
A pesar de su popularidad, los LLM siguen siendo poco fiables cuando se trata del desarrollo de software. Su capacidad de generación de código se parece más a los esfuerzos de prueba y error que al trabajo de un ingeniero.
Más que una herramienta precisa e inteligente, puedes pensar en un LLM como un mono con una GPU que se limita a probar cosas hasta que funcionan.
¿Cómo se manifiesta esta realidad en el desarrollo real? Hay numerosos ejemplos de modelos que inventan funciones, inventan nombres de paquetes e incluso producen una lógica peligrosamente errónea.
Por ejemplo, los LLM han hecho referencia a bibliotecas npm que no existen, y actores maliciosos han utilizado esos nombres alucinados para registrar paquetes, introduciendo un nuevo vector de ataques a la cadena de suministro.
Muchos pueden considerar que este riesgo sólo prevalece en teoría, pero no es así. Los estudios que comparan los resultados de calidad del código de herramientas líderes como GitHub Copilot, Amazon CodeWhisperer y ChatGPT generan código correcto sólo entre el 31% y el 65% de las veces, lo que significa que el código es defectuoso casi la mitad de las veces.
Lo que es aún peor es que el 40% del código de IA era vulnerableya que contenía fallos explotables y no seguía las prácticas básicas de seguridad.
Ahora está claro que no se trata sólo de imprecisiones. También incluye una confianza equivocada. Estas herramientas presentan su código con altos niveles de certeza incluso en casos en los que los resultados son erróneos.
Ha habido casos en los que los desarrolladores han pedido a la IA que optimice su código para aumentar la velocidad. ¿El resultado? El modelo elimina las comprobaciones de validación o rompe por completo la cobertura de las pruebas en aras del rendimiento.
Teniendo esto en cuenta, podemos decir que los LLM no son un sustituto de los humanos, no por ahora. Son herramientas que pueden, sin embargo, amplificar la intención y las capacidades de quienes las utilizan. Dicho esto, estos modelos carecen de una sólida comprensión de los sistemas y el contexto; no se puede confiar ciegamente en ellos, y el juicio humano es ahora más crucial que nunca.
La cadena de integridad de la intención
Teniendo en cuenta todo lo que hemos visto hasta ahora, está claro que confiar en el código generado por IA conlleva una serie de riesgos evolutivos. La cadena de integridad de la intención es un marco diseñado para garantizar que esos riesgos no prevalezcan y que la idea original de un desarrollador se convierta en un software funcional y fiable.
El concepto fundamental de este marco es que algo se pierde entre la idea de un desarrollador y el resultado final, y eso es lo que se conoce como brecha de traducción. Estas brechas existen entre una idea y el resultado final que produce un modelo LLM. Esto sucede porque el comportamiento del modelo es impredecible y se basa en la improvisación, lo que significa que no hay garantía de que lo que sale refleje lo que entró.
La Cadena de Integridad de Intenciones puede ayudar a resolver este problema mediante un proceso de varios pasos centrado en cuatro elementos:
- Pregunta - Escrita por humanos, representa la intención bruta o la funcionalidad deseada.
- Espec - Versión estructurada y estandarizada de la solicitud, en lenguaje natural, pero con un formato más claro y coherente.
- Pruebas - Generadas automáticamente a partir de la especificación, estas pruebas definen el comportamiento correcto.
- Código - Generado por el LLM, destinado a superar las pruebas basadas en la especificación.
Antes de seguir adelante con esto, es esencial saber que cada artefacto sirve como eslabón de la cadena, pero no se puede confiar ciegamente en él.
Aunque el prompt no necesita validación ya que es sólo un punto de partida, la especificación debe ser revisada por humanos para asegurar que captura la intención del prompt. Del mismo modo, la prueba debe ser bloqueada y verificable, y el código generado por LLM sólo debe ser validado si pasa la prueba bloqueada.
Esta estructura básicamente introduce puntos de control en cada etapa, lo que puede ayudar a reducir el riesgo de fallos de seguridad y características alucinadas, garantizando que el resultado se ajuste a la intención humana.
Confianza, verificación, puntualidad
El código generado por IA es cada vez más común. Por eso, construir barandillas no es una cuestión de buenas prácticas, sino de supervivencia.
Sin restricciones claramente definidas, como especificaciones y pruebas, los LLM pueden generar software inseguro o directamente defectuoso. Además, técnicas como el desarrollo orientado a pruebas (TDD) y el desarrollo orientado al comportamiento (BDD) proporcionan una estructura en las primeras fases, pero su adopción ha sido difícil porque los desarrolladores prefieren escribir código a escribir pruebas.
Con el desarrollo y la IA convirtiéndose en algo más que una tendencia, la habilidad más crítica que pueden adquirir los desarrolladores es la articulación de intenciones.
Lo que esto significa es que los desarrolladores deben convertirse ahora en ingenieros rápidos que puedan expresar los requisitos de forma precisa, diseñar especificaciones comprobables y auditar los resultados del LLM en busca de fallos. Por ello, el liderazgo técnico se ha convertido hoy en día en algo más relacionado con la capacidad de guiar un modelo a través de indicaciones estructuradas y validación de restricciones.
Un entendimiento común y un conjunto de competencias de futuro
Utilizar especificaciones estructuradas como Gherkin puede ayudar a limitar los malentendidos entre humanos y máquinas. Aunque estas especificaciones no son código, son lo bastante formales como para que las entiendan humanos y máquinas.
Aunque trabajar con especificaciones para probar y luego codificar puede ayudar a limitar los errores de IA en el resultado final, para ello es necesario que los desarrolladores cambien de mentalidad.
Deben dejar de ver a los LLM como expertos y pensar en ellos como una herramienta diseñada para amplificar la intención. Sin embargo, si la intención inicial es mala, el resultado del código también lo será.
Teniendo esto en cuenta, hay tres habilidades clave en las que los desarrolladores deben centrarse para mejorar su rendimiento y estar preparados para el futuro: escribir mejores instrucciones, validar los resultados y diseñar especificaciones claras. Quienes desarrollen estas tres habilidades clave tendrán más posibilidades de ser eficaces en sus carreras. Los que no lo hagan podrían acabar siendo sustituidos por la IA.
Reflexiones finales
La IA ha cambiado y sigue cambiando el desarrollo de software como nunca antes lo habíamos visto. Aunque puede codificar de forma más rápida y eficiente, su resultado no siempre es el previsto o contiene fallos lógicos, vulnerabilidades explotables, políticas de seguridad mal configuradas y mucho más.
Sin embargo, los desarrolladores pueden utilizar la cadena de integridad de la intención para mantener el control y garantizar que el código de IA se genera según lo previsto, alineando la intención humana con el resultado de la máquina mediante la estructura y la validación.
