La IA no genera bugs, pero está amplificando el problema.

A día de hoy es prácticamente imposible hablar de desarrollo de software sin hablar de IA. Ambas van tan de la mano que ya resulta raro no tenerla integrada en nuestro IDE y trabajar con ella constantemente en el día a día de una manera u otra.

Para este post parto de una premisa importante. La IA nos aporta muchísimas cosas positivas y se ha convertido en una ayuda indispensable, tanto para perfiles de desarrollo como para otros perfiles técnicos, entre los que me incluyo como QA.

A estas alturas ya existen muchísimos artículos hablando de las ventajas de utilizar IA. Sin embargo, me cuesta encontrar contenido que hable de ciertos problemas que se están detectando cada vez con más frecuencia debido a un uso “poco consciente” de esta tecnología.

Productividad aparente vs calidad real

La IA ha multiplicado nuestra capacidad para generar código y entregar funcionalidades a una velocidad que hace unos años parecía imposible. Eso, en la mayoría de los casos, es algo muy positivo.

El problema aparece cuando empezamos a medir la productividad en cantidad de: tickets cerrados, commits, automatizaciones… incluso el número de instrucciones hechas a la IA sin tener en cuenta la calidad de los mismos.

La velocidad ha aumentado, pero eso no siempre significa que la calidad lo haya hecho también o incluso que se haya mantenido al mismo nivel.

Hay veces que tendemos a tener prisas, incluso sin que nadie nos la exija. Si el Real Betis pudo esperar 6 meses la vuelta de Isco Alarcon de su lesión, seguramente un desarrollo pueda entregarse 2 días más tarde.

Igual que un futbolista puede recaer de su lesión si vuelve antes del tiempo necesario de recuperación, seguramente haya que retrabajar en el código entregado si no se le ha dado el cariño suficiente en todas sus fases.

De hecho, en muchos proyectos empieza a ocurrir algo peligroso. Se detectan más incidencias en fases tardías, aumentan las regresiones y el mantenimiento se vuelve más complejo, aún cuando aparentemente “se está avanzando más rápido”.

El problema y sus posibles causas

Aunque el post está escrito desde mi opinión, lógicamente basada en mis experiencias, tengo que reconocer que mi motivación para escribirlo viene tras mantener conversaciones con varios compañeros del mundillo.

Después de hablar con ellos, todos habíamos detectado una problemática común, que en mayor o menor medida estaba afectando en nuestros proyectos:

El número de bugs ha aumentado de forma considerable desde que la IA llegó a nuestras vidas.

No quiero que nadie me malinterprete, esto no es ni mucho menos una crítica a la IA. Simplemente, ahora somos capaces de producir más código en menos tiempo y no solo lo bueno se maximiza. Por ello y tal y como comentaba en la introducción, quiero dejar claro lo siguiente:

El problema no es la IA, el problema es cómo la estamos usando en algunos casos.

Definición de requisitos

Los requisitos son la base de todo desarrollo. Eran importantes antes y lo son aún más ahora. Tener unos buenos requisitos es una necesidad que existe desde siempre, pero que no se cumple en tantos proyectos como nos gustaría. Esto no es un problema nuevo y lógicamente nadie con o sin IA, puede hacer magia y entregar código sin tener claro qué se quiere.

La IA tiene un “problema” importante: amplifica muchísimo la calidad de la información que recibe. Cuando los requisitos son claros y bien definidos, la IA puede convertirse en una ayuda increíble:

• Acelera desarrollos
• Genera estructuras útiles y mantenibles,
• Propone soluciones válidas,
• Reduce muchísimo tareas repetitivas.

Pero cuando los requisitos son ambiguos, incompletos o incluso cambian constantemente, el efecto puede ser contrario.

Ese efecto contrario se está haciendo notar. Generalmente no hemos mejorado el nivel de los requisitos, pero estamos entregando una mayor cantidad de código generado a través de la IA. El resultado de esto no es otro que un aumento de número de bugs considerable en los últimos tiempos.

Desprofesionalización de la calidad de software

Cada vez se está dejando más la automatización de ciertas pruebas en manos de roles no específicos de calidad. Esto suele hacerse bajo la premisa de “cualquiera puede automatizar pruebas”.

