Todas las profesiones que absorbieron una herramienta transformadora siguieron el mismo patrón de tres actos. La ingeniería de software está en el Acto Uno.
Alguien preguntó hace poco en un hilo de LinkedIn si las herramientas de IA están cambiando realmente la ingeniería de software o si solo están haciendo que el trabajo existente sea más rápido. El hilo de comentarios fue más interesante que la pregunta misma: cientos de desarrolladores experimentados, divididos entre “esto lo cambia todo” y “esto no cambia nada”. Lo que me llamó la atención es que ambos bandos tenían razón, y ninguno parecía darse cuenta. Ya hemos visto este mismo debate antes, en profesiones que ya absorbieron su versión de este momento. El patrón tiene tres actos, no dos — y el tercero es la parte de la que nadie quiere hablar.
Acto Uno: Llega la herramienta
En 1979, Dan Bricklin lanzó VisiCalc, la primera hoja de cálculo electrónica para computadores personales. Antes de VisiCalc, la contabilidad era un proceso físico. Filas y columnas en libros de papel, lápiz en una mano, calculadora en la otra. Cambiar un solo número significaba recalcular todo lo que dependía de él — a mano. Bricklin recordó después haber mostrado VisiCalc a contadores y observar su reacción: personas que habían pasado semanas enteras en cálculos manuales entendieron inmediatamente lo que estaban viendo.
VisiCalc, y más tarde Lotus 1-2-3 y Excel, no solo aceleraron la aritmética. Redujeron el tiempo entre preguntar “¿qué pasa si…?” y ver la respuesta. Un modelo financiero que tomaba días en recalcularse podía actualizarse en segundos. La herramienta no cambió la esencia de la contabilidad — cambió qué tanta parte del trabajo era repetición mecánica.
El mismo patrón se repitió en la ingeniería y la arquitectura. Antes del software CAD, el dibujo técnico era un oficio enteramente manual: pluma, transportador, compás y años de entrenamiento para producir un solo conjunto de planos técnicos. El CAD no redujo la necesidad de entender la integridad estructural, los materiales o el razonamiento espacial. Automatizó el acto mecánico de traducir ese entendimiento al papel. El conocimiento permaneció; el medio cambió.
Acto Uno: La profesión se eleva
Aquí es donde la historia suele detenerse en el relato optimista: la herramienta automatiza las partes tediosas y la profesión se eleva a su verdadero potencial.
Y esa parte es genuinamente cierta. Cuando las hojas de cálculo se encargaron de la aritmética, los contadores finalmente pudieron dedicar su tiempo al trabajo al que la aritmética siempre debió servir: modelado financiero, planeación estratégica, análisis forense y trabajo de asesoría. El pensamiento que era perpetuamente desplazado por el cálculo finalmente tuvo espacio para respirar.
En ingeniería, el CAD no solo hizo que el dibujo fuera más rápido; fusionó los roles anteriormente separados de dibujante, diseñador e ingeniero. Los profesionales que entendían los principios subyacentes ahora podían iterar rápidamente en los diseños, simular cargas de estrés y colaborar en modelos tridimensionales. La herramienta expandió lo que era posible, y la profesión se movió hacia un trabajo de mayor criterio.
Este es el acto que la gente suele citar cuando habla de la IA y la ingeniería de software. Y tienen razón al hacerlo; el paralelo es claro. Las herramientas de programación con IA están automatizando la capa mecánica del desarrollo de software: código repetitivo (boilerplate), andamiaje (scaffolding), refactorización repetitiva, generación de pruebas. El conocimiento subyacente —diseño de sistemas, intuición para la depuración, comprensión de las compensaciones a escala— no se va a ninguna parte. La profesión tiene espacio para elevarse.
Acto Tres: La parte que nos saltamos
Pero el registro histórico tiene un tercer acto, y saltárselo hace que los dos primeros sean menos creíbles.
Cuando las hojas de cálculo transformaron la contabilidad, EE. UU. perdió aproximadamente 400,000 puestos de auxiliares contables, los roles que se definían predominantemente por el cálculo manual. Al mismo tiempo, el número de contadores trabajando en roles de mayor nivel creció en unos 600,000. La profesión no se redujo; se desplazó. Pero ese cambio no fue indoloro. Los contadores cuyo valor se concentraba en el trabajo mecánico —la precisión de su aritmética, la velocidad de sus cálculos— descubrieron que su habilidad específica ya no era escasa. La herramienta lo hacía mejor y más rápido.
Lo mismo ocurrió con el dibujo manual. A medida que las herramientas CAD se volvieron más accesibles, la demanda de dibujantes especializados cuyo valor principal estaba en el acto físico de producir planos disminuyó. La profesión no desapareció, sino que fue absorbida por roles más amplios: diseñadores e ingenieros que ahora podían hacer sus propios dibujos. La habilidad mecánica independiente perdió su valor premium.
He aquí el paralelo incómodo: en cada caso, la línea divisoria no fue la antigüedad ni los años de experiencia. Fue si el profesional entendía el propósito debajo del proceso. Los contadores que entendían el razonamiento financiero se adaptaron. Aquellos cuya experiencia estaba fundamentalmente en la mecánica de las hojas de cálculo, irónicamente, no tuvieron la misma ventaja. Los ingenieros que entendían los principios estructurales usaron el CAD para amplificar su criterio. Aquellos que principalmente sabían cómo producir dibujos limpios en una mesa de dibujo tuvieron una transición más difícil.
La pregunta que importa
La ingeniería de software está en medio del Acto Uno ahora mismo. La herramienta ha llegado y está automatizando la capa mecánica: el boilerplate, el scaffolding, el trabajo a nivel de sintaxis. El Acto Dos ya es visible: los desarrolladores que entienden los sistemas subyacentes están usando la IA para moverse más rápido hacia el trabajo que siempre importó. La profesión se está elevando.
Pero el Acto Tres también viene en camino, y fingir lo contrario es un flaco favor para cualquiera que navegue este momento con honestidad. Los desarrolladores cuyo valor está principalmente en escribir código —en el acto mecánico de convertir especificaciones conocidas en sintaxis funcional— están en la misma posición que los auxiliares contables de 1979. No porque sean malos en su trabajo, sino porque la definición del trabajo está cambiando.
Este no tiene por qué ser un enfoque pesimista. En cada caso histórico, la profesión terminó siendo más fuerte, más interesante y más valiosa en general. Pero la transición no fue automática. Requirió que los profesionales se movieran hacia el trabajo más difícil y de mayor criterio que el trabajo mecánico siempre había desplazado.
La pregunta no es si la IA cambiará la ingeniería de software —ese patrón ya se está repitiendo—. La pregunta es qué versión de la ingeniería de software has estado practicando: la aritmética o el modelado financiero. Ahora es un buen momento para ser honestos con la respuesta.
Siguiente paso: Audita a qué dedicas tu tiempo esta semana. Haz un seguimiento de la división entre la implementación mecánica (escribir boilerplate, actualizar configuraciones, traducir especificaciones a código) y el trabajo de criterio (decisiones de arquitectura, depuración de comportamientos complejos, evaluación de compensaciones). La proporción te dirá algo importante sobre dónde te sitúas en este cambio.
Ruta de aprendizaje: El análisis de Tim Harford sobre VisiCalc y la profesión contable ofrece una mirada más detallada a los datos económicos detrás de estas transiciones. Para una perspectiva enfocada en el desarrollador, el próximo artículo de esta serie explora cómo se ve este cambio en la práctica, incluyendo la deuda profesional que las herramientas de IA están a punto de cobrar.