La codificación agentic es una trampa

• La codificación agentic es una forma de trabajo en la que una persona crea los requisitos y el plan, y varios agentes de programación hacen la implementación, pero su propia estructura sigue aumentando la distancia entre el código que se genera y se hace commit y la persona
• Para que este enfoque funcione, un desarrollador experimentado debe revisarlo de forma crítica a nivel de arquitectura, pero el uso excesivo de la IA puede generar deuda cognitiva (cognitive debt), debilitando las habilidades necesarias para hacerlo
• Como plantea la paradoja de la supervisión en la investigación de Anthropic, para usar Claude de forma efectiva hace falta capacidad de programación para supervisarlo, y usar agentes de código puede debilitar precisamente esa capacidad
• Los LLM tienden a usarse para aumentar la cantidad de código generado en cierto tiempo, en lugar de priorizar la comprensión profunda y la concisión, y pueden llenar requisitos ambiguos con supuestos o alucinaciones, produciendo más revisiones, correcciones y uso de tokens
• Las caídas de Claude y la variación en el costo de los tokens ponen en evidencia la dependencia del proveedor y la incertidumbre de costos; usar la IA como apoyo para planificación, documentación, investigación y delegación limitada, en vez de como orquestador que sustituye la implementación, puede reducir la deuda de comprensión

---

Trade-offs estructurales

• Los agentes de programación son útiles y poderosos, pero ya existen trade-offs que deben evaluarse en términos cuantitativos y prácticos
  • Mitigar la ambigüedad derivada de la no determinación de la IA aumenta la complejidad de los sistemas alrededor
  • Las habilidades de muchos desarrolladores pueden atrofiarse
  • Una falla de un proveedor específico, como una caída de Claude Code, puede paralizar a todo el equipo
  • El costo del personal es fijo, pero el costo de los tokens puede seguir cambiando y aumentando
• Para que este enfoque tenga éxito, un desarrollador experimentado debe pensar críticamente a nivel de arquitectura y ser capaz de detectar problemas en miles de líneas de código generado antes de que escalen
• Pero las herramientas de IA pueden afectar negativamente la capacidad de pensamiento crítico y la claridad cognitiva necesarias para ello, y la deuda cognitiva (cognitive debt) puede crecer

No es solo una nueva abstracción

• No basta con interpretarlo como “los programadores están subiendo a un nivel más alto de abstracción”
• Un aumento en la ambigüedad no significa automáticamente un nivel más alto de abstracción
• Cuando aparecieron FORTRAN, los compiladores y los lenguajes de alto nivel, también hubo reacciones preocupadas por bugs, inestabilidad, pérdida de eficiencia y más “magia”
• Pero la mayoría de esas preocupaciones del pasado eran temores normativos o teóricos sobre lo que se perdería al adoptar una nueva tecnología, mientras que las herramientas de IA ya están mostrando efectos reales pocos años después de su aparición
• El impacto no se limita a desarrolladores junior; también aparece en desarrolladores con más de 10 años de experiencia
• Los desarrolladores junior enfrentan una curva de aprendizaje más empinada al verse desplazados de manipular código directamente hacia revisar código generado
• El code review es importante, pero solo representa la mitad del proceso de aprendizaje; si desaparece la fricción de escribir y depurar código directamente, la capacidad de aprender se debilita mucho
• Como estudiar este fenómeno toma tiempo, la evidencia anecdótica también importa para entender lo que pasa en tiempo real, pero además hay material de respaldo como el reporte del MIT Media Lab y esta cobertura relacionada con Microsoft

Por qué este cambio es distinto

• Un desarrollador de C++ no decía que tenía “brain fog” por pasarse a Java o Python, y un administrador de sistemas no sentía que perdía su comprensión de redes por migrar a AWS
• Tampoco es nuevo que un ingeniero senior se mueva a un rol de gestión, programe menos y con el tiempo se ponga “oxidado”
• En la trayectoria tradicional, ingenieros que habían acumulado décadas de programación, fricción y resolución de problemas pasaban a roles donde trataban más decisiones de arquitectura que sintaxis
• Ahora, en cambio, los desarrolladores se están moviendo a flujos de trabajo de mayor nivel, donde gestionan agentes de IA sin tener necesariamente esa experiencia acumulada de largo plazo
• El problema es que estos flujos de trabajo exigen habilidades equivalentes a las que antes se obtenían con décadas de experiencia
• Los ingenieros senior tampoco son una excepción
  • Simon Willison explica que, aunque lleva casi 30 años como desarrollador, si no tiene un “modelo mental sólido” de lo que una aplicación puede hacer y cómo funciona, razonar sobre ella se vuelve más difícil a medida que se le agregan funciones

