Por qué escribir código en 2026

• El rol del ingeniero de software se ha expandido más allá de producir código, hacia construir y mantener una fábrica de software, pero para entender y mejorar los sistemas sigue siendo necesario trabajar directamente con el código
• Si se guía a los agentes con prompts, AGENTS.md y bases de conocimiento, y se protege el resultado con pruebas, linting, sistemas de tipos y evaluaciones, incluso modelos de bajo rendimiento pueden producir cambios bastante útiles
• Programar directamente permite pensar en el entorno de ejecución sin pasar por el inglés, lo que hace más evidente la presencia de vulnerabilidades, pruebas débiles y excepciones innecesarias que pueden pasar desapercibidas en una revisión pasiva de código
• Los agentes se parecen más a un becario recién incorporado que a un compilador: siguen de forma conservadora el código existente y requisitos imprecisos, y pueden amplificar errores puntuales de humanos con wrappers y capas indirectas
• Para mantener el sentido de propiedad y el criterio, los humanos deben probar directamente los enfoques y establecer patrones que luego los agentes puedan repetir, aprovechando así la productividad de la automatización

---

La fábrica de software donde trabajan los agentes

• Los ingenieros de software no solo mantienen el software, sino también una línea de ensamblaje que permite que cualquiera solicite cambios mediante prompts y los despliegue de inmediato
  • Preparan de antemano la infraestructura para que los agentes tengan éxito mediante prompts, skills, AGENTS.md y bases de conocimiento
  • Protegen el resultado después con pruebas, linting, sistemas de tipos, evaluaciones y evaluación automatizada con ayuda de otras IA
• Si se proporcionan suficientes restricciones y contexto actualizado, incluso modelos menos inteligentes pueden producir cambios útiles sin desviarse del camino, y puede parecer que las personas ya no necesitan leer ni escribir código directamente
• Sin embargo, incluso si existieran agentes con inteligencia al nivel de Fable, programar directamente sigue permitiendo pensar directamente en el entorno de ejecución sin una capa intermedia como el inglés
• Leer pasivamente diffs y parches generados por agentes no basta para conectar en profundidad con la arquitectura del sistema
  • Trabajar directamente con el código permite sentir de forma concreta qué se rompe al agregar funcionalidad encima
  • Si se ordena el código y se documentan principios arquitectónicos consistentes que no acumulen excepciones, la fábrica de software también funciona de forma más estable
  • Si durante la depuración se identifican y corrigen debilidades en la estrategia de pruebas, se puede bloquear toda una nueva clase de errores
• Programar directamente no es la única forma de entender el software, ni hace falta insistir en un trabajo manual extremo como en la aguja magnetizada y la mano firme
  • Aunque la mayor parte del código real sea generada por IA, programar directamente sigue siendo una herramienta útil

Preservar la capacidad de pensar y el sentido de propiedad programando directamente

• Si uno se queda en el papel de centauro inverso, limitado a leer y aprobar código, disminuyen la concentración y el sentido de propiedad, el código de baja calidad pasa más fácilmente las revisiones y también se vuelve más difícil hacer ajustes finos
  • Si no se presta atención a los detalles, se acumulan vulnerabilidades y, a largo plazo, el código de baja calidad también perjudica a los agentes
  • Si los humanos prueban directamente los enfoques y luego los agentes repiten los patrones ya establecidos, es posible seguir involucrados y apropiarse del resultado
• El inglés es un lenguaje con especificación insuficiente para representar cálculos con precisión
  • En tareas algorítmicas es necesario concebir y pensar en pasos ejecutables
  • Según el caso, se puede ajustar la precisión necesaria eligiendo un lenguaje de bajo nivel con un espacio de diseño amplio o un lenguaje de alto nivel con un entorno computacional más restringido
