Cambios en el flujo de trabajo de programación
- En noviembre de 2024 era 80% manual + autocompletado y 20% programación con agentes, pero en diciembre esa proporción se invirtió a 80% programación con agentes y 20% correcciones/retouches
- En la práctica, se ha convertido en una situación de programar en inglés, dando instrucciones en palabras al LLM sobre qué código escribir
- Hay una parte que hiere el orgullo, pero el poder de manejar software en grandes unidades de "acciones de código" es demasiado útil
- Adaptarse a esto, configurarlo, aprender a usarlo y entender qué puede y qué no puede hacer lo vuelve aún más efectivo
- Es el mayor cambio fundamental en el flujo de trabajo de programación en unos 20 años de experiencia programando, y ocurrió en apenas unas semanas
- Probablemente algo similar ya le esté pasando a una proporción considerable de ingenieros (porcentajes de dos dígitos), aunque estima que la percepción del público general sigue en porcentajes bajos de un solo dígito
IDE / enjambre de agentes / posibilidad de errores
- Cree que, por ahora, el hype de "ya no se necesita un IDE" o del "enjambre de agentes" está exagerado
- Los modelos siguen cometiendo errores y, si hay código realmente importante, hay que vigilarlo con ojos de halcón y tener un IDE grande abierto al lado
- La naturaleza de los errores ha cambiado: ya no son simples errores de sintaxis, sino errores conceptuales sutiles como los que cometería un desarrollador junior algo descuidado y apresurado
- El tipo de error más común: hacer suposiciones equivocadas en lugar del usuario y seguir adelante sin confirmarlas
- Problemas adicionales:
- No maneja bien la confusión
- No pide aclaraciones
- No expone inconsistencias
- No presenta trade-offs
- No contradice cuando debería hacerlo
- Sigue teniendo cierta tendencia a ser complaciente (sycophantic)
- En modo plan mejora, pero hace falta un modo plan ligero e inline
- También tiende a sobrecomplicar el código y las API, inflar las abstracciones y no limpiar el código muerto después de terminar
- A veces implementa una estructura ineficiente, inflada y frágil a lo largo de 1000 líneas, pero si se le pregunta "¿no se podría hacer así?", responde "¡claro!" y de inmediato lo reduce a 100 líneas
- Todavía ocurre que cambia/elimina comentarios y código que no le gustan o que no entiende lo suficiente, aunque no tengan relación con la tarea
- Estos problemas siguen apareciendo incluso intentando corregirlos de forma simple poniendo instrucciones en CLAUDE.md
- A pesar de todo esto, sigue siendo una mejora gigantesca en términos absolutos, y es muy difícil volver a la programación manual
- Flujo de trabajo actual: a la izquierda, unas pocas sesiones de Claude Code en ventanas/pestañas de ghostty; a la derecha, el IDE para revisar el código y editar manualmente
Tenacidad
- Es muy interesante ver a un agente aferrarse a algo sin descanso
- No se cansa ni se desanima, y sigue intentando incluso en situaciones donde un humano ya se habría rendido hace mucho y lo dejaría para después
- Verlo luchar con algo durante mucho tiempo y que al final lo logre 30 minutos después se siente como un momento de "sentir AGI"
- Esto hace notar que la resistencia es un cuello de botella clave del trabajo, y con un LLM en la mano eso aumenta de forma drástica
Aumento de velocidad
- No está claro cómo medir la "aceleración" de lo asistido por LLM
- Sin duda siente que lo que iba a hacer se volvió mucho más rápido, pero el efecto principal es terminar haciendo mucho más de lo que pensaba hacer:
- Se vuelve posible programar toda clase de cosas que antes no valía la pena programar
- Se puede acceder a código sobre el que antes no se podía trabajar por falta de conocimiento/habilidad
- Es una aceleración, pero una parte aún mayor podría ser una expansión
Palanca
- Los LLM son excelentes para iterar en bucle hasta cumplir un objetivo específico, y ahí está gran parte de la magia de "sentir AGI"
- No decirles qué hacer paso a paso, sino darles criterios de éxito y observar
- Hacer que escriban primero las pruebas y luego que las pasen
- Meterlos en el loop con Browser MCP
- Hacer que primero escriban un algoritmo ingenuo que probablemente tenga una precisión muy alta, y luego pedir optimización manteniendo esa precisión
- Si se cambia el enfoque de imperativo a declarativo, el agente puede iterar más tiempo y ganar más palanca
Diversión
- La parte inesperada es que programar con agentes se vuelve más divertido
- Se elimina el trabajo aburrido de llenar huecos y queda solo la parte creativa
- Hay menos bloqueos/atascos (ese estado nada divertido) y se siente más valentía, porque siempre hay una forma de avanzar positivamente en conjunto
- También hay gente que siente lo contrario: la programación con LLM va a dividir a los ingenieros entre quienes aman programar en sí y quienes aman construir cosas
Atrofia
- Nota que la capacidad de escribir código manualmente empezó a atrofiarse poco a poco
- Generar (escribir código) y discriminar (leer código) son habilidades distintas en el cerebro
- Debido a los pequeños detalles sintácticos involucrados en programar, uno puede tener dificultades para escribir, pero aun así revisar código sin problema
Slopacolypse
- Espera que 2026 sea el año de la Slopacolypse (la avalancha de contenido de baja calidad generado por IA) en GitHub, Substack, arXiv, X/Instagram y, en general, en todos los medios digitales
- Además de mejoras reales, aparecerá todavía mucho más teatro de productividad inflado por el hype de la IA (¿si es que eso todavía es posible?)
Preguntas
- ¿Qué está pasando con el "ingeniero 10X"? — ¿la relación de productividad entre el promedio y los mejores ingenieros? Es posible que esa brecha aumente mucho
- Armados con LLM, ¿los generalistas terminarán superando cada vez más a los especialistas? Los LLM son mucho mejores llenando huecos (micro) que en la gran estrategia (macro)
- ¿Cómo se sentirá la programación con LLM en el futuro? ¿Será como jugar StarCraft? ¿O como jugar Factorio, o tocar música?
- ¿Qué proporción de la sociedad está realmente bloqueada por trabajo digital de conocimiento?
TLDR
- Las capacidades de agentes LLM como Claude y Codex cruzaron hacia diciembre de 2025 algún tipo de umbral de consistencia, provocando un cambio de fase en la ingeniería de software y áreas relacionadas
- Da la sensación de que la parte de inteligencia de pronto va bastante por delante de todo lo demás: integración (herramientas, conocimiento), necesidad de nuevos flujos de trabajo organizacionales, procesos y una difusión más general
- 2026 será un año de alta energía mientras la industria asimila estas nuevas capacidades
15 comentarios
Parece que también se publicó una versión de skills para mejorar el funcionamiento de Claude Code con base en el contenido de este artículo.
Karpathy-Inspired Claude Code Guidelines : https://github.com/forrestchang/andrej-karpathy-skills
Sigo teniendo esa duda, pero para quienes ya tienen internalizado programar a mano está bien supervisar a los LLM; en cambio, para quienes están aprendiendo recién, si solo se quedan viendo el código que genera el LLM, me parece que será difícil saber si eso está bien o no.
Me pregunto si la gente que antes programaba en ensamblador, cuando aparecieron los compiladores, habrá pensado algo como: ¿cómo voy a confiar en un compilador que escupe una salida en ensamblador toda chueca?
En ese entonces, incluso programando en C, seguramente codificaban guiando las cosas para que la salida en ensamblador saliera como querían.
También me da curiosidad si, cuando la era de la IA avance más, se podrá obtener un resultado final bien hecho en lenguaje natural sin supervisión humana.
Creo que incluso en la época en que la gente programaba código, si no estudiabas, tampoco sabías qué estaba mal jajaja
Los expertos en ensamblador todavía se quejan de los compiladores. Al final, lo importante es que en situaciones donde se necesita una optimización extrema, siguen haciendo falta ese tipo de especialistas; y si lo aplicamos a la IA, incluso aunque la IA siga avanzando, quizá le cueste superar a quienes programan extremadamente bien al más alto nivel. En términos generales, sin embargo, ya no hay ningún humano que pueda vencer a la IA. También estaría divertido ver otro momento tipo AlphaGo con una competencia de AlphaCode.
Si existe el esfuerzo de analizar y entender el código que genera, creo que puede estar bien.
Los compiladores son un concepto un poco distinto: como generan ensamblador de forma basada en reglas, están en un dominio determinista, así que una vez que se revisa, el mismo problema no suele volver a aparecer; en cambio, los LLM están en un dominio probabilístico, por lo que siempre existe la posibilidad de que el problema se repita.
Tal vez, si esta precisión probabilística sigue mejorando, pueda acercarse al 100%, pero si los propios requerimientos en lenguaje natural son imprecisos, al final el resultado también será impreciso, así que me da la impresión de que una versión
buenadel resultado sigue dependiendo de la persona.A mí también me preocupan quienes conocieron los LLM desde que eran estudiantes. También me da la impresión de que el mercado de contratación para perfiles junior se ha puesto un poco peor, aunque también es difícil demostrarlo...
En lo personal, siento que si solo tienes conocimientos de CS, no hay tanta diferencia.
O quizá sea porque la forma en que lo uso ahora se siente como hacer programación en pareja con un amigo que tiene las manos rapidísimas y te escribe todo el código...
Al final, cuando desarrollas a fondo, inevitablemente llega un momento en que necesitas conocer lo que hay dentro de la capa de abstracción.
La brecha entre el prompt en lenguaje natural y el código generado es demasiado grande, así que parece difícil pasar desde el prompt hacia el interior de la capa de abstracción del LLM.
Ahora mismo, lo que hacemos es transmitir al LLM mediante prompts el concepto de la especificación que teníamos en la cabeza, y luego volver a leer el código escrito para validarlo.
Como eso se parece más a revisar código escrito por otra persona, no da la sensación de estar entrando dentro de la abstracción.
Creo que estaba descuidando demasiado ese 20%
Últimamente me topé con un bug que la IA no pudo resolver... no es omnipotente, pero me di cuenta de que la estaba tratando como si lo fuera.
Ah... jajaja
Coincido mucho. En un proyecto reciente hice commit de unas 100 mil líneas (la cantidad real de código es mayor) y en promedio estoy usando 2 o 3 agentes. Diría que alrededor del 95% lo escriben los agentes.
Pero aun así, sigue siendo necesario gestionar las pruebas y el código muerto, y hacen falta detalles sobre los casos de prueba y las condiciones de éxito de las pruebas. Es importante gestionar qué se debe hacer y hasta dónde. Para lograrlo, no solo hay que actualizar continuamente la arquitectura que crea el harness y la configuración de
Rules, sino también el plan.Opiniones en Hacker News
Es interesante ver cómo los agentes siguen intentando sin cansarse
Las GPU y NPU trabajan al rojo vivo, y les estamos entregando incluso datos que normalmente no compartiríamos
Ahora parece un intercambio conveniente, pero a largo plazo existe el riesgo de que crezcan la dependencia y los problemas sociales
Al final, esto podría convertirse en una estructura subordinada a estos enormes gatekeepers
Trabajando con IA, el problema más grande que la atrofia mental parece ser convertirse en autocomplacencia y apatía
Al principio la rapidez de los resultados da un subidón de dopamina, pero mientras más se repite, más se siente que la IA arrastra el proyecto hacia donde quiere
Al final desaparecen los experimentos creativos que yo quería hacer y uno termina absorbido por la gravedad del espacio latente de la IA
Es como el doomscrolling: un loop adictivo en el que siempre quieres ver la siguiente salida
Estoy haciendo un juego multijugador con Rust y Bevy, y aunque el código funciona, termina siendo código que yo no entiendo
Antes no habría llegado hasta aquí sin entender por completo las herramientas, pero ahora hice un juego medio funcional sin siquiera saber qué es ECS
Pensando en mantenimiento o respuesta a incidentes, esto sí es una situación peligrosa
Ahora nos concentramos en aprender el modelo y estamos olvidando cómo pensar por nosotros mismos
Como la forma de usar LLM cambia todo el tiempo, al final es como estar en una cinta de correr eterna de aprendizaje
Aunque pases mucho tiempo sin hacerlo, la sensación queda y cuando vuelves la recuperas rápido
Cada vez hay más desarrolladores que, si el LLM no sabe algo, simplemente se rinden y no quieren leer la documentación
Incluso si lees la documentación tú mismo y les muestras capturas de pantalla, dudan diciendo “¿seguro que esto está bien?”
Por una gratificación breve sigues lanzando prompts y esperando “a ver qué sale esta vez”
La programación con LLM está sirviendo para separar a la ‘gente a la que le gusta programar’ de la ‘gente a la que le gusta construir’
A mí me gusta hacer cosas y obtener resultados, soy más del tipo builder, así que este cambio me entusiasma
En cambio, quienes disfrutan programar por sí mismo se sienten incómodos con esta tendencia
El atractivo de programar estaba en el proceso de estructurar problemas y ejecutarlos uno mismo
Ahora siento que “no estoy programando yo, sino dando órdenes”, y eso me quita interés
Antes también existían choques como compilado vs interpretado, tipado vs no tipado, despliegue rápido vs mantenibilidad
Al final, el software exitoso pasa por un proceso que va de una fase inicial caótica a una etapa de escalado estable
Todavía no estoy seguro de si la IA ayuda en ese proceso o si más bien lo vuelve más complejo
No se trata solo del resultado final, sino de disfrutar el proceso de definir la estructura del sistema
Un compañero humano de equipo sí tiene responsabilidad y confianza; un LLM no
Me parece interesante la idea de que la IA pueda traer una mejora de productividad de 10x
DevOps cambió la forma de colaborar entre desarrollo y operaciones para crear equipos de alto rendimiento, y eso produjo un efecto parecido a una versión de equipo del 10X
Para usar bien la programación con IA, igual que con DevOps, hace falta un proceso de mejora continua, cambios en el flujo de trabajo y construir confianza mediante automatización y verificación
Así como DevOps no se expandió ampliamente porque exigía aprender conceptos nuevos y cambiar la cultura del equipo, la programación con IA también puede adaptarse lentamente aunque tenga potencial 10X si no hay aprendizaje y cambio cultural
Para asentarse, hace falta formación y un cambio en la cultura de ingeniería
Sentí que los LLM son inútiles en codebases grandes
Sobre todo en código complejo y con muchas interacciones, casi no ayudan
Meterlos en un codebase existente, grande y complejo, es riesgoso salvo que sean cambios limitados con revisión minuciosa
En estructuras simples impresiona darles una lista de archivos al agente y dejarle la implementación, pero a medida que sube la complejidad el prompt tiene que bajar cada vez más a instrucciones detalladas para que siga habiendo resultados
A diferencia de los modelos anteriores, ahora sí da ayuda real incluso en monorepos complejos
Conviene comparar si, con la misma información, rinde mejor que un miembro nuevo del equipo
Los codebases internos comerciales se van ensuciando por desarrollo iterativo adaptado a pedidos de clientes, las suposiciones iniciales dejan de coincidir gradualmente con los requisitos y aparece la deuda técnica
Si usas LLM para refactors como separar helpers, modularizar o renombrar y ordenar el proyecto según los requisitos actuales, después el comportamiento del agente se vuelve más predecible
Hay que organizar requisitos, criterios de aceptación e historias de usuario en markdown, hacer que escriba el plan con detalle y luego pasar a la implementación en un flujo por etapas
Impresiona el punto en que la persistencia y resistencia de la IA superan los límites humanos
Incluso en investigación se dice que la tenacidad (grit) está más ligada al éxito que la inteligencia
Un LLM tiene persistencia infinita mientras el presupuesto lo permita
En los últimos meses siento que el rendimiento de la IA más bien ha retrocedido
Se olvida de las reglas y genera planificación excesiva y código sobrediseñado
Aun así, en frontend (HTML + Tailwind) sigue siendo útil
Siento que las expectativas excesivas sobre los IDE o los enjambres de agentes son prematuras
Haciendo una app para iPhone, me impresionó la capacidad de Claude para generar código a partir de prompts en inglés
> La programación con LLM termina dividiendo a los ingenieros entre quienes disfrutan programar en sí y quienes disfrutan crear cosas
Yo también, al juntar lo que escucho a mi alrededor, siento que al final se termina dividiendo así.