La paradoja del orquestador experto

• Una investigación reciente de Anthropic aborda la “paradoja de la supervisión” como un riesgo del uso frecuente de agentes de programación
• La idea central es que para usar Claude de forma efectiva hace falta supervisión, y para supervisar a Claude se necesitan precisamente las habilidades de programación que el uso excesivo de IA puede debilitar
• Sandor Nyako, que dirige a 50 ingenieros en LinkedIn, dice haber visto cómo se expande la atrofia de habilidades dentro de la organización, y pide a su equipo que no use IA en “tareas que requieren pensamiento crítico o resolución de problemas”
• Según él, desarrollar habilidades exige pasar por la dificultad y ejercitar el músculo de pensar profundamente en los problemas, y sin pensamiento crítico es difícil cuestionar si la IA realmente está en lo correcto
• Tampoco está claro qué cuenta exactamente como “uso excesivo”, pero tanto investigación basada en datos como material anecdótico muestran que las habilidades pueden debilitarse rápidamente incluso en pocos meses
• Usar agentes de programación crea una contradicción: debilita las mismas habilidades necesarias para gestionarlos bien

Los LLM aceleran lo equivocado

• No era obligatorio escribir código más rápido
• Sobre todo, no hacía falta producir más rápido grandes volúmenes de código que no se entienden por completo o que no pueden revisarse razonablemente a tiempo
• Antes de la IA, las prioridades de un buen desarrollador solían ser estas
  • Entender el código y su relación con la base de código
  • Verificar que se ajuste a estándares eficientes y documentados
  • Minimizar la cantidad de líneas necesarias para cumplir el objetivo sin perder legibilidad
  • Considerar el tiempo de procesamiento
• La codificación agentic y los LLM prácticamente invierten esas prioridades
• La capacidad actual y la forma en que se usan tienden a enfocarse en aumentar la cantidad de código generado en un tiempo determinado para ganar velocidad
• La velocidad es un subproducto natural de una habilidad alta, pero cuando se la fuerza, termina afectando la precisión
• Es posible usar LLM para mejorar la comprensión profunda y la concisión, pero la adopción forzada y el sobrecalentamiento organizacional centrado en el uso de tokens muestran que en la práctica el uso no va por ahí

Programar también es planificar

• Algunos desarrolladores planifican y piensan mejor con código
• Pensar y trabajar mediante código no es trabajo repetitivo sin sentido; es un proceso que obliga a pensar, a nivel técnico, en seguridad, rendimiento, experiencia de usuario y mantenibilidad
• En una entrevista sobre Spec Driven Development, Dax, creador de OpenCode, dice que cuando aborda tareas nuevas o difíciles, descubre qué debe hacer escribiendo código por sí mismo
• Prefiere formar el concepto tocando directamente los tipos, la interacción entre funciones y la estructura de carpetas, en vez de escribir primero una especificación enorme
• Lo que una persona dice no siempre coincide con su intención real, y los LLM rellenan la ambigüedad con supuestos o alucinaciones
• El resultado es más revisión, más correcciones hechas por agentes, más uso de tokens y una mayor desconexión con lo generado
• Y aun cuando se escriben prompts muy claros y estructurados, el LLM puede devolver métodos alucinados
• Un LLM no es un compilador, sino un motor de predicción del siguiente token, así que no se puede reemplazar un sistema determinista por uno probabilístico esperando que la ambigüedad llegue a cero
• Incluso desarrolladores senior muy favorables a la IA están empezando a ver esta desconexión como un problema creciente

Dependencia del proveedor e incertidumbre de costos

• Durante las caídas de Claude aparecieron publicaciones de desarrolladores y equipos de ingeniería que quedaron detenidos
• Algunos flujos de trabajo y capacidades de programación ya alcanzaron un nivel de fuerte dependencia de proveedores de IA específicos
• Habilidades que antes podían ejercerse solo con un teclado y un editor de texto ahora requieren una suscripción a un proveedor de modelos de IA