• Tratar a los agentes de programación como si fueran compiladores puede llevar a la actitud de que está bien desplegar código mal escrito
  • Los agentes se parecen más a un becario recién incorporado que a un compilador
  • Leen código existente, que puede ser incompleto y de baja calidad, y generan nuevos cambios a partir de descripciones imprecisas de los cambios deseados
  • Como los humanos no pueden transferir sin más su forma de pensar y sus preferencias a un grupo de becarios, no deben quedarse como simples consumidores, sino involucrarse directamente
• A los agentes les cuesta seguir por iniciativa propia la regla de los Boy Scouts de dejar el código en mejor estado de como lo encontraron, y también resulta incómodo delegarles eso
  • Tienden a inclinarse por hacer el cambio actual lo más seguro posible, preservando de forma conservadora decisiones previas
  • En una base de código, un humano usó sin pensarlo almacenamiento local del navegador para parte del estado, mientras el resto se guardaba en una base de datos backend; el agente intentó mantener esa decisión agregando wrappers y capas indirectas, y el número de líneas de código creció aproximadamente 3 veces
  • Esa clase de conservadurismo puede amplificar decisiones erróneas y puntuales tomadas por humanos
• El proceso de borrar código directamente y explorar ayuda a llegar a una mejor arquitectura que limitarse a dar instrucciones solo en inglés
  • Cuanta más atención se presta al código, más se fortalecen la capacidad de pensar, la sensibilidad de autor y la habilidad para dirigir la fábrica de software
• En una fábrica de software importan los detalles, desde los patrones de arquitectura hasta los algoritmos y el rendimiento
  • Los agentes han aumentado la necesidad de evaluaciones, mediciones y mecanismos de protección, y han impulsado incluso en proyectos personales la incorporación temprana de CI en lugar de dejarla para después
  • Gracias a eso, el estado del desarrollo de software ha mejorado considerablemente, pero toda línea de ensamblaje sigue teniendo debilidades
• Incluso en una fábrica de automóviles hay momentos en que hace falta desmontar la línea de ensamblaje, profundizar en los detalles de un motor de combustión interna para mejorarlo un 10%, o pasar todo el día observando pruebas de pastillas de freno para entender por qué no se detectó antes un problema en planta
  • También en el software, para conectar los detalles con la estructura general, no se deben trazar límites arbitrarios sobre lo que uno puede tocar directamente

[jimmy2056]

El momento en que escribo código es cuando surge algún problema.
Incluso entonces, en vez de hacerlo yo mismo directamente,
modifico el harness para que ese tipo de problema no vuelva a ocurrir en el futuro,
así que cada vez tengo menos ocasiones de escribir código.

[shakespeares]

Me identifico con el proceso de pensamiento y el sentido de pertenencia...

[choijaekyu]

Porque no hay tokens, qué triste.

[GN⁺]

Comentarios en Hacker News

