Las herramientas de programación basadas en IA están transformando por completo el panorama del desarrollo de software. Hoy en día, los equipos de desarrollo recurren a herramientas como GitHub Copilot, Amazon CodeWhisperer y ChatGPT para generar código, corregir errores, crear la estructura de pruebas y acelerar tareas rutinarias. Código que antes requería horas ahora puede producirse en minutos (a veces en segundos). Saber formular buenos prompts se está convirtiendo en una competencia clave.
La IA ha llegado para quedarse. Su promesa es clara: mayor productividad, entregas más rápidas y menos trabajo repetitivo. Pero este aumento de velocidad plantea una pregunta más profunda y relevante:
¿Estamos construyendo mejor software o simplemente lo estamos haciendo más rápido?
En este blog exploramos esta cuestión desde la perspectiva del Software Craftsmanship, con una visión pragmática sobre cómo adoptar la IA sin sacrificar los principios que hacen posible construir software de calidad, mantenible y alineado con el negocio.
La verdadera productividad en el desarrollo de software no se mide por el número de líneas de código escritas ni por la velocidad al teclear. Se mide por la capacidad de los equipos de desarrollo para resolver problemas relevantes, garantizar la corrección de sus soluciones y dejar el sistema en mejor estado del que lo encontraron.
Ser productivo significa entregar de forma constante software valioso y mantenible, con la mínima fricción, retrabajo y riesgo. Esto requiere claridad, corrección y capacidad de cambio, no solo velocidad.
La IA nos proporciona un motor muy potente, pero la productividad sigue necesitando un volante. Cuando se confunde velocidad con progreso, los equipos acaban generando más código de baja calidad, aumentando el retrabajo y acumulando riesgos a largo plazo.
De hecho, muchos equipos están viviendo una paradoja habitual:
Las funcionalidades se entregan más rápido, pero aumentan los errores, las regresiones y la entropía del sistema.
Esto no ocurre porque la IA “programe mal”, sino porque la calidad del código, la modularidad, la capacidad de prueba y el conocimiento compartido del equipo son propiedades sistémicas que la IA no tiene en cuenta de forma automática.
La productividad del software es una propiedad del sistema, no de la velocidad individual de un desarrollador.
Generar código más deprisa no reduce necesariamente el tiempo de entrega ni el esfuerzo de mantenimiento. Si el código generado no está alineado con la intención del negocio o está mal diseñado, puede aumentar los costes futuros. La velocidad solo es productiva cuando refuerza la claridad, la corrección y la adaptabilidad.
Combinada con principios sólidos de ingeniería, la IA puede amplificar no solo la velocidad, sino también la efectividad, ayudando a los equipos a entregar mejor software en menos tiempo.
Cuando se habla de productividad en desarrollo de software, suele pensarse en lo rápido que un desarrollador puede escribir código, pero la investigación y la experiencia real muestran una imagen muy distinta.
Según un estudio de 2019 de Microsoft Research titulado “Today was a Good Day: The Daily Life of Software Developers”, y basándonos en otros análisis citados, es razonable estimar que menos del 25 % del tiempo de un desarrollador se dedica a editar código fuente.
La mayor parte del tiempo se invierte en leer código, navegar por el repositorio, comprender el comportamiento del sistema, asistir a reuniones, refinar requisitos o investigar problemas.
Aunque la IA puede ayudar en algunas de estas tareas, no sustituye la comprensión profunda del sistema, su diseño y su intención.
Esto deja claro que:
El verdadero cuello de botella no es lo rápido que escribimos código, sino lo rápido que entendemos qué hay que cambiar y dónde.
Aunque la IA acelere la generación de código, los equipos de desarrollo siguen necesitando comprender y razonar sobre el sistema existente. Pero cuando ese sistema es caótico (con límites modulares pobres, nombres inconsistentes, lógica duplicada o ausencia de pruebas) el coste de comprensión aumenta de forma significativa. En este caso la IA no elimina ese coste, si no que en muchos casos lo amplifica.
El problema no es lo rápido que podemos escribir código nuevo, sino cómo de rápido podemos cambiar lo que es necesario y entender con seguridad el código que ya existe.
Los principales obstáculos para una buena comprensión suelen ser:
Estos problemas se agravan cuando varios desarrolladores, apoyados por IA, generan código a gran velocidad sin mejorar la estructura subyacente. Más código no equivale a más valor si el sistema es cada vez más difícil de entender y evolucionar.
No son simples problemas de “higiene”. Son bloqueos sistémicos de la productividad. Sin abordarlos, ninguna aceleración basada en IA resolverá el problema; solo lo ocultará bajo más código.
La IA reduce el esfuerzo solo cuando ayuda a clarificar y simplificar, no cuando añade ruido. Aquí, el Software Craftsmanship actúa como garantía de que la aceleración no se produce a costa de la comprensión y la calidad.
Programar es una de las formas más precisas de comunicación humana. A diferencia del lenguaje natural, donde se espera ambigüedad, metáfora y matiz, el código fuente debe ser explícito, inequívoco y lógicamente coherente. Cada carácter importa, por eso la transición desde la intención humana hasta un software funcional siempre ha sido un desafío, y es también donde la IA generativa encuentra su mayor fricción.
Los modelos de lenguaje de gran tamaño (LLMs), como Copilot y ChatGPT, están diseñados para predecir y generar secuencias de texto plausibles, incluido código. Sin embargo, las entradas que reciben (nuestros prompts) están escritas en el mismo lenguaje natural impreciso e incompleto que utilizamos en la conversación. Incluso cuando un desarrollador tiene un objetivo claro, el prompt que redacta suele carecer de contexto, claridad o precisión. Y lo que es peor: la IA puede estar tomando como referencia una base de código que ya esté mal estructurada.
Nos encontramos así ante una situación en la que:
Este bucle de retroalimentación puede degradar rápidamente la calidad del sistema, especialmente cuando las bases de código carecen de una estructura semántica sólida, como demostró un estudio de la Universidad de Stanford. Un sistema mal modularizado, con límites de dominio débiles, nombres poco claros y patrones arquitectónicos inconsistentes, ofrece poca orientación a un LLM. La IA no tiene suficiente contexto de negocio, y su única referencia es el código existente, que puede ser a su vez un mosaico de prácticas incoherentes.
Sin fundamentos sólidos en diseño de software y modularización, las herramientas de IA tienden a amplificar los defectos existentes en la base de código. Por ejemplo:
En este escenario, el Software Craftsmanship se vuelve aún más importante. Un código bien modularizado, bien nombrado y bien probado no solo ayuda a las personas a navegar por el sistema, sino que también proporciona a las herramientas de IA mejores patrones con los que trabajar, como demostró el mismo estudio de la Universidad de Stanford que ya hemos referenciado antes. Solicitar un cambio dentro de un módulo claramente definido y con buena cobertura de pruebas tiene muchas más probabilidades de producir código correcto y mantenible.
Los LLMs operan en una zona gris entre el lenguaje difuso y el código determinista. Si el código base es deficiente y los prompts son vagos, incluso los modelos más potentes generarán soluciones de baja calidad. El mal código tiende a propagar más mal código.
Software Craftsmanship aporta la precisión que la IA necesita. Si la IA es la herramienta eléctrica el Software Craftsmanship es el diseño que la guía. Sin lo segundo, solo estaremos generando código más rápido, pero no mejor.
Una consecuencia de la IA generativa en el desarrollo de software que a menudo se pasa por alto es cómo esta nueva tecnología contribuye a que se acelere la pérdida de conocimiento. Tradicionalmente, cuando un desarrollador escribía una pieza de código, dedicaba tiempo a pensar la lógica, tomar decisiones de diseño, nombrar elementos y comprender cómo encajaba todo dentro del sistema. Este proceso, aunque a veces lento, ayudaba a interiorizar las reglas de negocio, las restricciones técnicas y los compromisos asumidos detrás del código que estaba escribiendo.
Pero cuando la IA genera ese código en cuestión de segundos, el desarrollador se convierte en un editor pasivo, no en un autor activo. El modelo mental y la comprensión profunda que surgen de enfrentarse a un problema se evaporan.
En una de nuestras recientes iniciativas de capacitación con un equipo de un cliente, un desarrollador envió una gran pull request con cambios en decenas de archivos. Cuando se le pidió que explicara la lógica de negocio detrás de la actualización o cómo se gestionaban determinados casos límite, la respuesta fue sorprendente: «No estoy seguro. Tendría que volver a mirar el código». Y, sin embargo, acababa de “escribirlo”. En realidad, la IA había generado la mayor parte de los cambios, y el desarrollador se había limitado a formular el prompt, copiar, pegar y realizar ligeras modificaciones.
No se trata de un caso aislado; más bien es un patrón que estamos detectando cada vez más a menudo.
Y lo que es peor, esto no ocurre solo a nivel individual. En las organizaciones modernas, los sistemas suelen ser grandes y distribuidos, construidos por múltiples equipos de desarrollo que trabajan en paralelo, muchas veces sobre varios microservicios. Cada desarrollador aporta una comprensión distinta del sistema, del dominio y de las buenas prácticas de diseño. Sus prompts varían, su contexto es diferente, y lo único de lo que dispone la IA como referencia es la base de código, que puede ser ya inconsistente o estar mal estructurada.
¿El resultado? Un desorden de lógica solapada, esfuerzos duplicados, implementaciones divergentes y deriva semántica entre servicios. Un solo cambio generado por IA, si no se revisa y comprende cuidadosamente, puede introducir inconsistencias sutiles que se propagan por el sistema. A medida que estas se acumulan, los equipos invierten cada vez más tiempo en reconstruir la intención que existe detrás de un código que nunca llegaron a entender por completo.
Software Craftsmanship ofrece un contrapeso a esta situación, ya que valora especialmente la comprensión compartida, la claridad semántica y el diseño intencional. En un mundo que avanza a un ritmo cada vez más acelerado, estos principios protegen la mantenibilidad a largo plazo y la eficacia de los equipos de desarrollo. Sin ellos, estamos construyendo sistemas que no comprendemos del todo, a una velocidad insostenible. Lo que sucede cuandoo los equipos de desarrollo generan grandes volúmenes de código sin entenderlo (o sin debatir/consensuar la intención de diseño) el conocimiento colectivo del equipo se erosiona. El código se convierte en una caja negra, incluso para quienes lo “escribieron”. Con el tiempo, los sistemas evolucionan de formas impredecibles y demasiado arriesgadas.
Craftsmanship ayuda a los equipos a mantenerse cerca del código, garantizando que la IA acelere la entrega sin desconectar a los desarrolladores de aquello que están construyendo.
Estamos argumentando cómo la dependencia excesiva de la asistencia de la IA podría erosionar las competencias básicas de ingeniería.
La revisión de código siempre ha sido uno de los mecanismos de control de calidad y de intercambio de conocimiento más importantes dentro de un proceso profesional de desarrollo de software. Una buena revisión detecta defectos de diseño, errores y malentendidos antes de que lleguen a producción. Pero para que las revisiones sean efectivas, los cambios revisados deben ser comprensibles, tener contexto y, de forma crítica, ser lo suficientemente pequeños como para poder razonarse sobre ellos. Cuando el código está generado por IA se altera este equilibrio.
Hoy en día los desarrolladores, impulsados por asistentes rápidos y potentes, pueden realizar cambios de gran alcance en decenas de archivos en cuestión de minutos. Lo que antes podía requerir días de reflexión cuidadosa, diseño e iteración, ahora puede generarse con unos pocos prompts y pegarse en la base de código. La velocidad resulta embriagadora, pero conlleva serios riesgos que hay que tener en cuenta:
¿La reacción natural ante una pull request masiva? Revisar por encima o, peor aún, aprobar sin analizar en profundidad, y en el momento en que las revisiones se vuelven superficiales, la calidad disminuye. Los errores se cuelan, las inconsistencias aumentan, la deuda de diseño se acumula, y lo que es peor, desaparece la oportunidad de aprendizaje compartido. La revisión de código no trata solo de aprobar cambios; va de construir una comprensión compartida dentro del equipo.
Este no es solo un problema de la IA; las pull requests grandes e imposibles de revisar siempre han sido un antipatrón, pero el hecho de que ahora la IA sea capaz de generar código a tal velocidad ha agravado el problema. Ahora es más fácil que nunca eludir la disciplina saludable de desarrollo en nombre de una mayor velocidad.
Software Craftsmanship propone un enfoque diferente:
La IA puede ayudar en este proceso, generando código repetitivo, sugiriendo mejoras y acelerando tareas rutinarias, pero solo si mantenemos el control sobre el ritmo y la escala del cambio. De lo contrario, corremos el riesgo de convertir el desarrollo en una cadena de montaje acelerada de código sin revisar, donde el coste de cada error solo se hace visible meses después.
La IA facilita realizar cambios grandes y de amplio alcance, pero es especialmente necesario revisar y validar esos cambios, especialmente cuando abarcan múltiples archivos o servicios, y esta tarea se vuelve más difícil. Cuando las revisiones son superficiales o se omiten por completo, la calidad del código se resiente y los errores se cuelan.
Utilizada con criterio, la IA puede seguir apoyando cambios pequeños y significativos. Los desarrolladores pueden formular prompts en pequeños pasos, manteniendo la capacidad de revisión y la modularidad intactas.
Nota: Actualmente estamos evaluando herramientas de revisión de código basadas en IA para analizar las PR conforme a nuestras propias directrices de calidad de código y diseño. Las pruebas iniciales son muy prometedoras. En futuras publicaciones aportaremos más información sobre esto.
En el desarrollo de software, la estructura es significado. Confiamos en la modularización semántica (límites arquitectónicos claros, nomenclatura significativa y responsabilidades bien definidas) para hacer que los sistemas sean comprensibles y mantenibles. Cuando una base de código está estructurada semánticamente, los desarrolladores pueden responder con rapidez a preguntas críticas tipo:
¿Qué hace este módulo? ¿Qué dominio de negocio representa? ¿Dónde debería realizarse este cambio?
Por desgracia, la mayoría de las bases de código están lejos de ser ideales. Los límites semánticos (o bounded contexts, si se prefiere la terminología de Domain Driven Design (DDD)) son difusos o inexistentes. La lógica de negocio está dispersa entre capas y servicios, la nomenclatura es inconsistente o genérica, las decisiones de modularización (si alguna vez existieron) están enterradas bajo años de deuda técnica. Y ahora, las herramientas de IA están aprendiendo y construyendo sobre este desorden.
Sin una base semántica sólida, incluso el asistente de IA más potente tiene dificultades para generar soluciones de alta calidad, y en su lugar, refuerza inconsistencias existentes, introduce duplicaciones adicionales y amplía clases y métodos que ya estaban sobredimensionados. Cada nuevo cambio erosiona un poco más la claridad, y el deterioro semántico se acelera con el tiempo:
El resultado es un sistema que funciona técnicamente, pero es conceptualmente incoherente; un mosaico de ideas, estilos y supuestos, que con cada linea nueva añadida se vuelve más difícil comprenderlo.
Craftsmanship, por el contrario, sitúa la semántica en el centro:
Cuando perdemos la semántica, perdemos precisamente aquello que hace que el cambio sea seguro, rápido y rentable. La IA puede ayudar en este ámbito, pero solo cuando está guiada por desarrolladores que comprenden los límites semánticos y saben formular prompts con intención. Combinar la velocidad de la IA con la conciencia de diseño propia de Software Craftsmanship puede ayudar a los equipos a preservar el significado y la estructura a gran escala.
Una de las prácticas más potentes dentro del Software Craftsmanship es el Test-Driven Development (TDD), no solo para garantizar la corrección, sino también para orientar el diseño. Empezar por un test ayuda a los desarrolladores a clarificar expectativas, descomponer comportamientos complejos y producir código más limpio y modular. Los buenos tests actúan como documentación y como mecanismo de retroalimentación del diseño.
TDD no trata solo de corrección, si no de escribir mejor código.
La IA está cambiando cómo escribimos código y, con ello, cómo escribimos los tests. Muchos desarrolladores generan ahora primero el código de producción y después piden a la IA que cree las pruebas, y aunque esto resulta cómodo, einvierte el flujo de intención. En lugar de que las pruebas definan el comportamiento, pasan a convertirse en un simple sello de aprobación de lo que el código ya hace, incluso si es incorrecto, ineficiente o no está alineado con los objetivos del negocio.
Esto da la vuelta por completo al propósito de las pruebas:
Cada vez es más habitual encontrar suites de pruebas llenas de:
Dicho esto, la IA puede ser una aliada muy potente en el ámbito de las pruebas, siempre que esté bien orientada, y los desarrolladores apliquen la mentalidad de TDD para interactuar con la IA de forma más estructurada. En lugar de pedir simplemente “código que haga X”, pueden proporcionar el contexto general y avanzar en pequeños pasos, describiendo en cada uno el comportamiento que esperan de un módulo concreto, las restricciones implicadas y las directrices de diseño relevantes.
También pueden ser muy precisos respecto a los nombres de clases, métodos, parámetros y tipos de retorno esperados. Además pueden detallar los distintos escenarios (variaciones de prueba) que desean cubrir, desde el caso ideal (happy path) hasta una lista de casos límite. Incluso pueden pedir a la IA que revise si falta algún escenario de prueba o si existen vulnerabilidades en el diseño propuesto.
Aunque la IA genere primero el código, el razonamiento propio de TDD sigue ayudando a formular mejores prompts, diseñar mejor y crear pruebas más útiles.
Algunos equipos incluso piden a la IA que escriba primero la prueba, o que ayude a refinar una ya existente antes de empezar a programar. Aunque este enfoque aún está evolucionando, apunta hacia un futuro interesante: la IA como colaboradora en el diseño, no solo como generadora de código.
En definitiva, probar no consiste únicamente en validar que algo funciona si no en proteger la calidad. Cuanto más entendamos la IA como una herramienta que amplifica el juicio humano, más podremos preservar la esencia de la Artesanía, incluso mientras construimos más rápido y a mayor escala que nunca.
La IA está revolucionando la forma en que escribimos código, pero sin orientación puede erosionar precisamente las cualidades que hacen que el software sea valioso. Ahí es donde entra en juego el Software Craftsmanship. Y con esta reflexión no abogamos por resistirse al cambio ni romantizar el pasado, si no defender principios atemporales que garantizan que el software siga siendo un activo y no un lastre, independientemente de cómo se construya.
En su esencia, la Artesanía es un compromiso con:
Software bien elaborado : código claro, comprobable mediante test, mantenible y alineado con las necesidades del negocio.
Profesionalidad: prácticas que aseguran la sostenibilidad a largo plazo, el crecimiento del equipo y la agilidad del negocio.
Colaboraciones productivas: verdadero trabajo en equipo entre desarrolladores y stakeholders, basadas en la confianza y la comprensión compartida.
Estos principios son más importantes que nunca en la era de la IA, porque los modelos de lenguaje de gran tamaño no entienden tu negocio, no se preocupan por tu arquitectura, no reconocen los compromisos y decisiones que estás tomando. Sin prompts reflexivos y un contexto de alta calidad, solo generarán código plausible y rápido, que puede crear tanta fricción a largo plazo como progreso en el corto plazo.
El Software Craftmanship ayuda de las siguientes maneras:
Definiendo el papel de la IA no como un programador autónomo, sino como un asistente potente que debe ser guiado.
Enfatizando la intención y asegurando que cada cambio refuerce la modularidad, la claridad y el significado para el negocio.
Protegiendo la corrección, integrando procesos de testing , pensamiento de diseño y revisión dentro del flujo de trabajo.
Frenando la entropía mediante prácticas coherentes, convenciones de nomenclatura y disciplina arquitectónica.
Lo más importante es que Software Craftsmanship adopta la IA sin renunciar a los estándares, porque reconoce que escribir código nunca ha sido el verdadero cuello de botella, y sí lo han sido la comprensión, la toma de decisiones y la calidad. La IA puede ayudar a acelerar la entrega, pero solo cuando los cimientos son sólidos, y ese es el verdadero desafío (y también la oportunidad, por supuesto) para los equipos de desarrollo actuales:
Utiliza la IA para ir más rápido, pero asegúrate de que estás avanzando en la dirección correcta y hazlo aplicando los principios del Sftware Craftmanship que te ayudarán a garantizar que tu código no solo se entregue con rapidez, sino que también conserve su valor con el paso del tiempo.
La IA está transformando el panorama del desarrollo de software, ayudándonos a programar más rápido, automatizar tareas rutinarias y explorar soluciones que quizá no habríamos considerado por nuestra cuenta. Pero velocidad no es lo mismo que productividad, y volumen no es lo mismo que el valor.
Si adoptamos la IA a ciegas, corremos el riesgo de inundar nuestros sistemas con código difícil de mantener y desconectado, generado con rapidez, mal comprendido y revisado de forma superficial.
Lo que necesitamos ahora es intencionalidad, una mentalidad que valore la claridad, la estructura y la mejora continua, y un compromiso con prácticas que preserven la agilidad del negocio, no solo que aceleren la entrega a corto plazo.
Ese es el papel de Software Craftsmanship en la era de la IA, no resistirse al cambio, sino guiarlo: Formular mejores preguntas, establecer mejores restricciones, asegurar que el software que construimos siga siendo robusto, comprensible y adaptable, incluso a medida que evolucionan las herramientas que utilizamos.
Craftsmanship convierte la IA en una aliada muy poderosa, no cediéndole el control, sino elevando el estándar de lo que significa “hacerlo bien” y garantizando que cada línea de código, escrita por IA o por humanos, contribuya al éxito a largo plazo.
El futuro del software no lo escribirá solo la IA, sino quienes sepan utilizarla con oficio.
La IA es el motor. Craftsmanship es la brújula.