• El costo de los tokens es difícil de predecir

  • Los proveedores de modelos están fuertemente subsidiados, y los propios modelos siguen asentados sobre una base cambiante
  • Cada lanzamiento de un nuevo modelo repite un patrón de benchmarks altos, hype y quejas posteriores de que fue “nerfeado” tras el uso real
  • También aparecen quejas de que para hacer el mismo trabajo se queman 2 o 3 veces más tokens
  • Los costos de personal son conocidos, pero los costos de tokens son difíciles de prever por día, por mes y por año
  • Si todo el equipo adopta la codificación agentic como opción por defecto, la cuenta de costos debe mantenerse muy flexible
  • Primeagen dice que, con un workflow totalmente agentic, “el proveedor del modelo básicamente te posee”
  • Puede formarse una estructura industrial en la que haya que pagar el costo del consumo de tokens para realizar tareas que antes dependían del pensamiento crítico y la resolución de problemas humanos
  • Esto se parece menos a una simple dependencia de proveedor de producto y más a una dependencia de proveedor sobre la capacidad técnica de toda una industria
  • La base financiera e intelectual puede tambalearse en cualquier momento, y los LLM locales todavía no están listos para absorber ese nivel de uso
  • No es una teoría; ya se está reportando, y los propios proveedores de modelos lo están destacando
  • Otra investigación de Anthropic afirma que la habilidad de depuración cayó 47%
  • Si la IA se introduce de forma agresiva en el trabajo, especialmente en ingeniería de software, puede impedir que se desarrollen las habilidades clave de depuración cuando algo falla, porque se priorizan resultados rápidos apoyándose en la IA

Un enfoque que reduce el papel de la IA

• Los LLM pueden ser herramientas poderosas para aprender y mejorar capacidades
• Pueden ayudar a explorar conceptos y técnicas con más profundidad y amplitud, y a experimentar ideas nuevas con menos esfuerzo que antes
• Las herramientas de generación de código en sí no son algo nuevo
  • Emmet, el autocompletado y los snippets ya eran herramientas para escribir menos código directamente y generarlo más
  • COBOL también buscaba expresar más instrucciones con menos escritura usando palabras tipo inglés como MOVE y WRITE
  • El lema de jQuery también era “write less, do more”
• Los LLM pueden verse como otra adición a esa línea de herramientas de generación de código
• La diferencia importante está en usar los LLM y los agentes de programación como procesos de apoyo
• Es posible usar IA para hacer brainstorming en la etapa de planificación sin sacrificar la habilidad propia por productividad, y seguir involucrándose activamente en la implementación
• Delegar solo cuando haga falta permite obtener ganancias de productividad mientras se reduce la deuda de comprensión

Una forma de uso cotidiana

• Usar LLM para generar especificaciones y planes, pero que la implementación la lidere una persona
• Es una manera de invertir el workflow de “orquestación”, y según la tarea implica programar directamente entre 20% y 100%
• Incluso al usar un modelo, conviene escribir pseudocódigo con frecuencia para reducir la distancia entre la solicitud y el código generado
• El modelo se usa para generar código temporal, documentación conversacional e investigación
• Se usa como herramienta de delegación responsable para preguntar, iterar, refactorizar y aclarar mejor los enfoques
• No se genera más código del que pueda revisarse de una sola vez
• Si hay demasiado para revisar, se baja la velocidad, se divide el trabajo y, si hace falta, se refactoriza manualmente para comprender el resultado final de forma integral
• No se delega a un LLM o a un agente una implementación que uno mismo nunca haya hecho o que no podría hacer por su cuenta
• La excepción son fines educativos o tutoriales, y muchas veces ese resultado después se descarta
• En resumen, la IA debería usarse más como la computadora de una nave que como Data de Star Trek

Trabajar mejor, no solo más rápido

• Las mejoras de productividad de los modelos sí existen
• Al mismo tiempo, la fricción y la comprensión que surgen de tratar el trabajo directa y frecuentemente también importan de verdad
• Los intentos de democratizar la programación sin entender el código han fracasado repetidamente
• Para entender el código, hay que interactuar directamente con él
• Si uno deja de involucrarse y de escribir código de forma continua, puede perder esa comprensión y esa conexión
• Si se pierde la comprensión, también se debilita la capacidad de gestionar mejor a los agentes, y la etapa de programación con IA se convierte en una transición extraña e innecesariamente estresante

Podría ser otro gran experimento

• La tendencia actual parece otro experimento masivo que estamos aplicándonos a nosotros mismos sin entender del todo sus efectos de largo plazo
• Cuando se adoptaron las redes sociales, tampoco se entendían bien sus implicaciones de largo plazo, y después aparecieron problemas como déficits generalizados de atención
• Esta vez está en juego algo más riesgoso
• Jeremy Howard, creador de fast.ai, dice que quien apueste todo a los agentes de IA está garantizando su propia obsolescencia
• Si externalizamos todo el pensamiento a la computadora, dejamos de pasar por el proceso de desarrollar capacidades, aprender y volvernos más competentes