• Parece evidente que si no puedes escribir código, tampoco puedes revisarlo, pero hay personas y empresas que dicen que basta con que Claude lo escriba y Codex lo revise. Aun así, la razón por la que piden el resultado en lenguajes de alto nivel como Python o Java, y no en ensamblador o binarios compilados, es al final porque los humanos tienen que poder leer el código
  Esperar que los desarrolladores lean, depuren y razonen sobre el código, mientras al mismo tiempo no se les quiere dar entrenamiento para desarrollar esa habilidad, es una contradicción

  • La razón por la que no se le pide a Claude que escriba ensamblador es que casi no hay material de entrenamiento para crear apps CRUD en ensamblador. No gusta la idea de que los LLM desplacen empleos, pero también es cierto que los modelos de punta hacen bien tareas repetidas y ampliamente documentadas en internet, y que durante las últimas décadas una parte considerable del desarrollo de software ha sido producción estandarizada de apps CRUD
    Queda la duda de si la industria puede seguir avanzando si se delega toda la creación a los LLM
  • Escribir código es también pensar, así que si se deja de escribir código, también se deja de pensar. Incluso si se dice que el pensamiento ocurre a un nivel más alto, ese mismo diseño de alto nivel también terminará siendo algo que el LLM haga mejor, así que la ventaja actual sería solo temporal
  • Al final parece ser una diferencia en la forma de cognición. Para algunas personas, el código es más preciso y más fácil de leer que una explicación en inglés, y un desarrollador experimentado puede entender su funcionamiento con solo repasarlo; para otras, leer código es difícil y el lenguaje natural les resulta más cómodo
    No significa que una opción sea mejor que la otra; quizá quienes se fijan menos en los detalles terminen guiando al mundo, o quizá cada problema requiera un nivel distinto de precisión
  • Casey Muratori y Demetri Spanos parecen haber tratado esto en un video: la razón para evitar binarios tiene menos que ver con confiar en los LLM y más con las diferencias de lenguaje máquina y offsets entre máquinas, además de la dificultad de interpretar el contexto. Igual que hay una diferencia entre entender código C descompilado por Ghidra y código fuente C escrito por un desarrollador, los lenguajes de alto nivel pueden expresar la intención del código
    El compilador ayuda a que el LLM escriba código que realmente pueda compilarse y ejecutarse, pero si emitiera lenguaje máquina directamente, es muy probable que ni siquiera corra. Claro, si no puedes escribir código en absoluto, revisarlo se vuelve mucho más difícil
  • También hay quienes de verdad sostienen que Claude debería emitir ensamblador o binarios directamente. Aun así, es probable que tenga menos portabilidad que un lenguaje de alto nivel que puede compilarse a ensamblador para varias máquinas

• “¿Cómo llama la industria a una especificación de proyecto lo bastante completa y precisa como para generar un programa? Código” — CommitStrip
  Si está bien escrito, lo esencial del código debería ser expresar de la forma más simple la lógica de negocio subyacente. Puede que no sea necesario revisar todas las capas de soporte, pero si no se leyó el código, es difícil decir que realmente se entiende por completo la lógica de negocio

  • Enlace original
  • En otro texto sobre este tema también se recomendaba usar código en lugar de especificaciones. También sirve darle al agente instrucciones en forma de código o ejemplos que deba seguir
    https://softwaredoug.com/blog/2026/07/04/write-code-not-specs
  • Por eso hace falta Lisp. Primero se crea un lenguaje de programación cuyos elementos básicos sean también los elementos básicos de la lógica de negocio, y luego se escribe en ese nuevo lenguaje un programa sencillo que describa lo que hace el negocio

• La pregunta importante es quién va a pagar por escribir código manualmente. Los clientes no pagan por el acto de escribir o generar código en sí, sino por resolver problemas, así que el negocio se lo queda quien lo resuelva con menos costo y menos fricción, y es difícil ignorar la ventaja de que las herramientas de IA compriman los tiempos
  Llevo en esta industria desde los años 90, pero siempre ha habido muchos desarrolladores no tan buenos produciendo resultados mediocres. Se romantiza demasiado el código hecho a mano, pero en la práctica las bases de código tendían a volverse difíciles de mantener con el tiempo y llenas de bugs, y los proyectos mal ejecutados no son nada nuevo

  • Más bien creo que escribir uno mismo una menor cantidad de código aumenta la productividad. Si dedicas un día a reestructurar manualmente la arquitectura, puedes ahorrarte miles de dólares en tokens y varias semanas de dolores de cabeza
    Ahora mismo parece que quieren construir una fábrica de software con las dos manos atadas
  • Los desarrolladores mediocres ahora están produciendo 10 veces más resultados mediocres
  • En industrias como salud, aviación y energía nuclear, donde la calidad del software importa y está regulada, espero que se siga pagando por escribir código manualmente. Pero es un mercado relativamente pequeño

