La IA exige más disciplina de ingeniería, no menos
(charitydotwtf.substack.com)- Que haya mejorado la calidad de la generación de código con IA no es una señal para abandonar la revisión de código, sino para exigir con más fuerza la validación y la disciplina operativa en un entorno donde el código puede regenerarse de forma barata y rápida
- Desde finales de 2025, después de Opus 4.5, la IA puede producir código más rápido y más barato, y con una calidad cercana a la de un ingeniero de software de nivel medio al menos en patrones comunes; esta transición está respaldada por agentic harness, uso de herramientas, function calling y MCP
- A medida que el costo de producir código se acerca casi a 0, las líneas de código dejan de ser un activo valioso que hay que preservar y pasan a parecerse más a una caché regenerable que materializa el entendimiento actual
- Así como la infraestructura inmutable hizo que se reemplazaran los servidores en ejecución en vez de corregirlos, en la era de la IA el código de aplicación también hace que la validación del comportamiento, los characterization test, capture/replay, la división de tráfico y la observabilidad sean más importantes que el cambio en sí
- Los sistemas no deterministas exigen disciplina de ingeniería —como traces, evals en producción y ciclos rápidos de retroalimentación— más que depender de humanos resistiendo como puerta de calidad, y la IA no elimina el hecho de que el software sigue necesitando tecnólogos y disciplina
La economía de la producción de código se invirtió en 2025
- Durante la mayor parte de 2025, era razonable y predominante la idea de que el código generado por IA era “slop” y que probablemente seguiría siéndolo
- Después de Opus 4.5 en noviembre de 2025, la IA pasó a poder generar, al menos en patrones comunes, código de una calidad comparable a la de un ingeniero de software de nivel medio, mucho más rápido y más barato
- Opus 4.5 fue menos una causa única y más un punto de inflexión
- un agentic harness es una estructura de código que pone al LLM en un loop junto con herramientas
- estos harnesses se volvieron algo realista a mediados de 2025, y sus señales previas se remontan hasta finales de 2024
- el tool use, function calling y MCP se fueron acumulando durante 2025 y llevaron a una usabilidad general hacia finales de año
- En el primer cambio podía tolerarse el escepticismo de “lo creeré cuando lo vea”, pero cuando vuelve a aparecer un cambio a la misma velocidad, se vuelve difícil mantener la misma postura
El código pasa de activo valioso a resultado regenerable
- El cambio central ocurrido en 2025 fue que se invirtió la economía de la producción de código
- se pasó de una situación en la que generar código era difícil, tardado y costoso, a otra en la que es prácticamente inmediato y barato
- las líneas de código dejaron de ser algo que se reutiliza y se cuida, y pasaron a ser algo desechable que puede volver a crearse
- También existe una visión según la cual el verdadero resultado de un equipo de ingeniería de software es el entendimiento compartido
- ese entendimiento se almacena como una caché en la cabeza de las personas, y se vuelca a disco en commits de GitHub y despliegues a producción
- pero la memoria humana se olvida con facilidad, se adormece con la repetición y tiende a pasar por alto pequeños detalles
- los modelos mentales siguen desalineándose con el mundo que los usuarios realmente encuentran
- Desde la perspectiva de SRE, el verdadero resultado de un buen equipo de software está en producción
- “Only prod is prod”
- la producción no debe tratarse como un lugar posterior al desarrollo, sino como una etapa del desarrollo
La similitud entre Phoenix Architecture e infraestructura inmutable
- Honeycomb emitió un AI mandate en agosto de 2025 y consideró que, como empresa de devtools, debía abordar los problemas difíciles de la tecnología más reciente
- Phoenix Architectures de Chad Fowler conecta la era del código con IA con la infraestructura inmutable
- Chad Fowler fue quien acuñó la expresión “immutable infrastructure” en 2013
- Relocating Rigor es el texto mencionado por Martin Fowler en un resumen de meetup de Thoughtworks
- La idea central de The Death and Rebirth of Programming es no corregir lo que está corriendo, sino reemplazarlo
- immutable infrastructure, servicios stateless, contenedores, blue-green deployments e infrastructure as code comparten la misma premisa
- la IA extiende esa premisa desde la infraestructura hacia el código de aplicación
- cuando baja el costo de reescritura, corregir en el lugar se vuelve riesgoso, la mutación acumula entropía y el reemplazo la reinicia
- The Deletion Test propone imaginar que se elimina toda la implementación
- si borrar da miedo, es porque no se sabe cuál es el comportamiento necesario, qué fallas son inaceptables, qué invariantes siempre deben mantenerse y con qué criterio juzgar la corrección de una nueva versión, más que por el código en sí
- no saber qué bug corregía un arreglo de un caso borde olvidado es el mismo problema
- no es un problema de código, sino un problema de evaluación
- Cuando el código es el único lugar donde vive el conocimiento, el código se vuelve valioso
- antes era razonable tratar el código como un activo persistente porque el trabajo de producirlo era el cuello de botella
- cuando regenerarlo se vuelve fácil, el código funciona más como una vista materializada del entendimiento: útil por ahora, pero descartable cuando envejece
El código debe poder regenerarse como se regenera un servidor
- La experiencia de pasar de servidores mascota hechos a mano a ganado de infraestructura inmutable dejó una lección: la mutabilidad es enemiga del entendimiento
- si corriges en el lugar un resultado que está ejecutándose, aparece drift
- el drift hace más difícil mantener el sistema
- Honeycomb mata el nodo de Kafka más antiguo con un cron cada martes
- gracias a eso puede tener confianza en que el proceso de bootstrap y balanceo es repetible
- los datos son regenerables y las promesas importantes están en otra parte
- Si no puedes regenerar el código de la misma manera, es señal de que no lo entiendes lo suficiente
- no sabes qué promesas hiciste
- no sabes qué dependencias se van a romper
- la mayoría de las veces lo descubres rompiéndolas
- Las migraciones largas y dolorosas, los rewrite, el reemplazo de legacy code y strangler fig son casos en los que las líneas de código cargaban demasiada responsabilidad
- en el código quedaban atados la intención de los desarrolladores, las expectativas de los usuarios, los comportamientos implícitos y explícitos, y los rastros de bugs pasados
Lo que se revisa no son solo líneas de código
- Como mantener y cambiar líneas de código era costoso, otros resultados no pudieron desarrollarse lo suficiente
- faltan resultados que permitan entender y discutir cómo cambia la arquitectura
- muchas veces la propia arquitectura solo puede inferirse vagamente a partir del código
- La dirección ideal se parece más a discutir y acordar diagramas de arquitectura, y luego regenerar el código a partir de ese cambio
- No puede asumirse que todo el código vaya a ser generado por IA según especificaciones, saltándose la comprensión humana
- el rango total de lo posible depende de qué es un spec o de qué podría llegar a ser
- quien haya pasado por una migración de base de datos dolorosa debería saber que extraer y formalizar las expectativas de los usuarios en una forma reproducible y automatizable es algo difícil
- Las herramientas aún no existen, pero las ideas relacionadas ya están aquí
- entre ellas están los behavioral test, characterization test, capture/replay y traffic splitter venidos de operaciones y QA
- estas técnicas se parecen más a observar y codificar lo que realmente está ocurriendo que a definir qué debería ser correcto
- aquí también entra la observabilidad en el buen sentido
Los humanos no son adecuados como puerta de calidad para validación
- El código no determinista en producción obliga a hacer cosas que ya debían hacerse desde antes
- instrumentación de traces
- test y eval en producción
- tratar producción no como algo posterior al desarrollo, sino como una etapa de desarrollo
- El cerebro humano no está hecho para la validación
- es peor que las máquinas para seguir comprobando diferencias repetitivas y triviales
- si el papel del humano se limita a su capacidad de ser una puerta de calidad, la calidad del software se vuelve frágil
- Los humanos pueden conservar durante mucho tiempo su papel en creatividad, inspiración y saltos lógicos, pero es difícil ponerlos como la entidad que vence a las máquinas en validación
La conclusión de la era de la IA es el regreso de la disciplina
- La razón por la que el discurso de IA de los últimos dos años resultó extraño y atemorizante para muchos ingenieros fue que algunas voces de IA parecían decir que el software ya no era un problema de ingeniería
- “SaaS is dead”
- “Making AI great at coding was the strategy that unlocks everything else”
- Adam Jacob es presentado como alguien que anticipa un gran cambio en los empleos de software
- Si 2025 fue el año del vibe coding, 2026 parece el regreso de la disciplina
- a medida que la IA genera líneas de código al nivel de un ingeniero de software de nivel medio, el rango de futuros posibles se amplió de forma inestable
- el conocimiento que está en la cabeza no puede ser usado por la IA hasta que se codifique en el sistema
- Son muy pocos los equipos de software que trabajan con ciclos de retroalimentación rápidos y cortos
- se presenta una proporción de alrededor de 5%, y claramente por debajo de 10%
- las herramientas de IA pueden acercar esta forma de trabajo más que antes
- Que la IA por sí sola, sin disciplina de ingeniería, produzca enormes retornos de inversión no es una preocupación inmediata
- muchos equipos lo intentarán, pero lo valioso está respaldado por la durabilidad, no por la desechabilidad
- Los usuarios no quieren que cada día que inicien sesión en Slack cambien sutilmente los botones y menús
- tampoco quieren que las transacciones financieras se completen solo en la mayoría de los casos
- el determinismo no va a desaparecer
- La IA no es magia y el software sigue siendo ingeniería
- la tecnología necesita tecnólogos
- lo que habrá que revisar en adelante no serán solo líneas de código, sino una gama más amplia de otros resultados de ingeniería
1 comentarios
Comentarios de Hacker News
Ahora es mucho más difícil distinguir entre quién entiende el sistema y usa la IA de forma efectiva, y quién no entiende nada y solo anda pegando y copiando de LLM
Antes de 2025, la gente de bajo rendimiento o que solo sobrevivía tendía a quedar más expuesta porque aportaba poco, pero ahora todos los ingenieros producen PR, code reviews, documentos de diseño técnico, etc., con una forma aparentemente convincente
También influye mucho que los C-level presionen con fuerza para usar IA al máximo, y desde la perspectiva de cada ingeniero también es una respuesta de teoría de juegos favorable producir lo más posible
Nos estamos ahogando por completo en documentos y código que parecen plausibles, y para procesar todo ese volumen terminamos dependiendo otra vez de la IA
Siento que la resaca de esta etapa será una forma extraña de deuda técnica, especialmente marcada por la escala
A los LLM les encanta producir mucho y agregar cosas, pero los ingenieros realmente competentes generan más resultados de negocio con menos código y menos piezas en movimiento
Escucho seguido cosas como: “Quiero usar IA para automatizar un proceso, pero la documentación del proceso no está completa, así que espero que la IA ayude”
Aunque les expliques que no se puede crear un resultado desde la nada, todas las discusiones sobre IA terminan volviendo al mismo punto
Incluso la solución propuesta para crear la documentación que iría en esa automatización con IA es usar IA, así que parece un ouroboros en el que la IA crea documentos, la IA los resume y la IA los explica
Con el código va a pasar lo mismo: la IA generará miles de líneas y luego otra vez habrá que usar IA para explicarlas
Hoy, gracias a los LLM, es demasiado fácil parecer diligente si uno solo mira el volumen de contribuciones
La diferencia ahora es que una persona incompetente puede producir literalmente varios órdenes de magnitud más output que un ingeniero prudente y con experiencia
El PR no es una barrera perfecta, pero es una de las pocas barreras reales que tenemos ahora mismo, y suele quedar bastante claro quién se está esforzando y quién no
Supongo que las preguntas de algoritmos en entrevistas ya filtraron por completo a quienes fingían tener conocimiento de sistemas, ¿no?
Coincido con eso de que “no es un problema de código sino de evaluación” y de que “el código se vuelve valioso cuando el conocimiento vive solo dentro del código”
Pasarse el día leyendo código escrito por IA es doloroso, y además es una forma terrible de derretirte el cerebro justo en el momento en que más necesitas ser competente
La programación manual tiene un ciclo de retroalimentación productivo y satisfactorio: lees código, lo escribes, y lo corriges hasta que compila, corre o hace lo que quieres
El código de IA no solo reemplaza la mitad de eso, sino que además el momento final del “clic” también se siente menos gratificante. No puedes estar seguro de no haber hecho alguna trampa menor para llegar hasta ahí
Tomar el código generado por IA como el único output duradero de la programación es un callejón sin salida para la industria
Lo que Charity señala como el espacio de trabajo interesante, y lo correcto de desechar, son los diagramas de arquitectura y las especificaciones
Mi sospecha es que eso está más cerca de los prompts, planes en Markdown e instrucciones guía escritos directamente por humanos
Hay que enfocarse en lo que uno mismo produce como humano para que sirva de base al ciclo central de “¿la IA siguió mis instrucciones?”, y eso también da más apalancamiento en code review
Para cuando llegas al PR, ya le habrás dado suficiente input a Claude como para poder regenerar el código, pero el default actual de la industria es tirar toda esa sesión y desplegar solo el código. Está al revés
Los bloques grandes de código son prácticamente imposibles de revisar para un humano, pero cuando hay un LLM involucrado mucha gente parece olvidarlo
Todos los días llega una pila enorme de código para revisar, y es realmente agotador
Aun así, siento que la IA es mejor, porque si dejas las reglas por escrito, al menos tiende a seguirlas
Muchos desarrolladores offshore repiten los mismos errores todos los días
Parece que en nuestra empresa necesitamos contratar mejores desarrolladores offshore
Antes, parte de mi modelo mental del sistema que construía mediante el acto de programar ahora lo estoy formando dependiendo de la revisión de código
Se está volviendo más difícil entender y recordar los detalles del sistema, lo cual no sorprende si piensas que la información que uno mismo “genera” se recuerda mejor que la que solo se leyó
Estoy aplicando a la expansión del code review lecciones extraídas de la pedagogía, y si esto te resuena me gustaría conversarlo
Como parche temporal, quizá podrías hacer que Claude escriba un resumen de la sesión como parte del mensaje de commit, pero me gustaría saber si hay alguna herramienta más estructurada y de mayor nivel
Si quieres código verificable que siga un plan bien diseñado, en la práctica tendrías que escribir pseudocódigo y dejar que la IA lo traduzca
Si es así, entonces uno se pregunta por qué dejar que la IA escriba el código en primer lugar
Personalmente, me divierte más planear, escribir y debuggear por mi cuenta. Esa era precisamente la parte que me hizo enamorarme de programar desde el principio
Últimamente he estado pensando mucho en esto
Buena parte de mi intuición sobre el desarrollo de software se basa en 25 años de experiencia acumulada sobre “cuánto tarda escribir cierto código”
Cuando pienso si agregar validación para casos límite que no rompen todo, pero sí pueden ensuciar un poco las cosas si alguien tropieza con ellos, puede que lo omita si implica unas cuantas horas más de código
Pero si basta con un prompt, ¿por qué no hacerlo?
Para que una nueva función sea más fácil de entender, estaría bueno tener un explorador de API dedicado, pero antes probablemente no se habría podido justificar la inversión
Pero si con Codex se hace en 10 minutos, la historia cambia, y de hecho así fue: https://tools.simonwillison.net/datasette-extras-explorer#ur... también enlazado en las notas de la versión https://docs.datasette.io/en/latest/changelog.html#extra-sup...
A una escala mayor, hay proyectos que antes ni siquiera habría considerado. Necesitaba una biblioteca personalizada para parsear consultas
SELECTde SQLite, pero no lo suficiente como para dedicarle más de una semanaPero ahora sí es posible: https://github.com/simonw/sqlite-ast
Decir que poder producir líneas de código más rápido tiene valor hace que mucha gente se enoje y hasta lo mire por encima del hombro
Claro que medir la producción por “número de líneas de código” es una tontería
Pero medir el número de líneas de código validadas que entregan valor no es una tontería, y ahora podemos hacerlo más rápido
Google es valiosa porque absorbe datos y genera ingresos por publicidad, y porque sus gastos son pequeños en relación con esos ingresos
¿Y todas esas “apuestas”? Qué gracioso, ¿y cómo terminaron?
La ingeniería por la ingeniería no tiene ningún valor para la economía, o sea, no significa nada
La verdad incómoda que nadie quiere oír es que, en un momento dado, dentro de una economía solo puede existir una cantidad limitada de cosas, y solo sobreviven las que son valiosas y económicamente sostenibles
Hay mucha gente a la que no le importa, pero también la hay a la que sí
Me gustó este post, y como parece que muchos otros comentarios no, dejo lo que pienso
Cuando empiezo con una base de código nueva, ¿cómo me vuelvo un contribuidor útil lo más rápido posible? Voy directo a la documentación escrita por personas
Verifico cuál era el problema que este sistema intentaba resolver originalmente, cuál era el diseño original, cuáles son los mayores problemas y quién lo usa hoy
Saber esto me permite inferir por qué se construyó de esa manera, lo que hace mucho más fácil leer el código
Este post del blog también se volvió popular: https://blog.gpkb.org/posts/just-send-me-the-prompt/
Parece que Charity ve un problema muy antiguo y espera que una tecnología nueva lleve a algún tipo de solución nueva
No creo que considere que la generación actual de herramientas sea el final de la historia del desarrollo de software con IA
Tampoco está diciendo que le tires el documento de diseño a Claude code y te vayas. Los documentos de diseño tampoco son completos, así que al hacer onboarding también hay que hablar con personas y leer tickets viejos y análisis post mortem
En producción, como no nos gusta que sea difícil entender por qué la infraestructura terminó en su estado actual, hoy hacemos infraestructura como código
Las bases de código también tienen como estado por defecto que “es difícil entender por qué terminaron en su estado actual”, y eso es un problema observado desde antes de “Programming as Theory Building”
Así que, al igual que pasó con la infraestructura, parece razonable esperar que el desarrollo de software también cambie hacia herramientas centradas en dejar más claro “por qué el código terminó en su estado actual”
Es cierto que al entrar a una base de código nueva lo correcto es empezar por las personas y la documentación escrita por personas, pero en muchos equipos de ingeniería esa documentación no existe en absoluto
Las decisiones se toman en la cabeza de un ingeniero o en chats que no quedan guardados, y las especificaciones eran unas cuantas líneas de notas en tickets que luego se borraron durante una limpieza, o desaparecieron cuando cambiaron la herramienta de seguimiento
No hay mapa de la base de código ni de las funcionalidades, no hay ADR y la observabilidad es mínima
Lo único que queda es el código, así que toca leerlo para averiguar qué está pasando y preguntarle al ingeniero que hizo commits recientes en cierta área si se acuerda por qué lo hizo así
Cuando alguien hace un cambio, a veces se rompe una parte del otro extremo de la base de código que parecía no tener ninguna relación
Sí hace falta más disciplina con la IA, pero en teoría esa disciplina puede aprenderse mucho más fácilmente que convertirse en un buen ingeniero
Hace 20 años, para escribir buen código C escalable había que ser un genio o estar totalmente dedicado a la tecnología misma
Había que conocer a fondo un montón de herramientas como ASan, LSan, UBSan, TSan y GDB, y si además tocaba leer archivos DWARF a mano, peor todavía
En la práctica era difícil dominar todo eso en poco tiempo, y al mismo tiempo también había que aprender diseño de sistemas, que es una habilidad aparte y casi ortogonal
Ahora basta con conocer los riesgos del lenguaje y del framework que usas, indicarle al LLM que los pruebe, tener la infraestructura para verificar si realmente probó lo suficiente y luego leer las pruebas reales y la implementación
Leer y entender Rust es mucho más fácil que depurar los errores casi mágicos que aparecen al desarrollar en Rust
También es más fácil detectar que cierto escenario necesita una prueba con Loom y crear herramientas para verificar si realmente se escribió
Aunque sigas usando C o Zig, es mucho más fácil saber cuándo hay que usar cada herramienta y detectarlo que aprender a dominar cada una por separado
Leer SQL no es difícil y casi la mitad de la gente de negocios puede hacerlo. Python apenas es un poco más difícil, y Rust también se puede entender leyendo una guía de 50 páginas, lo cual es un costo muy pequeño comparado con pasar 10 años aprendiendo a fuerza de prueba y error
No me queda claro el camino de “los LLM funcionan de maneras que no podemos conocer” a “por eso hace falta más disciplina” y de ahí a “todo está bien”
Estoy de acuerdo con que todo está bien, pero no me parece que ese proceso mental trace un camino claro
Si alguien tiene la voluntad de hacer que esto funcione y dedica un poco de tiempo a entender qué hace que falle, puede lograr cosas enormes usando LLM
Como los LLM vuelven casi gratuito el costo de crear cosas complejas, en realidad van a hacer que la situación sea mucho más compleja
La ingeniería siempre ha tratado sobre disciplina y sobre hacer que las cosas funcionen, pero antes hacía falta un conjunto previo de habilidades técnicas para poder aportar valor
La mayor parte de eso ya desapareció, y ahora es mucho más fácil que antes
La disciplina sigue siendo necesaria, pero comparada con pasar 10 años rodando entre las llamas, la disciplina es barata
Acabo de pasar una semana revisando este PR de unas 200 líneas: https://github.com/ncruces/wasm2go/pull/37
Lo envió un usuario avanzado y es muy probable que haya consultado a un LLM de punta
Aun así, sentía que algo estaba mal. No lo entendía, y no pensaba mergearlo sin entenderlo
También sospechaba que estaba mal de una forma que causaría problemas en el futuro
Así que lo revisé de cuatro maneras: entenderlo y mejorarlo, hacerlo con un algoritmo mejor, evitarlo arreglando el problema upstream, o reescribirlo desde cero para que encajara con mi cabeza
Esperaba que la respuesta fuera la segunda o la tercera, pero la segunda, aunque era la correcta, implicaba rehacer el proyecto desde cero, y la tercera, aunque de verdad esperaba que funcionara, no funcionó
Al final terminé mezclando la primera y la cuarta, y todavía no tengo certeza total, pero ahora sí entiendo el problema y la solución
Claro que creo que mi enfoque es mejor
Aun así, hice que un LLM revisara ambas versiones después de quitarles los comentarios
El LLM respondió que el PR original era claramente mejor y, cuando le expliqué por qué no, respondió que yo tenía razón
Si pongo comentarios y vuelvo a intentarlo, los LLM dicen que el mío es mejor, porque encontré el problema real
Pero no sé si dicen que el mío es mejor porque realmente lo es, o porque los llevé a decir eso
Al leer el texto, parece que olvidó el dicho de que “todos los modelos están equivocados”
También es un error común entre quienes gustan de los RPG “realistas” de “simulación”
Si modelas algo de manera lo bastante exhaustiva, el modelo simplemente se vuelve la cosa misma
Para crear un modelo de un lugar que incluya todos los detalles del lugar real, necesitas un modelo a escala 1:1, y eso termina siendo una copia de ese lugar
Un prompt para un modelo con suficiente planificación como para reproducir de forma confiable el 100% de la funcionalidad de un sistema probablemente sea el propio código fuente de ese sistema
A menudo me he preguntado si gran parte de TI y la programación no consiste simplemente en unir piezas bien entendidas
Hace 8 años pensaba por qué no reemplazar LLVM con un sistema mucho más simple, y la optimización manual con un simple “optimizador” de IA
Me parecía que bastaba con entrenarlo para transformar código compilado simple en código “optimizado”, pero en ese momento el consenso era que los sistemas de IA tenían demasiada dificultad para producir código correcto con la confiabilidad suficiente como para ser utilizables
Si la IA ni siquiera puede reemplazar ese código de bajo nivel, entonces los problemas de alto nivel naturalmente deberían estar mucho más lejos
Sin embargo, la gente usa IA para problemas de alto nivel
Mi hipótesis es que gran parte de la ingeniería digital moderna es plug and play
Recuerdo que antes de 2023 en HN todos idolatraban la idea de que reducir la cantidad de líneas de código era el indicador senior más poderoso
Solo que la corriente es demasiado fuerte como para ganar una carrera nadando contra el torrente de líneas de código generado por los LLM
Y tampoco estoy de acuerdo con la premisa del artículo de que los LLM pueden escribir buen código
Escriben código que funciona, pero parece como si lo hubiera escrito un demogorgon, y da un poco de náusea verlo
Es malo, pero malo de una manera en la que un humano jamás escribiría
Es una incomodidad distinta a leer código espagueti escrito por un desarrollador junior; es más bien una repulsión como si en algún rincón del estómago estuviera eclosionando un huevo de Cthulhu
Recuerdo que en una empresa en la que trabajé, un senior prácticamente solo se dedicó a borrar código desde que entró hasta que se volvió manager
Este artículo no fue divertido de leer
Las frases en sí y cada párrafo por separado estaban bien, pero como conjunto era disperso y, me atrevería a decir, carente de sentido
Había muchísimas palabras, pero parecía que en realidad decía muy poco
Por ejemplo, no es exacto decir que en 2025 se invirtió la economía de la producción de código
Si antes el proceso de manufactura era estrictamente aditivo, como la impresión 3D, ahora se parece más a algo complementado con un enfoque sustractivo, como el fresado CNC
La “forma” requerida no ha cambiado mucho, y si te importan ciertas tolerancias, tampoco ha cambiado el esfuerzo humano
Todavía hay que valorar, reutilizar, cuidar y curar el producto tanto como lo exige el mercado
Tampoco estoy de acuerdo con la frase “las líneas de código no son un entregable ideal para revisar”
¿Qué significa “ideal” aquí?
Cuando era niño, en todos los exámenes la regla era “muestra tu procedimiento”
La razón es que no se busca solo el producto que va a salir mañana, sino mejorar los modelos mentales y los procesos de pensamiento de la siguiente generación
El lenguaje era realmente difícil de seguir y tampoco resaltaba el punto central del texto
Este tipo de artículos me hace dudar más de la idea de que los empleos de ingeniería de software van a desaparecer
El trabajo de un ingeniero de software en 2026 ya es distinto al de 2020, y ni hablar del de 1990, así que ¿por qué debería creer en la falsa dicotomía de que el trabajo de 2026 o se mantendrá igual o desaparecerá por completo?
Hace mucho tiempo, cuando trabajaba en Google, me resultó novedosa la idea de revisar todo el código
Antes de eso, en MS, el código se grababa en CDs y terminaba en cajas, así que en su mayor parte no se revisaba hasta ese momento riesgoso cerca del final del proyecto
Entre 2000 y 2004 cambió drásticamente la forma en que los ingenieros de software usaban su tiempo, y creo que mejoró porque aumentó la comprensión compartida y fomentó la colaboración
Si la IA escribe código y los humanos dedican más tiempo a revisarlo, eso no necesariamente sería algo malo
Pero si el código de IA llega a ser lo bastante bueno, se empezará a considerar opcional hacer una revisión exhaustiva
Entonces el trabajo del ingeniero de software será muy distinto al de antes, y ya no se escribirá tanto código ni se dedicará tanto tiempo a revisarlo
Los IDE podrían desaparecer como el dodo
El enfoque podría desplazarse a definir objetivos y pruebas para evitar que el equipo de programación con IA se desvíe de la tarea
Los ingenieros de software que entiendan bien hacia dónde va el proyecto también podrían dedicar más tiempo a la arquitectura, porque no querrán que la IA reescriba cosas una y otra vez cuando el destino esperado cambie de forma razonable
También podría dedicarse más tiempo a la exploración: construirlo de una forma, luego de otra, luego de otra más, comparar y generar nuevas ideas a partir de enfoques distintos
No pretendo tener mejores predicciones que nadie, pero sí me opongo con fuerza a la idea de que el rol va a desaparecer, y estoy a favor de que evolucione, como ya ha ocurrido muchas veces. Aunque quizá nunca tan rápido como ahora
No creo que sea correcto decir que “tratábamos el código como algo permanente porque el trabajo de producir código era el cuello de botella”
Tratábamos el código como algo permanente porque lo veíamos como la fuente de verdad
La computadora no ejecuta documentos; ejecuta código
Si un documento de requisitos contradice al código, por defecto se asumía que el documento de requisitos estaba equivocado
No se puede separar el código de la especificación. El código es la especificación.