[GN⁺]

Comentarios de Hacker News

• En los últimos años trabajando con programación agentic, he aprendido más sobre los lenguajes, sistemas y herramientas que uso que en 35 años programando directamente a mano
  Mi capacidad para decidir sistemas, técnicas y enfoques sigue siendo muy superior a la de la herramienta, pero estas herramientas se parecen a un pasante muy erudito que sabe muchísimos detalles misceláneos. Tiene poca experiencia y comete errores con entusiasmo, pero al menos al principio acepta la retroalimentación y actúa en consecuencia. Eso sí, como no lo entiende ni lo internaliza por completo, a menudo se le olvida
  La idea de que uno debe saberlo absolutamente todo sobre todo lo que toca es muy ingenua. Si trabajas en dos o más equipos, habrá muchas partes que no entiendas del todo, y si es una base de código antigua, casi todo puede resultarte ajeno. En un enorme monorepo acumulado durante décadas, ya es suerte si entiendes bien incluso la parte en la que todos te consideran experto
  Quienes hacen este tipo de afirmaciones suelen ser muy junior, o trabajan casi solos, o da la impresión de que llevan 20 años pegados al mismo proyecto. Nadie que trabaje en un equipo o en una gran organización puede decir que conoce toda la base de código, y lo mismo aplica para quien programa de forma agentic. Aun así, puedes preguntarle cosas al agente y obtener respuestas, y como alguien que ha leído código ajeno toda la vida, también puedo leer código escrito por un LLM. No me importa en absoluto si el código malo lo escribió una máquina o una persona, y al menos la máquina sí toma mi feedback y actúa sobre él

  • Suele ser cierto que no hace falta saberlo todo, ni siquiera la mayor parte, pero sí debes poder encontrar y comprender rápidamente lo que necesites sobre el proyecto o sistema en el que trabajas
    He visto muchos equipos de software quedarse totalmente atorados ante un problema trivial en cuanto hacía falta alguna habilidad adicional, como lenguajes de bajo nivel, ensamblador, algoritmos poco comunes o protocolos de red
    Por otro lado, también se atascan no porque no tengan la capacidad de interpretar lo que ven, sino porque usan algo que es una caja negra, como una librería privativa o un sistema operativo privativo, y no pueden profundizar en su interior ni verificar cómo funciona realmente
    Por eso creo que, aunque solo haga falta en casos muy raros, siempre debe ser posible trabajar en un entorno donde puedas averiguarlo todo sobre todo lo que estás tocando
  • Con 35 años de experiencia ya tienes acumuladas la capacidad de aprender y la estructura mental general para adquirir conocimiento nuevo, y además sabes usar la programación agentic como herramienta de apoyo. Los juniors que empiezan hoy no tienen eso, así que dependen demasiado de la programación agentic y ni siquiera saben qué es lo que no saben
  • Este texto no dice “hay que saberlo todo sobre todo lo que uno toca”, sino que la capacidad de escribir código y la capacidad de leer código eficazmente están conectadas de forma esencial
  • De acuerdo. Yo tampoco conozco toda la pila completa, porque trabajo bien sin saber cómo la arena se convierte en transistores ni conocer ensamblador
    Lo importante es no tener miedo de aprender el resto del sistema y mantener un índice
    Sobre todo, tienes que poder orientarte rápido en cualquier cosa. Eso te permite abarcar mucho. Profundizas cuando hace falta, y cuando no, lo revisas a alto nivel; se trata de elegir el nivel adecuado para el problema
    Hace mucho, en la universidad, a los estudiantes de ciencias de la computación les enseñaban ingeniería en general. Cuando pregunté: “¿Cuándo voy a necesitar saber ingeniería química o sistemas de control analógico?”, me respondieron: “Probablemente nunca lo uses. Pero debes poder entenderlo lo bastante rápido como para programarlo y luego olvidarlo. Nosotros te damos una base sólida”
    Eso aplica exactamente igual dentro de una gran base de código
  • El problema aquí es que, en cierto sentido, el agente que escribió el código y el agente que responde preguntas sobre ese código no son el mismo agente. Si el agente original no dejó rastro de su proceso de razonamiento, normalmente te quedas a oscuras
    Herramientas como git-ai [0] capturan la sesión del LLM, vinculan cada edición de archivo con una acción específica del agente y permiten que el agente consulte, sobre un fragmento concreto de código, la conversación alrededor de ese cambio: qué prompt le dio el usuario, cuál fue el razonamiento del LLM que generó ese código, etc. Eso podría cambiar el equilibrio, pero todavía no se usa ampliamente
    [0] https://usegitai.com/