• Para concentrarse y entender, no basta con mirar al agente desde lejos y leer código de forma pasiva; hay que experimentar el código directamente. En el fondo, eso significa entrenar tu propio modelo mental
  Al programar, el subconsciente emite muchos juicios como “esto se siente correcto”, y eso solo se desarrolla con repetición y concentración profunda; solo revisar código o leer documentación tiene límites. Cuando ese modelo mental ya existe, basta ver un mensaje de error en producción para señalar de inmediato la causa, pero con código generado uno puede tardar mucho más, recurriendo a un razonamiento consciente y lento
  Para que un LLM sea realmente útil, habría que poder asumir que se encarga de todo el mantenimiento del código y funciona como una biblioteca externa; de lo contrario, los problemas seguirán apareciendo inevitablemente

  • Ya se intentó una separación similar entre humanos, y funcionó tan mal que hasta surgió el término despectivo arquitecto de torre de marfil. En sistemas reales aparecen diseños teóricos imposibles de implementar, el equipo de implementación o el LLM terminan rodeando la arquitectura, y mientras arquitectos e implementadores discuten sin alinearse, la velocidad de desarrollo cae mucho
  • En observabilidad, se diría que si cuesta encontrar la causa solo con el comportamiento dinámico en ejecución, entonces hay que hacer el sistema más transparente y más observable. Como las personas pueden moverse o irse, nunca fue buena idea depender del modelo mental de individuos excepcionales
    Aún no sé cuál postura es la correcta y sigo investigándolo

• Incluso en 2026, el código generado por IA sigue siendo bastante malo. Ya sea con Fable o con un harness personalizado de Pi/opencode LeetCode, los resultados son terribles, y si no puedes distinguir la diferencia de calidad entre tu código y el de la IA, eso son malas noticias

  • Mi código era peor que el de la IA, o quizá todavía lo es, pero al menos me pagan, así que esas malas noticias no importan mucho

• En el perfil de ejecución ya dejé explicitado en las reglas que el agente debe seguir la regla del boy scout, revisar la cobertura de código, hacer una revisión crítica y redactar reportes y tareas de seguimiento. Los LLM de punta de hoy siguen este tipo de reglas mucho mejor que el 90% de las personas con las que he trabajado, y me pregunto si eso realmente significa algo malo

  • El agente hoy tiende a inclinarse por hacer que el cambio actual sea lo más seguro posible. Una vez, antes incluso de tomar café, le dije sin pensar que usara el almacenamiento local del navegador, y como el resto del estado estaba en la base de datos del backend, agregó wrappers y capas de indirección para preservar esa mala decisión, casi triplicando la cantidad de líneas de código
    El agente es conservador, así que puede amplificar errores humanos puntuales. Hay muchas formas de resolver esto y cada persona piensa distinto, así que tanto un enfoque de no leer el código como uno de leerlo y escribirlo directamente son posibles, pero también hay una gran ventaja en la precisión del código cuando no pasa por un LLM

• La razón por la que necesito escribir código yo mismo es que, si no lo hago, el LLM termina creando demasiado código. Hay que entender el problema por completo y generalizarlo para evitar que a un “Hello World” le terminen colgando 10 mil líneas y 5 capas de abstracción
  Como los LLM son predictores de tokens, cuanto más problemas haya que resolver, más tienden a aumentar los tokens de código que generan

  • A los LLM les gusta envolver el código de forma defensiva en vez de pensar el conjunto de manera integral, así que se inflan con facilidad. En cambio, los desarrolladores humanos pueden seguir la regla del boy scout de ir ordenando también el código de alrededor mientras trabajan
  • Peter Naur explicó hace décadas que programar no es producir mecánicamente código fuente, especificaciones o documentación, sino una actividad humana de construir una teoría mental profunda sobre cómo encaja cada parte del sistema con el problema del mundo real. El verdadero producto de la programación es el modelo mental compartido por quienes desarrollan
    Como quienes tienen el problema a resolver son humanos, si no se entiende el problema puede aparecer el problema X/Y, donde el LLM termina resolviendo algo que no tiene relación con la necesidad real. El LLM abstrae mejor elementos no centrales, como bibliotecas o lenguajes de alto nivel, pero el núcleo del problema sigue teniendo que expresarse formalmente
    Incluso el vibe coding, donde se van agregando restricciones una por una hasta llegar al resultado deseado, al final sigue siendo una forma laxa e informal de programación. Es mejor dejarle al LLM la periferia del problema y escribir y entender uno mismo la parte central
  • El 99% de mi trabajo es en C#, pero gracias al LLM ahora puedo autoproclamarme el programador de bajo nivel que siempre quise ser sin hacer nada
  • Le pedí que armara un proyecto para correr en K8s, similar a otros módulos de la empresa, y el LLM terminó escribiendo hasta pruebas unitarias para la implementación de Hello World
  • Le encargué a un modelo estadounidense reciente una tarea trivial para mostrar información del lado del cliente, y terminó modificando ambos lados del código para que el servidor enviara la información al cliente en el handshake inicial, y de hecho funcionó. Pero esa información ya estaba en el cliente, así que era una tarea que se resolvía cambiando una sola línea del código del cliente
    En apariencia resolvió perfectamente lo pedido, pero era código innecesario y desprolijo. Las empresas que venden tokens por consumo tienen un incentivo económico para crear soluciones tipo Rube Goldberg que medio resuelven el problema mientras consumen la mayor cantidad posible de tokens, y se termina usando más tokens no solo al generar, sino también más adelante al tener que lidiar con un código enorme al que además se le mezclaron bugs nuevos
    Es gracioso ver a gente que se burlaba del código copiado y pegado y ahora se entusiasma con código pegado de manera desprolija

