Primeras reflexiones personales sobre IA, desarrollo de software y aprendizaje

Desde el primer momento en que probé un chatbot (ChatGPT) en 2022 tuve la sensación de que había caído un meteorito. En aquel momento lo enuncié así, ahora, en otras palabras, podemos decir que estamos ante una nueva especie: la “A” de artificial bien podría ser la “A” de alienígena (palabras de Yuval Noaḥ Harari, Historiador y escritor).

Estas son mis primeras reflexiones públicas sobre el uso de la IA en el desarrollo de software. No son conclusiones o recomendaciones cerradas. Son el resultado de usar IA de formas muy distintas: desde chats generales, pasando por GitHub Copilot con VS Code, hasta herramientas (agentes) más estructuradas como spec-kit o tidewave.ai. A día de hoy sigo manteniendo gran parte de mi entorno “clásico”, no por resistencia ideológica, sino por desconocimiento práctico de todo lo que está apareciendo.

Mi interés no está solo en programar con IA, sino en qué le hace la IA a todo el proceso de ingeniería del software… y, sobre todo, qué nos hace a nosotros como ingenieros, como profesores y como estudiantes.

Mi tesis ahora en este instante es sencilla:

La IA no cambia la esencia de la ingeniería del software, pero sí expone brutalmente quién la entiende y quién no.

1. ¿Qué cambia cuando programas con IA?

Personalmente, cuando trabajo con IA no siento que piense de forma distinta. Pienso igual pero hago cosas diferentes.

Delego más. Arranco proyectos más rápido. Pido explicaciones. Pido alternativas. A veces chateo demasiado y pierdo el tiempo. Otras veces avanzo mucho más rápido de lo que podría hacerlo solo.

No tengo ningún problema en delegar decisiones técnicas o de diseño en la IA, siempre que luego pueda entenderlas y revisarlas. El problema no es delegar. El problema es no tener criterio o tiempo para evaluar lo que devuelve.

Cuando la IA me propone una solución, lo primero que intento es entenderla. No comprobar si compila, sino si dice algo sensato. Si hay estructura, si hay intención, si hay señales de conocimiento real o simplemente bullshit bien redactado.

Aquí aparece una primera frontera clara:

• Si no sabes evaluar una solución, la IA no te ayuda.
• Te engaña. Te ofrece una falsa sensación de “ya lo tengo”.

2. El problema del texto infinito

Hay una experiencia muy común usando IA que creo que se comenta poco: quedarse mirando ensimismado cómo salen las palabras. Produce fascinación. Fascinación y pereza.

A veces dan ganas de decir: “hazlo todo tú, luego me lo enseñas y ya veré si lo entiendo, no me preguntes maś”. No me gusta esa sensación. No porque me preocupe perder comprensión o implicación, sino porque me preocupa perder el tiempo.

El problema no es que la IA explique mal. Es que explica demasiado.

Demasiado texto. Demasiada documentación. Demasiadas variantes. Demasiados artefactos generados. Leerlo todo es inviable. Ignorar algo, irresponsable. Un callejón sin salida.

De momento, no tengo una buena estrategia para esto. Y sospecho que no es un problema pasajero: es estructural.

A los estudiantes que se sienten abrumados por respuestas largas de la IA les diría algo muy poco popular:

No hables con la IA. Aprende por tu cuenta. Entrena tu propio cerebro

3. IA y especificaciones: se las toma en serio

Si hay algo que la IA está empujando con fuerza es el retorno a las especificaciones.

Históricamente nos ha costado ponerlas en el centro porque son difíciles de gestionar: se desestructuran fácilmente, se quedan obsoletas, nadie las mantiene o las mantienen diferentes personas con diferentes sensibilidades.

La IA, en cambio, puede trabajar con las especificaciones, resumirlas, contrastarlas y detectar inconsistencias mucho mejor que nosotros.

Herramientas como spec-kit me han resultado especialmente interesantes, no tanto por el resultado técnico, sino por lo bien pensados que están los prompts internos de cada fase del proceso. Ahí hay metodología embebida.

Además, la IA favorece claramente:

• el texto plano,
• los formatos versionables,
• los .md bien escritos,
• y, probablemente, futuros lenguajes textuales de especificación y diseño como SysML v2.

¿Quizá estamos volviendo —o avanzando— hacia una forma más literaria de la ingeniería del software? Eso me parece una buena noticia.

4. Buenas prácticas: inevitables

A veces se habla de la IA como si trajera nuevas buenas prácticas. No es cierto.

La IA no ha inventado nada que no estuviera ya en los textos de Parnas, Dijkstra, Brooks, Knuth, Liskov, Perlis, etc. Lo que sí hace es forzar su uso cuando los prompts son los adecuados.

Sin buenas prácticas:

• no sabes orientar a la IA,
• no sabes evaluar lo que produce,
• no sabes corregirla cuando se equivoca.

La IA no elimina la necesidad de entender las buenas prácticas del diseño, la modularidad, la abstracción o los procesos. La hace más evidente.

5. Estudiantes, IA y aprendizaje

Las IAs resuelven problemas mejor que los estudiantes de grado. Esto es un hecho. La IA es capaz de resolver los más de 100 ejercicios de mi hoja de ejercicios de la asignatura de introducción a la programación orientada a objetos.

Precisamente por eso, los estudiantes no están aprendiendo nada cuando copian y pegan de la IA. Un trabajo perfecto generado con IA no demuestra, obviamente, ni comprensión, ni criterio, ni aprendizaje. No demuestra nada.

¿Hay momentos en los que introduciría IA sin miedo? Sí: cuando el único objetivo es aprender. No para entregar actividades, no para aparentar.

Durante mucho tiempo, probablemente, la IA no debería jugar ningún papel en los primeros pasos del aprendizaje. No porque sea peligrosa, sino porque es demasiado buena.

Mi tesis aquí es que usar la IA te aleja de aprender a pensar como ingenieros.

6. Juniors, seniors y un problema social

Hay un escenario plausible a corto plazo que se discute poco: ingenieros con experiencia trabajando con agentes pueden ser más productivos que equipos enteros de juniors.

Esto plantea una pregunta incómoda:

Si los juniors tienen menos cabida, ¿dónde se aprende a ser senior?

Aquí la universidad no puede resistirse al cambio. Tiene que reaccionar. Enseñar a usar la IA como muleta, no como sustituto. Enseñar a pensar, revisar, corregir, orientar. Probablemente necesitaremos asignaturas en los últimos cursos que enseñen a crear y usar agentes.

Cierre

Creo que este alien que ha venido para quedarse no es una “bala de plata” para la ingeniería del software porque creo que la esencia de la ingeniería del software no es solventable por una inteligencia superior: “Creo que la parte difícil de construir software es la especificación, el diseño y la validación de este constructo conceptual, no el trabajo de representarlo ni de comprobar la fidelidad de esa representación. Seguimos cometiendo errores de sintaxis, desde luego; pero son ruido comparados con los errores conceptuales que hay en la mayoría de los sistemas.” No Silver Bullet —Essence and Accident in Software Engineering, Frederick P. Brooks, Jr. (1986)

Ojalá este texto envejezca mal.