• Como desarrollador senior con más de 25 años de experiencia, hace poco me aventaron a una reunión del tipo “¿puedes entrar cinco minutos?”, y de verdad odio ese tipo de reuniones donde te jalan a media conversación sin ningún contexto
  Las preguntas empezaron a llegar rápido, sin introducción alguna, y eran sobre una integración externa entre decenas de ellas. Para empeorar las cosas, ese lado usa su propia terminología, distinta a la nuestra
  Como dependí mucho de modelos para construir esas integraciones, me costó muchísimo incluso entender las preguntas. Era un trabajo extremadamente aburrido, con una especificación externa enorme ya dada
  Sigo pensando positivamente que, sin usar modelos, probablemente ni dedicándole 10 veces más tiempo habríamos terminado esas integraciones. Pero ahora estoy considerando seriamente volver a documentar los puntos de “ajá” para que no vuelva a pasar este tipo de momento incómodo
  Nunca me había sentido tan ignorante y avergonzado en una reunión, y lo único que pude decir fue: “Eso lo reviso y les respondo, esto también, aquello también”
  La deuda cognitiva es totalmente real y, personalmente, me duele más que la deuda técnica. La deuda técnica la comparte todo el equipo, pero la deuda cognitiva es personal, y si además quien la creó fui yo, entonces debería conocerla mejor
  En adelante, voy a considerar que un trabajo no está terminado si no genero una lista de términos en Markdown tipo flashcards de 5 minutos con cosas como “qué es esto” y “qué es aquello”

  • Esto se parece a una situación de la que los médicos suelen quejarse. Llega un paciente diciendo que solo necesita cierta receta, pero los buenos médicos muchas veces no dan ni medicamentos ni consejos hasta entender correctamente el panorama completo
    Un desarrollador senior es alguien que debe poner freno cuando algo no le parece bien. Tiene autoridad. Basta con decir: “Qué pregunta tan interesante. Para darte mi perspectiva necesito más contexto. ¿Podrían explicarme brevemente la arquitectura del sistema o qué problema real intentan resolver con este enfoque?”
  • Me pregunto qué clase de trabajo es ese donde te meten a media reunión, te lanzan preguntas técnicas sin contexto y esperan que las contestes ahí mismo. Mucha gente querría evitar algo así, así que estaría bien saberlo
    Cuando te tratan así, decir “para responder bien a esta pregunta necesito revisar la documentación y el código” es una respuesta completamente válida y bastante diplomática
  • Baja el ego y no te preocupes. Usaste herramientas, y sin ellas te habría ido peor. Basta con decir: “No lo sé, se lo preguntaré a la IA”
  • Me recordó el sketch de 7 minutos de 2014, “The Expert”: https://www.youtube.com/watch?v=BKorP55Aqvg
    No son nada agradables las reuniones donde la especialización no se ve como algo que construir, sino solo como una forma de confirmar un sesgo de confirmación creativo
  • Fácil. Al final haces que el agente escriba esa lista. Y luego simplemente nunca la lees

• Para encontrar problemas en el código generado, el desarrollador tiene que poner atención. Muchos desarrolladores, especialmente en grandes empresas, ya están bastante desconectados del trabajo y solo buscan la forma de cerrar tickets y pasar la responsabilidad con el mínimo esfuerzo posible
  Aunque tengan capacidad, esos desarrolladores no van a esforzarse por entender el código generado lo suficiente como para encontrar los problemas que el agente dejó pasar. Más aún en esta fiebre actual por la velocidad impulsada por IA

  • Exacto. El código generado es más difícil de leer porque rompe todas las expectativas semánticas que dependen del modelo mental de un autor humano
    El código generado suena plausible a nivel de lenguaje, pero a menudo imita modismos comunes de manera incoherente sin darse cuenta, de modo que bugs reales pueden quedar escondidos por accidente de formas que ni un humano normal, ni siquiera un mal programador, imaginaría fácilmente
    Como el LLM no tiene una evaluación interna, el revisor debe tener eso en cuenta y evaluar línea por línea, reconstruyendo desde cero las razones ocultas y el conocimiento implícito que el LLM nunca tuvo. A veces eso termina arrastrándote hacia no-problemas y desperdiciando tiempo valioso
    A estas alturas, muchas veces requiere más inversión que escribirlo desde cero
  • En las grandes empresas hay excepciones, pero en muchos equipos a muchos desarrolladores incluso los castigan por preocuparse
  • Algunas personas dicen que el hermano mayor te vende comida chatarra y luego te vende la “solución” para bajar de peso
    Tal vez ahora las empresas están comprando IA chatarra, y en la siguiente etapa les prometerán la “solución”. El capitalismo está funcionando exactamente como era de esperarse

