El bucle que viene
(lucumr.pocoo.org)- Fuera del agente de código, las iteraciones a nivel de harness donde una cola de trabajo y un harness gestionan la repetición están surgiendo como el nuevo patrón central de la ingeniería de agentes
- Cuanto más tiempo opera un modelo de forma autónoma, más fácil es añadir defensas locales y fallback que invariantes fuertes, lo que puede debilitar la comprensión del diseño y el control en código que debe mantenerse a largo plazo
- En cambio, en áreas donde es fácil verificar o descartar resultados, como portabilidad de código, experimentos de rendimiento, escaneos de seguridad e investigación, la repetición mecánica ya está funcionando con fuerza
- Cuando atacantes y reporteros ejecutan bucles, los mantenedores también sienten la presión de usar máquinas para triage, reproducción y respuesta; el caso de curl muestra la carga que generan los reportes creados por IA
- El reto hacia adelante no es si usar bucles o no, sino cómo mantener dentro de ellos el juicio humano, las reglas de ingeniería, la supervisión responsable y una arquitectura comprensible
Bucles que corren fuera del agente de código
- Dentro del agente de código ya existe un bucle del agente donde el modelo llama herramientas, incorpora resultados, lee y modifica archivos, ejecuta pruebas y luego entrega una respuesta
- El patrón que está destacando ahora es el bucle a nivel de harness que está por fuera
- Una tarea entra a la cola
- La máquina toma la tarea e intenta resolverla
- Se detiene, y luego el harness decide si realmente terminó
- Si no terminó, inyecta un mensaje en la misma sesión, inicia una nueva sesión con contexto modificado o pasa la tarea a otra máquina
- Este bucle externo mantiene viva la tarea incluso después del punto donde normalmente el modelo diría “terminé”
- El bucle en sí no es nuevo, pero últimamente ha empezado a verse más seguido en la ingeniería de agentes y en la conversación de Twitter
- Encima de Pi también aparece parte de este flujo, y como Pi es un harness, queda en el centro de estos experimentos
La incomodidad que aparece con el código de larga vida
- Para el código que realmente importa, este enfoque todavía no encaja bien
- La clave está en el criterio y el control
- Se quiere entender el código que se despliega
- Bajo presión o al discutir con otras personas, uno debería poder explicar cómo funciona el sistema sin pedirle primero a la máquina que lo explique
- Por ahora, entender el código sigue siendo importante
- El código generado sin intervención, especialmente el que sale de un bucle, tiene problemas recurrentes
- Es demasiado defensivo
- Es demasiado complejo
- Se queda en razonamiento local
- Evita invariantes fuertes
- En vez de volver imposible un estado incorrecto, agrega fallback
- Crea código duplicado y malas abstracciones, y cubre diseños poco claros con más mecanismos
- Combinaciones como Claude Code y Fable pueden trabajar más de 30 minutos seguidos sobre un mismo problema, así que hay menos human in the loop que antes
- La calidad del código producido hoy con un enfoque de harness sin intervención se siente incluso peor que la del otoño pasado, y al menos desde este criterio casi no se ve mejora
El bucle amplifica los hábitos del modelo
- Cuando el modelo ve una falla local, tiende a añadir una defensa local
- Andrej Karpathy ha dicho que los modelos “temen fatalmente” a las excepciones
- En sistemas con invariantes importantes, especialmente formatos de datos persistentes o infraestructura central, la forma de “manejar todos los casos malformed” puede no ser la corrección adecuada
- Un mejor camino es hacer imposible representar esos casos malformed o impedir que puedan escribirse desde el principio
- Incluso con bastante guía manual, a los LLM les cuesta producir este tipo de código de forma natural, y pueden intentar manejar errores que ya se volvieron imposibles
- Cuando este hábito se pone detrás de un bucle, el problema se amplifica
- Cada iteración añade una pequeña defensa más
- El sistema parece más robusto, pero se vuelve cada vez más difícil de entender
- Cuanto más se sueltan las manos, más crece esta tendencia
- Si se les da esta herramienta a personas junior sin lineamientos claros, puede enseñarles malas prácticas
- Si se les pregunta por qué, pueden defender sus decisiones de forma convincente
Áreas donde el bucle sí encaja bien
- El patrón del bucle ya funciona muy bien en algunas áreas
- La portabilidad de código es un caso representativo
- Existen casos de portabilidad automática a gran escala como llevar partes de Bun de Zig a Rust
- También se ha usado con éxito para portar MiniJinja a Go
- También encaja bien en la exploración de rendimiento
- La máquina prueba experimentos
- Ejecuta benchmarks
- Descarta fallos
- Sigue explorando
- También encaja de forma natural en escaneos de seguridad y casi cualquier tipo de investigación
- Se puede explorar un espacio de problemas complejo y reportar resultados
- No hace falta necesariamente hacer commit de código que vaya a durar mucho tiempo
- Lo que tienen en común los casos exitosos es que el resultado no necesita mantenerse por mucho tiempo, o transforma código existente, o se parece más a un proof of concept, una idea, un hallazgo o una transformación mecánica
- Lo que necesita el harness no es una señal completamente objetiva o binaria, sino una señal lo bastante útil como para empujar la siguiente iteración
- Muchos casos exitosos usan otro LLM como judge u orchestrator
- Una traducción mecánica puede validarse con test cases binarios o juzgarse con un LLM
- Claude Code está volviéndose cada vez más capaz de construir y ejecutar flujos completos de experimentación
- Aunque el código generado sea desordenado, eso parece más un problema del modelo que de la capacidad de juicio del harness
Un cambio hacia tratar el software más como un organismo que como una máquina
- Todavía no se siente cómodo escribir código duradero con este mismo estilo de bucle
- El ideal anterior se parecía más a entender el software como una máquina determinista
- Al quitar una capa, se podía entender más a fondo
- Una máquina observada de manera no determinista difícilmente se consideraba óptima
- Era deseable que la arquitectura avanzara hacia más determinismo
- Se consideraba buen diseño permitir que una persona nueva pudiera explorar una base de código compleja
- En un sistema bien diseñado había ingenieros que sabían dónde estaban las invariantes, qué partes eran load-bearing y qué cambios eran seguros
- El software grande ya no cabe entero en la cabeza de una persona, y los sistemas distribuidos a veces se diagnostican como un médico que observa síntomas, plantea hipótesis y pide más pruebas
- Los LLM empujan esta dirección aún más rápido
- Aparece un problema en producción y la máquina lee logs
- Propone la root cause
- Sube un parche
- Otra máquina lo revisa y, a veces, lo integra a
mainsin supervisión humana
- Esta forma de trabajar es poderosa y atractiva, pero puede hacer que la gente ya no entienda el sistema completo de la misma manera que antes
- Lo opera, lo monitorea y lo estabiliza, pero no necesariamente lo entiende
- No todo el código necesita autoría humana, y también es posible que en el pasado se haya escrito código peor
La presión de la que es difícil salirse por completo
- Puede ser difícil hacer opt out de un futuro totalmente guiado por máquinas
- La seguridad es el caso más claro
- Aunque uno no construya software con bucles, otras personas pueden ejecutar bucles contra ese software
- Los atacantes mantienen máquinas corriendo todo el tiempo
- Incluso si no son atacantes, los investigadores de seguridad hacen trabajo automatizado
- Como resultado, entran juntos problemas reales y ruido
- El texto de Daniel Stenberg sobre curl, summer of bliss, muestra la presión que ya reciben los mantenedores
- No parece que la IA tenga un papel grande en el desarrollo central de curl
- Aun así, los mantenedores están desbordados de reportes, y la mayoría son reportes generados por IA
- Si atacantes y reporteros ejecutan bucles, los defensores también tienen que seguirles el ritmo
- No necesariamente para escribir parches directamente
- Puede ser por la presión de hacer triage, reproducir y responder
- La presión competitiva es parecida
- Algunos equipos pueden construir más que otros por pura velocidad
- Un grupo pequeño que coordine bien a las máquinas puede acelerar un proyecto de golpe
- Algunas startups pueden hacer con 5 personas lo que antes requería 50
- Alguien puede ejecutar bucles contra un producto y pedirle que lo “haga parecido a otra cosa”
- No todo el software se verá afectado de la misma forma
- En algunas áreas se castiga lo descuidado y se exige confianza y responsabilidad
- En mucho software, la velocidad, la experimentación rápida y la cobertura amplia son muy importantes
La nueva dependencia que crean los bucles
- Las herramientas creadas por bucles pueden generar no solo un costo puntual, sino una dependencia cognitiva continua
- En el pasado, el desarrollo de software dependía de herramientas costosas como los compiladores, pero las herramientas actuales se parecen más a sistemas a los que hay que seguir accediendo
- Si una base de código fue creada con bucles, revisada con bucles, parchada con bucles y mantenida con bucles, habrá problemas si se corta el acceso a sistemas de ese mismo nivel
- Restricciones comerciales pueden eliminar el acceso a los modelos más potentes
- El costo puede volverse imposible de sostener
- El equipo puede perder la última capacidad que tenía para entender el código sin ayuda de máquinas
- Puede aparecer una base de código que no solo sea difícil de mantener para las personas, sino que asuma como parte del modelo de mantenimiento la participación continua de máquinas
- Ya se están viendo algunos cambios
- Cada vez más personas hacen merge de código que no pueden explicar por completo
- Se refuerzan o reescriben reportes de issues y discusiones de chat con contexto provisto por la máquina
- Se depende de la máquina para resumir y dar contexto
- Se ve con más frecuencia a personas conversando a través de un LLM
- No necesariamente se puede decir que esto esté mal, pero sí es un cambio grande respecto a la forma anterior
Los harnesses y herramientas que harán falta hacia adelante
- No basta con coordinar más bucles
- Aunque se visualicen mejor los cambios, la orquestación y los agentes, la comprensión no se recupera automáticamente
- La dirección necesaria parece ser una de dos
- Encontrar formas de volver a meter a las personas dentro del bucle con fuerza y hacer que los cambios del bucle puedan leerse a largo plazo
- O encontrar mejores formas de componer sistemas cada vez más complejos
- También está cambiando la forma de pensar sobre Pi
- Pi ha sido cuidadoso, y esa cautela es buena
- No se quiere un futuro donde cada interacción se convierta en cambios hechos por una multitud de máquinas que cuesta seguir
- Tampoco se quiere que Pi se vuelva un caos imposible de mantener para ganar la competencia del software escrito por sí mismo
- Tampoco se quiere que Pi fomente esta forma de ingeniería
- Aun así, Pi es un harness, y los harnesses están en el centro de los nuevos experimentos
- Las colas de trabajo de código, la orquestación de agentes, los subagent y las durable session se volverán cada vez más importantes
- Incluso quienes no quieren aceptar ciegamente los bucles deberían empezar a experimentar
- Porque hace falta entender cómo hacer que este futuro permanezca dentro de ciertos límites y sea soportable
El problema de controlar el bucle
- Si se acepta el bucle del harness, entonces es el harness el que decide cuándo terminó el trabajo
- En el bucle del agente, al final el modelo dice “done” y una persona revisa
- Incluso antes de eso, normalmente una persona va guiando en el camino
- La persona participa, y en ese proceso aprende
- En un bucle operado por el harness, el papel de la persona se vuelve poco claro
- La señal de “done” también pierde significado y pasa a ser un mensaje para que otra máquina lo juzgue
- El papel de la persona puede acercarse al de un mensajero
- Actualmente, buena parte del código producido de esta forma no gusta, y tampoco resulta agradable interactuar con software creado con apoyo de IA
- Los bucles son poderosos, pero van quitando responsabilidad y, por ahora, también empujan a rendirse ante la máquina
- Aun así, parece que el futuro de los bucles va a llegar
- Ya se ven equipos muy pequeños construyendo a una velocidad que parecía imposible
- Las bases de código se están volviendo organismos más ambiguos y caóticos
- Esas bases de código son útiles y desordenadas al mismo tiempo
- La pregunta hacia adelante no es “si se van a ejecutar bucles”, sino algo más cercano a esto
- Cómo no renunciar al juicio dentro del bucle
- Cómo mantener buenas reglas de ingeniería
- Cómo lograr que personas responsables sigan supervisando
- Cómo repensar la arquitectura del código para poder conservar la cordura
1 comentarios
Opiniones de Hacker News
Loop funciona cuando dedicas tiempo por adelantado a entender bien lo que quieres. La premisa es la claridad, y tienes que ser capaz de escribir una especificación con suficiente cuidado como para poder pasársela a un colega junior.
Normalmente, para llegar a entenderlo hay que pasar por 5 o 6 versiones rotas y torpes. Esas 5 o 6 rondas de prueba y error no se pueden acelerar, y ninguna tecnología de agentes puede evitar el tiempo que necesita el cerebro humano para pensar. Así que la mayor parte del tiempo se va y viene entre “no sé lo que quiero, voy a tener que leer, escribir y manosear el código” y “creo que ya pasó suficiente tiempo como para saber lo que quiero”. Es muy fácil engañarse a uno mismo, pero solo puedes usar Loop una vez que de verdad sabes lo que quieres. Mucha gente cree que puede adelantarse con agentes, pero la comprensión y la claridad no se pueden fingir, y se nota dolorosamente cuando alguien se salta esa etapa
No tuve que pensar mucho tiempo en lo que quería; simplemente quería que hiciera eso. El resultado sigue siendo mixto y todavía no confío lo suficiente como para dejarle una codebase delicada, pero en el juego que estoy haciendo el tiempo que paso verificando se redujo a una quinta parte de lo de antes. No necesariamente es algo bueno. Es muy probable que esté pasando menos tiempo y perdiéndome buenas ideas. Pero antes los prompts se habían vuelto mecánicamente
#now-do-this,#now-review-that, y estaban estancados en un punto donde el 90% de las sugerencias eran correctas. Ahora basta con recordarle automáticamente “haz primero lo difícil y ordena/refactoriza sobre la marcha” y, después de la primera entrega, “revisa el trabajo realizado”, hacer que exponga los problemas pendientes, y luego meter eso en el prompt generador de guías para lanzar nuevas tareasLa iteración se volvió más rápida, pero el esfuerzo necesario para atravesar esas versiones torpes sigue siendo casi el mismo. Todavía tengo que entender qué ideas, principios o diseños encajan con la solución, qué probar después y ajustar mi modelo mental. Al final se siente como meter mucho más esfuerzo mental en menos tiempo, con apenas un pequeño ahorro en la escritura de código. Una vez que tienes experiencia, te das cuenta de que teclear código nunca fue una parte tan grande. Aunque “solo” estés escribiendo prompts y leyendo código, terminas igual de agotado o incluso más por el ciclo de iteración comprimido
Ahora vivo esto todos los días, y es desalentador y preocupante. Creo que la razón por la que estamos fusionando más código que no podemos explicar por completo es que el modelo mental que antes construíamos escribiendo código y haciendo planificación técnica colaborativa ahora se lo estamos dejando a la revisión de código.
La revisión de código no sirve para ese propósito. Aun así, creo que se le puede agregar práctica estructurada inspirada en pedagogía para equilibrar mejor la fricción y la comprensión. Estoy buscando ayuda para probar ejercicios de este tipo
La pobre UI de PR de GitHub tampoco ayuda. Hay pocas herramientas para explorar los alrededores de la codebase que no cambiaron directamente pero sí se ven afectados, y así encontrar y resaltar problemas
Lo que dice el texto original sobre preferir sistemas que hagan imposibles las condiciones de borde incorrectas en vez de manejarlas con rutas alternativas es importantísimo. El enfoque de rutas alternativas te lleva a implementar otra ruta alternativa encima de la anterior, y cada una aumenta exponencialmente la cantidad de código y, de alguna manera, siempre crea problemas nuevos. Casi se podría llamar una “ley general del diseño de sistemas”. Las rutas alternativas reducen el riesgo de falla, pero cuando la falla realmente ocurre la vuelven más compleja y más dañina. Como ingeniero de software, me gusta el nuevo entorno de programación que crea la IA. Porque Big Tech me ha creado una cantidad infinita de trabajo. Los desarrolladores humanos se volvieron un componente central de la ejecución del código y siempre tienen que estar en espera para manejar las casi infinitas excepciones difíciles no contempladas que inevitablemente van a ocurrir de vez en cuando. Ahora el ingeniero de software se parece menos a un trabajador y más a un guardia de seguridad que se pasa la mayor parte del tiempo sentado en su escritorio tomando café y solo interviene cuando aparece un problema raro
Esto sigue la línea de lo que vengo diciendo desde hace meses. Los LLM son excelentes para completar tareas, pero débiles en estética y gusto.
Hay dos tipos de trabajo. Uno es el trabajo orientado a objetivos: tienes una meta que alcanzar y no importa mucho cómo llegues a ella. La seguridad es el ejemplo perfecto. Si quieres explotar un sistema, casi no te importa si el exploit es elegante; solo quieres acceder a los planes nucleares ultrasecretos. La investigación es parecida: el código de “calidad de investigación” ya tenía fama de ser un desastre mucho antes de la era de la IA. El otro es el trabajo orientado por el gusto. Cuando agregas una función a una codebase grande, crees que el objetivo es agregar esa función, pero muchas veces no lo es. Mantener la codebase en un estado que reciba bien cambios futuros es muchísimo más importante que esa función puntual, y eso requiere gusto. La mantenibilidad y la calidad de código no son sinónimos, y la calidad de código es solo un medio; su fin es la mantenibilidad
El problema de que el LLM intente manejar incluso los casos incorrectos de forma natural es algo con lo que se ha peleado en muchas revisiones de PR. En especial, una vez que ya está escrito, es muy difícil convencer a los demás de que el exceso de verificaciones de null es perjudicial
A menos que haya un mejor modelado y un lenguaje que permita tipos suma, todavía no he encontrado una refutación universalmente efectiva contra este tipo de “parsing con escopeta”. Tal vez en realidad no sea un problema tan grande. Pero al leer y refactorizar una base de código real, siempre me ha frustrado tener que gestionar estas verificaciones innecesarias. Una vez que entran, a veces es casi imposible eliminarlas de forma segura sin antes agregar logging o una investigación amplia
Ese es justamente el núcleo de la idea de hacer imposible expresar estados no deseados
Aunque ahora nada le pase números negativos a esta función, ¿qué tan difícil sería que un cambio futuro en el código rompa esa suposición? Siempre he pensado que un error claro es lo mejor. Incluso alguien que no conoce bien el código puede ver qué supuestos hay sobre el rango válido de entradas, y deja de ser necesario considerar valores atípicos imposibles
Mi cuello de botella está en la especificación. El loop del agente ahora es un problema menos importante para mí
Si logro una comprensión clara de lo que quiero construir y lo comunico como objetivo para escribir una especificación ejecutable en el modo de planificación de Claude Code, cuando el agente pasa a la implementación por lo general salen resultados muy buenos. Pero esta estrategia efectiva me carga a mí con gran parte del peso de escribir la especificación. El agente suele resolver muy bien cada especificación, y el seguimiento basado en revisión de código normalmente toma solo 2 o 3 rondas, pero pronto se vuelve a llegar a una etapa donde hace falta otra especificación. Además, aunque el agente termine el trabajo que le dejé mientras yo no estaba y podría empezar con una especificación ya existente que no tenga conflictos porque los archivos no se pisan, no sabe que puede crear una nueva rama y arrancar. Antes de irme a dormir le digo cosas como “haz la tarea X y, cuando la completes y hagas push, empieza la tarea Y”, pero más allá de eso no avanza bien. A menudo, al comenzar Y surge una pregunta, y después de eso el agente se queda detenido durante el resto del tiempo. El último problema es la dependencia combinada con lo anterior. Por ejemplo, hoy escribí un procesador de trabajos en segundo plano y, naturalmente, los jobs de tareas posteriores necesitan ese sistema. Esto pasa bastante seguido. Para reflejar los detalles decididos durante la implementación, también hay que actualizar la propia especificación después de implementar. Aun así, ya estamos justo antes del punto en que hará falta un loop externo. El cuello de botella está casi por completo en escribir especificaciones y en la revisión de PR. Donde ese cuello de botella no importa, quiero que el agente siga avanzando. Además, creo firmemente que debemos empezar a usar herramientas que, aunque sean peores para nosotros, sean mejores para los LLM. Por ejemplo, Rust me resulta molesto porque el compilador es demasiado estricto, pero para un LLM es excelente
Ahora que construir está más automatizado, la especificación y el diseño de sistemas pueden volver a ocupar un papel principal e importante. Tal vez regresen la ingeniería y la calidad
La AI es excelente para producir soluciones decentes que técnicamente funcionan, pero es bastante débil para tener una buena visión de la solución. Sigue siendo muy útil para intercambiar ideas, explorar y profundizar la comprensión, pero escribir una buena especificación para que la implemente un LLM no es mucho más fácil que escribir directamente el código
https://www.aihero.dev/skills-handoff
/handoffes mi skill favorita nuevahttps://www.youtube.com/watch?v=dtAJ2dOd3ko
Haya agentes o no, tarjetas perforadas o intérpretes, al final programar sigue siendo programar
El mayor code smell de los LLM es que intentan “manejar todos los casos incorrectos”, y ahora hasta tratan de manejar errores imposibles. No sé por qué están tan obsesionados con eso
En Python, esto aparece mucho como poner una comprobación con
hasattrsobre un tipo en una base de código completamente verificada por tipos, aunque ese tipo ya define que la propiedad existe. ¿Por qué pasa esto? Me pregunto si es por el preentrenamiento o por el aprendizaje por refuerzo. Si es lo segundo, ojalá los labs lo corrijanEn HN esto se comenta mucho, pero todavía me sorprende cuando veo una base de código que no escribí yo —sea open source o del trabajo— y realmente hace esto bien. La mayoría de los programadores, en vez de pensar en impedir que ocurran errores y reflejar ese hecho en los datos, piensan en ir recogiendo los pedazos en el punto donde aparece el mensaje de error y arreglarlo ahí. Digo “la mayoría” porque creo que la IA actual también tiene ese problema de mentalidad. Es difícil darle hoy a una IA el nivel de comprensión que un humano tiene de una base de código al final del proceso, es decir, entender de forma global el flujo de garantías. A nivel de código crudo, esas garantías muchas veces abarcan tanto código que fácilmente revientan la ventana de contexto. Incluso intentar resumirlo en archivos de memoria trae problemas. Que exista texto sobre las garantías no significa que la IA vaya a extraer la información correcta, y a los humanos les pasa lo mismo si solo leen el código. No diría que sea “imposible” darle ese entendimiento a una IA, pero incluso si se lograra, la forma en que la IA trabaja muchas veces juega en contra de ese entendimiento. Mi solución, en general, fue renunciar a que la IA entienda esto. Normalmente convierto la solución del problema en prompts, como haría la mayoría, y si quiero hacer imposible representar estados inválidos, hago que la IA pase por el proceso de refactorización necesario paso a paso. Si es algo muy pequeño, lo hago yo mismo. Si le pides gradualmente que tipifique con más rigor código lleno de maps/diccionarios, arreglos, strings y enteros, en realidad lo hace bastante bien. No me pasó muchas veces que salga un buen diseño de un solo prompt, por más detallado que esté. Suele funcionar mejor tratarlo como dos tareas separadas. Y hay que mirar con mucho cuidado las diferencias de tipos. A la IA le encanta colar métodos como
.JustSetItAndIgnoreAllThePreAndPostConditions(string). Sospecho que hay mucho dato de entrenamiento de “un tipo bien estructurado para hacer imposible representar estados de error, al que luego llega un mantenedor y le agrega un métodoJustEffingDoItque rompe todo”. Una de las mejores defensas es poner esos tipos en su propio archivo, revisar fácilmente todos los métodos agregados y corregir al instante cualquier cosa de ese estilo. Probé llenar la documentación de advertencias sobre no hacerlo y de precondiciones y postcondiciones que debían mantenerse, pero cambió muy pocogetattren cada dataclass es una decisión rarísimaEl código es parte del entendimiento compartido y acumulado sobre un sistema de información
Si estos loops son lo que nos mantiene avanzando en medio de la ola constante de software que se nos viene encima, entonces en el nivel más alto del diseño lógico de sistemas de información todo termina siendo juicio humano y equilibrio de requerimientos de negocio. Para ajustarse a un nicho específico de una empresa o de un mercado, todos los programadores tendrán que convertirse en analistas de negocio, investigadores de mercado y empresarios. Salvo en nichos específicos donde las herramientas de IA no logren “tambalearse” bien, o cuando termine la era de los tokens de IA subsidiados y todos estos loops se vuelvan demasiado caros. Se siente como otra repetición de los sistemas expertos y las máquinas Lisp de Symbolics. Por un momento, lo que encontramos fue que no es tanto que el código en sí no pueda hacer algo, sino que la estructura organizacional de una empresa termina plasmada en el software, así que si no puedes cambiar la organización de la empresa, también hay límites para la flexibilidad del software. Los diagramas de flujo de datos y el conocimiento del dominio, el modelado del dominio y el lenguaje ubicuo pueden convertirse en el metalenguaje con el que fijamos calidad, funcionalidad y estándares y convenciones no funcionales. Hay que hacer que los “clankers” que dan vueltas en el loop cumplan los contratos de datos, comportamiento y rendimiento antes de decir “terminado”. Ahora “terminado” ya no significa solo código que compila, código que construye, código que se despliega, ni siquiera código que ya está en producción. Tiene que ser código que satisfaga los requerimientos de los usuarios, de los operadores y de quienes lo mantienen. Así que el lenguaje que se use puede acercarnos más a ser analistas de negocio y arquitectos de software que simples personas que conocen una sintaxis. ¿Será la venganza de UML y el regreso del diseño declarativo y lógico y de BDD?
La revisión ortográfica se hizo con gemma4-12b, pero no dejé que cambiara el mensaje
Sigo pensando en desde cuándo ya no necesito estar metido a la fuerza dentro del loop. Como desarrollador, realmente me encanta pulir la estructura del código, hacerlo más claro, pensar buenas abstracciones y dividirlo en módulos
Ahí encuentro disfrute, pero también entiendo que en algún punto yo me convierto en el factor limitante. Si el propósito del software es beneficiar a las personas, ¿debería seguir importándome cómo se ve el código? Ahora mismo creo que la respuesta es “sí”, pero ¿en 3 años? ¿en 10?
Si algo requiere mucho juicio y es “código que me importa profundamente”, me cuesta estar de acuerdo con la dirección que se plantea aquí. No deberíamos intentar delegar decisiones que nos importan profundamente.
Me gusta la distinción entre el bucle del agente y el bucle del harness, pero solo se debería delegar aquello que puede especificarse con precisión de antemano. En mi caso, por lo general son tareas repetibles, por ejemplo, “mira cómo se hizo X y haz lo mismo en Y”, y eso es, en esencia, predecible. Si al quitar mi juicio terminaría siendo algo a lo que yo diría “no”, entonces hay que bajar al modo de colaborar dentro del bucle del agente del que habla Armin. Y eso está perfectamente bien. Es rápido y seguro. Incluso antes de los asistentes de programación con IA, a veces entraba al equipo un ingeniero increíblemente productivo. Los colegas decían con envidia: “¡Claro, lograron hacer todo eso porque tienen a X en el equipo!”. Pero no habían vivido la maldición de tener a alguien así cerca. Si no está perfectamente alineado, avanza a una velocidad tremenda en la dirección equivocada.
No entiendo qué significa esto en la práctica. Parece solo un texto verboso que amontona conceptos abstractos diseñados para insinuar un panorama más grande, y al final se trata de dejar que la IA escriba código.
¿Así va a ser de ahora en adelante? En realidad no somos líderes de pensamiento, sino seudomaestros tratando de arrear a una banda de tontos de IA hacia la respuesta correcta, pero aun así tenemos que mistificar el rol para seguir pareciendo líderes de pensamiento, ¿sin que se note que todo eso es pura postura tecnológica?
El autor quizá podría haberlo pulido para hacerlo más conciso, pero que un lector no lo entienda en su estado actual no significa que haya mistificación.
Yo estoy viendo exactamente de qué habla el texto, tanto en el trabajo como en proyectos personales, y me asusta que alguien vea esto como “un texto verboso que amontona conceptos abstractos”. Me hace pensar que la mayoría no tiene idea de lo que está pasando ahora mismo.
En IA, la vida útil del último estado del arte es de unas 2 semanas. No logré seguirle el paso al bucle de Ralph Wiggum, y ahora siento que mejor ni haberlo intentado.
https://news.ycombinator.com/item?id=46682325