Yo, sinceramente, creo que ahí existe una confusión importante entre saber utilizar una herramienta tipo Cypress o Playwright y entender realmente cómo asegurar calidad de software.

La automatización no consiste únicamente en generar y lanzar tests automáticos. La parte realmente compleja está en decidir cosas como:

• Qué merece ser probado
• Qué riesgos existen
• Qué impacto tiene cada cambio
• Qué escenarios son críticos

Ahí es donde el conocimiento de una persona especializada en calidad sigue siendo fundamental.

La IA puede ayudar muchísimo a generar tests o incluso suites completas de una forma muchísimo más rápida que una persona humana. Eso no garantiza que las pruebas sean buenas, útiles o estratégicas. Al igual que ocurre con el código entregado de la propia aplicación, los tests se deben analizar y entender.

De hecho, hay un riesgo que ya se empieza a ver. Hay una falsa sensación de cobertura y seguridad donde vemos muchos tests, mucha automatización y pipelines verdes pero a la hora de la verdad hay poca validación real de comportamiento crítico.

Al final esto se traduce en el problema que ya os debe ir sonando: los bugs se han incrementado debido a que muchas pruebas automáticas no cumplen su función a la hora de regresionar nuevos desarrollos.

Desarrollo consciente

Antes dije que los requisitos son la base de todo desarrollo, pero tengo que reconocer que no es de todo cierto. Para mí, la base de todo es y será las personas. Creo que uno de los mayores riesgos que estamos empezando a ver es cómo cambia la relación que algunas personas tienen con el código que producen.

Un desarrollador o desarrolladora consciente (por suerte la mayoría lo son) no es simplemente alguien que consigue que “la funcionalidad funcione”, es alguien que se ha involucrado en entender el requisito, cuestionarlo cuando es necesario, analizar impactos, pensar en escenarios alternativos y preocuparse por la calidad final del software que entrega.

La IA acelera muchísimo la generación de código, pero es la propia persona de desarrollo la responsable del código generado, por lo que es igual de importante que lo analice, entienda y pruebe antes de entregarlo.

Por desgracia, cada vez se están detectando más casos en los que el código generado por la IA se entrega sin ser analizado, entendido y probado, incluso casos en los que el código se genera por IA y la PR lo da por bueno.

A largo plazo, esto puede generar diferentes problemas como:

• Código poco mantenible.
• Personas de desarrollo estancadas técnicamente.
• Personas de desarrollo que no conocen perfectamente sus apps, ni funcional ni técnicamente.

Mi experiencia me dice que la persona de desarrollo que estaba involucrada antes de la IA lo está también ahora y quien no lo estaba antes, con IA se le ven más las carencias ya que ahora está entregando bastante más código.

Y es que la IA puede ayudarnos muchísimo a ser más productivos/as, pero no debería sustituir algo fundamental: la responsabilidad técnica sobre lo que estamos entregando.

¿Qué podemos hacer?

La IA ha llegado para quedarse y quién sabe hasta dónde va a llegar. Sería absurdo renunciar a todo el valor que nos aporta. El objetivo no debe ser usarla menos, sino usarla mejor. Generar código nunca había sido tan fácil y debemos “disfrutar” de ello.

Tengamos el rol que tengamos, considero que muchas de las soluciones son comunes para todo el mundo y que de una manera u otra todos tienen en común la pasión con la que cada uno hace su trabajo.

Debemos seguir insistiendo en tener unos buenos requisitos y si no nos los proporcionan, tenemos que ayudar a definirlos, ya que nadie conoce la app como quien la ha creado.

Debemos insistir en la importancia de que cada tarea la realice una persona especializada, dejando claras las consecuencias reales de qué pasa cuando esto no ocurre.

Por último, pero quizás la más importante, debemos tener una involucración real y pasional en cada una de las fases del ciclo de vida del producto, sin olvidar que la IA debe ser una herramienta de apoyo y no un sustituto de nuestra implicación.

“El verdadero problema no es si las máquinas piensan, sino si los hombres lo hacen.” B. F. Skinner.