• Siento que este texto esquiva un poco el punto central
  Sí hay una pérdida de habilidades cuando usas mucho la IA
  Pero quisiera reconocer al elefante incómodo en la habitación. La IA está volviendo a la gente demasiado rápida. No quiero decir que producir rápido sea malo en sí mismo, sino que la producción rápida y el código están adelantándose a la comprensión y experiencia globales con las que se generaron. Se está recompensando más a quien sabe hablar de valor de negocio que a quien construye tomando decisiones seguras desde el conocimiento profundo
  La IA es buena y puede producir buenas soluciones, pero en última instancia no sabe lo que hace y, en el mejor de los casos, necesita una dirección fuerte
  Estamos metidos en el lodazal del desarrollo guiado por negocio, y no hay suficiente castigo reputacional severo para las malas decisiones

  • La pérdida de habilidades es real. Pero yo llevo literalmente 10 años quejándome de eso con mis jefes. Así que para mí la IA es solo uno de varios problemas. Por alguna razón, cada año terminé programando menos
    Dicho eso, no estoy seguro de que la pérdida de habilidades sea un problema tan grande. Quizá solo sea una señal de que la naturaleza de nuestro trabajo está cambiando. Tal vez entremos en una época en la que saber de buena arquitectura se valore más que recitar de memoria el estándar de C++ y usar correctamente cientos de features
  • En general estoy de acuerdo, pero la verdad brutal es que las prioridades de la mayoría de las empresas siempre han sido, más o menos, un desarrollo guiado por negocio tosco e improvisado. El proceso de ingeniería centrado en humanos era un freno que evitaba por accidente las peores consecuencias de esa filosofía; no era un mecanismo intencionalmente diseñado
  • Otro aspecto de “ir demasiado rápido” es que cambia el orden de nuestros problemas
    En el desarrollo normal uno suele debatir más entre “¿de verdad queremos construir esto?” y “¿qué podría salir mal si lo hacemos así?”, idealmente antes de aprobar el PR o fusionar y desplegar. Parte de eso se está moviendo a “ya veremos después quién se queja”. Como dices, más vale prevenir que lamentar
  • En un mundo guiado por negocio, con gobiernos guiados por negocio que escriben reglas guiadas por negocio, no sé cuál sería la alternativa si quieres optimizar para el éxito
  • No son solo las empresas. También en proyectos de código abierto veo con frecuencia PRs enormes que, en apariencia, están bien, pero traen como mil bugs pequeños. No son catastróficos, pero sí lo bastante molestos
    Además, ese código no seguía el C++ idiomático del proyecto, y el LLM ignoró por completo APIs que ya existían. Se puede corregir y los mantenedores deberían detectarlo, pero por la cantidad de código generado todo el mundo tiene que gastar demasiada energía

• Sin duda estos posts de blog se habrán escrito con ayuda de IA, y aun así este ha sido tema de comentarios aquí y por todo internet durante años. La atrofia de habilidades es una preocupación seria, y todos los escépticos de la IA la vienen repitiendo desde 2022, pero da la impresión de que a algunas personas y algunos lugares simplemente no les importa
  Si llega un punto en que solo estás jalando la palanca de una máquina de basura sin ninguna comprensión del código, entonces puede ser válido que tu jefe pregunte por qué deberías ganar más de 50 mil dólares al año