• Viendo el avance desde ChatGPT 3.5 en noviembre de 2022 hasta ahora, me pregunto si dentro de 4 años seguiré revisando código. Aun sin ser un extremista de la IA, si se mantiene la velocidad actual, es muy posible que en 5 a 10 años desaparezcan la ingeniería de software y el desarrollo tal como existen hoy
  A los humanos quizá solo les quede algo como el diseño de UI, y todo lo demás podría quedar abstraído para que la IA haga el trabajo real

  • Si fuera una máquina que cumple deseos de una vez, una petición única sería fácil de resolver, pero el software es la acumulación de miles de deseos, y en cada rincón hay que tomar decisiones finas sobre querer esto y no querer aquello. En el enfoque actual de los LLM, todas esas decisiones todavía las tiene que gestionar un humano, pero en el futuro podría aparecer una forma que hoy ni imaginamos
  • Se asume que el progreso seguirá al mismo ritmo, pero da la impresión de que ya entramos en una cierta meseta. Los costos crecen exponencialmente cada vez que los modelos se hacen más grandes, y creo que ya quedó bastante claro que el negocio de entrenar modelos cada vez más grandes no es rentable
  • Ya me desagrada un futuro donde ni siquiera podremos culpar directamente a humanos incompetentes por haber hecho sitios web en los que todo requiere JavaScript y ni siquiera se puede escribir bien en un campo de texto. Si, por culpa de gerencias que priorizan la apariencia sobre la funcionalidad y de datos de entrenamiento llenos de sitios así, el LLM empieza a producir esa misma basura a una escala muchísimo mayor, siento que vendrá una crisis existencial
    La web ya está lo suficientemente arruinada, así que al menos me gustaría que, como ahora, pudiéramos seguir culpando a humanos incompetentes

• Sin importar la presión por KPI, sigo escribiendo código yo mismo cada vez que tengo la oportunidad, y de la IA solo espero algo como un autocompletado de código más inteligente

• Escribo código yo mismo porque amo programar y eso realmente me hace feliz. No hay razón para renunciar a algo que me gusta

  • Hay un encanto casi mágico en darle una tarea a una computadora y verla resolverla miles de millones de veces más rápido que cualquier otro medio
  • Entré a este campo porque disfruto diseñar programas y escribir código. Me quedé atrás en el uso de IA y todavía tengo que aprender más, pero programar con las manos es algo que no quiero dejar nunca
  • Si te hace feliz que además te paguen por programar, la empresa puede dejar de darte esa recompensa. Si dependes de ese ingreso para mantener tu visa, es muy probable que te veas obligado a adaptarte al cambio y termines dejando de programar