• Usar IA para ir más rápido es optimizar lo incorrecto. En todos los lugares donde he trabajado, “escribir código” en sí era la parte que menos tiempo consumía comparada con todo lo demás necesario para implementar una feature
  Pensemos en una feature que podrías codificar en un día. Primero hay que planearlo todo mediante la liturgia de planificación que use la empresa, sea Agile o Waterfall, dividir el trabajo, crear tickets en JIRA y decidir quién lo hará. Eso solo ya puede tomar días o semanas. Luego hay que escribir un documento de diseño con la propuesta y obtener revisiones de colegas y del equipo; si es una feature sustancial, eso ya es otra semana. Si involucra varios equipos, súmale una semana más para conseguir su aprobación y un acuerdo de diseño. En algunos lugares además hace falta una autorización formal para empezar, lo que puede añadir unos días según la agenda y disponibilidad de quien aprueba
  Después escribes el código en un día y haces que pasen las pruebas
  Luego viene la revisión de código, con mucho ida y vuelta con el equipo, varias iteraciones y posiblemente revisiones adicionales. Ahí se van otros días o semanas. Si es una empresa más grande, hay que pasar por toda clase de revisiones de otros departamentos como legal, privacidad, rendimiento, accesibilidad, QA, etc. Aunque se hagan en paralelo, seamos conservadores y sumemos otras 2 semanas. Finalmente lo subes a staging y debe madurar un tiempo entre dogfooders internos antes de que haya confianza en que funciona. Súmale 1 semana. Ya está listo para pasar de staging a producción, pero ninguna empresa seria manda algo directamente al 100% de producción. Hay que aumentar el porcentaje poco a poco y revisar feedback y métricas por si hace falta rollback. Hasta el lanzamiento completo pueden irse otras 2 semanas
  Así que, en una feature que tardó unos dos meses desde el diseño hasta el lanzamiento, estamos armando un escándalo para reducir de un día a 5 minutos la parte que tomó un día

  • Me recordó este aforismo de ingeniería de software
    Cuando creas software, debes recordar que es un snapshot de tu comprensión del problema. Le dice a todo el mundo, incluso a tu yo futuro, cuál era tu enfoque, tu claridad y lo apropiada que era tu solución para el problema en cuestión. Así que conviene elegir sabiamente qué quieres decir
    Está muy bien señalado eso de que en una feature de dos meses de diseño a lanzamiento estamos obsesionados con reducir a 5 minutos la parte de un día
  • Los modelos ahora son extremadamente buenos para automatizar casi por completo tareas aburridas como actualizar dependencias, scripts de build y despliegue, y pruebas unitarias. Cosas que antes tomaban días ahora pueden tomar minutos, y aquí sí es fácil obtener una mejora de velocidad de 50x
    Este tipo de trabajo representaba una parte nada menor del día a día de todos los ingenieros en empresas estables. Llámalo “ingeniería de plataforma” o como quieras, pero esa área está muerta
    Además, ideas técnicamente riesgosas que antes no se intentaban porque el riesgo y el esfuerzo no compensaban la recompensa ahora están al alcance de la mano. No es solo “ir más rápido”; la velocidad a la que puedes probar algo cambia la naturaleza misma del proceso de ingeniería
  • Todos los procesos que describiste existen para maximizar el tiempo que los ingenieros de software pasan escribiendo código[0]. En las empresas, los ingenieros de software están entre los empleados más caros, y desperdiciar su tiempo tiene impacto real en el negocio, por eso existen esos procesos
    Si los ingenieros de software se vuelven lo bastante baratos, desaparece gran parte de la necesidad de muchos de esos procesos. Las empresas que ya tienen esa burocracia lo van a pasar mal, porque romperla es extremadamente difícil, pero las empresas que nunca la tuvieron o que pueden eliminarla obtendrán una ventaja competitiva considerable
    No es algo nuevo. Los startups siempre han competido con empresas establecidas por velocidad de ejecución. Lo nuevo es la capacidad de sostener esa velocidad por más tiempo
    Revisiones como legal, privacidad, rendimiento, accesibilidad y QA también están en la mira. Si una empresa puede trasladar la responsabilidad legal de esas revisiones a un proveedor externo, lo hará
    [0] Dejemos de lado por un momento la ironía de que buena parte de este proceso termina recayendo precisamente en los empleados a los que supuestamente iba a ahorrarles tiempo
  • Depende muchísimo de en qué empresa trabajes. Por ejemplo, no puedes operar un startup de esta manera
  • No todas las empresas trabajan así
    En big tech sí hay muchos de esos procedimientos inflados, pero las empresas pequeñas pueden moverse rápido y sin tanta ceremonia

• La calidad del código, al final, depende de ti
  Nada te impide iterar con el agente hasta pulirlo y obtener un código de exactamente la misma calidad que si lo hubieras escrito tú mismo

  • Si mi meta es el nivel de calidad de mi propio código, entonces me resulta más rápido y menos frustrante escribirlo yo mismo
  • Yo no quiero la calidad de mi código, quiero calidad de código AGI. Eso fue lo que me prometieron, junto con mochilas propulsoras y autos voladores
  • Por eso no entiendo estos textos, y me parecen un estudio de caso sobre la pereza humana. Si quieres buenos resultados, revisa el resultado e itera. Si quieres una buena base, escribe tú mismo esa base, y después eso ya evita en gran medida que el LLM escriba mal código
    Estos textos son bastante frustrantes. Aunque el punto del autor sobre el costo de tokens sí es real y sí es un riesgo
  • Nada te lo impide, pero sigue siendo más lento que escribirlo tú mismo desde el principio. El aumento de productividad por IA es un mito
  • En mi experiencia, se tarda lo mismo o más en llevar a la IA de la mano hasta ese punto. Especialmente si ni siquiera hay evidencia de que sea más rápido, es mejor escribirlo tú mismo y saber cómo funciona que meter un LLM como intermediario

• Uso herramientas de IA para hacer brainstorming de enfoques y, de vez en cuando, generar algo de código, pero el tecleo real lo hago yo. Así es menos probable que con el tiempo olvide los mecanismos y el lenguaje de programación

  • Yo también, casi siempre le pido un plan de implementación, pero minimizando el código o incluso sin código, o en pseudocódigo, y el código real lo escribo yo. En trabajo de código abierto, lo que disfruto en esencia es escribir código directamente
    Sinceramente, si todo se redujera a hacer prompts para que el LLM escriba el código y luego revisarlo, dudo que quisiera seguir siendo mantenedor de open source. No parece nada satisfactorio
    En un trabajo pagado real sí me pregunto cómo cambiaría mi uso de LLM. Soy desarrollador de software porque amo esta tecnología. Me gusta el acto de construir, de usar el cerebro para convertir ideas en código. Si el trabajo se volviera solo hacer prompts al LLM, no sé si seguiría en esta profesión. Como mínimo, empezaría a explorar un cambio de carrera
  • Un enfoque posible es pedirle que nunca escriba el código por ti. Eso lo obliga a explicar, y luego tú mismo pruebas esa idea al codificarla, lo que te ayuda a entenderla mejor
    Uso este método con código que tendré que mantener. Aun así, el modelo mezcla mucha información incorrecta, así que de vez en cuando me hace caer. Por lo general son cosas que antes eran correctas pero ahora ya no
    En scripts desechables o fáciles de verificar sí dejo que genere, pero le pido que evite sobreingeniería o intentos de cubrir todos los edge cases. En scripts, suele ser más fácil de entender si un paso falla y simplemente revienta, dejando claro dónde estuvo el problema
    Evito lenguajes que me cuesta leer, como PowerShell, y prefiero que genere cosas lo bastante cortas como para caber en la pantalla y poder leerlas y entenderlas completas. Python, Bash y Batch son los lenguajes de scripting que más uso
  • Yo también configuré el prompt del sistema para que nunca me dé una solución completa ni código completo. Así, cuando pregunto, me da un ejemplo corto de unas 10 líneas o pseudocódigo. Eso es mucho más fácil de razonar
    Todavía rechazo más del 50% de las sugerencias de IA. Porque son demasiado genéricas, o mueven código sin motivo, o a veces simplemente están mal
  • Si la IA puede volver a enseñarte cualquier cosa que hayas olvidado, ¿por qué importaría olvidar?

• Lo gracioso es que esta tecnología es una de dos cosas
  O es una tecnología para managers que permite delegar sin experiencia, aunque no puedan saber si está mal o si es imposible, o es una tecnología para coders que sí tienen experiencia, pero que poco a poco van perdiendo esa misma experiencia
  Así que no tengo muy claro para quién es, aparte de los VCs y accionistas hasta el próximo trimestre

• Un poco fuera del tema, pero me da risa que el artículo diga que Spec Driven Development es el futuro
  Técnicamente, eso ya lo hacíamos en la época de Waterfall. A veces hasta extraño cuando había buena documentación. En los últimos 10 años, quizá más, muchas veces he recibido tickets de JIRA de una sola línea, que no especifican casi nada, y con frecuencia tengo que llamar a la gente para aclarar
  Yo todavía evito trabajar con IA. Quiero probar algunos modelos locales por experimentar, pero me niego a pagar por algo armado a partir del trabajo ajeno. Y hasta ahora los modelos locales han estado por debajo de las expectativas

  • Los modelos remotos van a seguir encareciéndose. El futuro de su negocio depende de la expectativa de mejoras en el costo de inferencia. Nadie debería querer atarse voluntariamente a esa cárcel