¿Necesitas una fábrica de software?

Una fábrica de software es un ciclo repetible en torno al trabajo de software. Si estás construyendo una fábrica de software, el código lo suficientemente bueno para enviarse a producción aún necesita el gusto humano y la propiedad. Discutiremos esto, incluyendo si realmente necesitas una fábrica todavía.

Si es así:

• Probablemente necesitarás humanos en el ciclo desde el principio para decidir la intención del producto, el diseño del sistema (si te importa) y tu estándar de calidad.
• Revisa el código (fábrica con luces encendidas) pero sé intencional con dónde es más necesario. He descubierto que debes estar atento a dónde se rompe la contrapresión automatizada. O dónde se deben tomar decisiones de compensación en mantenibilidad.
• Apunta a que las verificaciones de calidad ocurran lo más temprano y continuamente posible. No todas tienen que serlo, pero esto incluye sistemas de tipos, pruebas automatizadas, pruebas de mutación, escáneres de seguridad y linting para reglas de arquitectura.
• Número de verificaciones != calidad. Probablemente necesitarás experimentar con qué verificaciones te dan la mejor relación señal-ruido. Prepárate para ajustar o relajar tus restricciones de manera deliberada.

Quieres construir tu fábrica para que algunos aspectos del gusto humano se codifiquen en el entorno, el agente te dé evidencia de que su trabajo es correcto y donde un humano todavía "posee" lo que se envía a producción.

¿Realmente necesitas una fábrica de software?

¡En mi experiencia, puedes llegar sorprendentemente lejos con tu arnés de codificación estándar! Es decir, Claude Code o Codex, múltiples sesiones, buenas especificaciones con verificación incorporada y restricciones. Incluso puedes lanzar un lote de issues de GitHub con criterios de implementación e involucramiento humano. Las rutinas de Claude Code y los agentes en la nube de Copilot/Codex ya te dan un ciclo programado o basado en eventos sin infraestructura personalizada.

Una fábrica vale la pena si necesitas ejecuciones repetibles y consistentes, pasar trabajo entre agentes, evitar que dos sesiones tomen el mismo issue, mantener evidencia y pausar la producción cuando las revisiones están atrasadas.

Así que empecé diciendo que una fábrica de software es un ciclo repetible en torno al trabajo de software. De hecho, podemos ver un prompt que demuestra un ciclo de fábrica muy pequeño aquí:

Lee el issue #123 de GitHub y las instrucciones del repositorio antes de cambiar el código.

Implementa solo los criterios de aceptación establecidos. No modifiques autenticación, facturación, migraciones o aserciones de pruebas existentes. Trabaja en una rama y mantén el diff revisable.

Ejecuta npm run lint, npm test y npm run build. Si una verificación requerida no puede ejecutarse, detente y explica por qué. Abre un pull request en borrador con las verificaciones que ejecutaste, los riesgos restantes y cualquier decisión que un humano aún deba tomar. No fusiones.

Un objetivo puede mantener esto en movimiento hasta que las verificaciones pasen y podamos consultar los issues de GitHub en busca de etiquetas específicas o revisar los pull requests abiertos cada mañana. La protección de rama podría imponer un límite de fusión y el humano puede permanecer en el ciclo eligiendo qué está listo, revisando y tomando las decisiones finales de fusión, etc.

Agrega una fábrica de software cuando necesites una cola de trabajo basada en eventos (por ejemplo, activadores de Slack, issues de GitHub, Linear, un backlog) para ejecutarse en un entorno aislado en la nube que maneje el triaje, la implementación y las pruebas con algo de supervisión humana explícita. Algunos terminan su ciclo con un agente monitor que observa la producción y reporta issues que vuelven a pasar por el triaje.

En mi experiencia, la fábrica se vuelve útil cuando la parte difícil es hacer que tus diferentes ejecuciones se comporten de manera consistente, pasar trabajo entre agentes y evitar que diferentes sesiones reclamen el mismo issue, preservar la evidencia y detener la producción cuando la revisión humana se está quedando atrás.

Lo que resuelve esto puede sonar un poco aburrido. Por ejemplo, Warp menciona hacer triaje de cada issue entrante en uno de cuatro estados: listo-para-implementar, listo-para-especificar, necesita-información, esperar-para-implementar, y la etiqueta es lo que activa el siguiente agente.

Esta etiqueta hace varios trabajos a la vez: es la cola, el bloqueo y, dado que una sesión solo recoge lo que está marcado como listo, es donde un humano puede estacionar cosas sin decir que no permanentemente.

En cuanto al flujo de trabajo, hay algunas similitudes y diferencias con solo usar Claude/Codex:

• Dirección: el agente necesita corrección de rumbo, puedes dar información y redirigirlo
• Notificaciones: cómo la fábrica dice que está bloqueada. Esto puede ser porque un requisito era ambiguo, comenzó algo riesgoso o necesita información humana (dirección)
• Transferencia: mover la tarea, su estado y contexto entre la fábrica en la nube/otro agente/revisor humano. Las buenas transferencias mantendrán un registro de lo que sucedió, lo que queda por hacer y por qué se necesita la transferencia.

En una buena fábrica, el humano no se limita solo a revisar y aprobar el diff final al final. Pueden dar forma al trabajo desde el principio, dirigirlo durante la implementación, pasarlo a través de una transferencia o evitar que se envíe a producción.

La verificación es donde una fábrica responsable pasa gran parte de su tiempo. Cubriremos esto más adelante.

Si decides que sí necesitas una fábrica de software, construirla no es la única opción. Levantar la infraestructura para escalar una fábrica puede ser mucho trabajo y es posible que quieras considerar comprar vs. construir. Factory.ai, Devin, Warp y HumanLayer venden partes de este ciclo.

Dónde pongo realmente mi atención

Mi experiencia diaria del desarrollo de software ha cambiado mucho en el último año. He estado hablando cada vez más de hacer mucho trabajo paralelo con agentes, avanzando hacia tener una fábrica de software con luces encendidas. Y mucha gente me ha estado preguntando, ¿qué significan realmente estas cosas? ¿Qué estás construyendo? ¿Qué tipo de proyectos usas para estas cosas? Es mucho de esto:

Así que en un día muy promedio, tengo una fábrica de software con luces encendidas más simple. Puedo tener tareas que se ejecutan en la nube. La mitad de estas tareas podrían estar trabajando en aplicaciones cliente de producción con empresas más pequeñas con las que estoy colaborando. Van a tener usuarios reales. Van a tener autenticación real, pagos, suscripciones, riesgos reales importantes con los que debes tener cuidado. No puedes simplemente decir, oye, agente, ve y haz esto sin tener pruebas, restricciones y controles de calidad.

Podría trabajar en mis proyectos de código abierto. Podría estar creando sitios complementarios para mis libros. Podría estar trabajando en herramientas. Podría estar creando mis propias aplicaciones. Y todos estos son tipos de aplicaciones muy, muy diferentes en las que estoy trabajando. Y a veces lo único que tienen en común es la herramienta que estoy usando para trabajar en ellas, ¿verdad? Tal vez estoy trabajando en una migración. Otras veces, podría estar haciendo trabajo de funcionalidades realmente importantes. Y el radio de explosión del trabajo también podría ser muy, muy diferente.

Así que, a medida que comienzas a pensar en llegar a un lugar donde hacemos cada vez más trabajo en paralelo, tratamos de mejorar la velocidad, tratamos de mejorar la productividad y tratamos de mejorar la autonomía, lo que significa llevar el sistema a un lugar donde confiemos más en él, tienes que pensar en cuáles son los lugares que requieren absolutamente revisión de código humana, aporte humano.

Y gran parte de eso será necesario desde el principio, ¿verdad? Cuando estás definiendo tu especificación, tus requisitos, ¿cómo será el diseño del producto? ¿Cuál será la intención del producto? Y luego, ¿cómo estás verificando que los agentes realmente han hecho el trabajo correctamente? ¿Cómo estás verificando que no han roto el sistema existente que estaba en su lugar? ¿Cómo te aseguras de que cumple con tu estándar de calidad?

Y así, generar código no es necesariamente la parte que más te debe preocupar. Con suficiente contexto, los agentes pueden escribir la implementación, ejecutar las pruebas, inspeccionar fallas y revisar el código por nosotros. Necesitamos llegar a un lugar donde sintamos que hay suficiente gusto humano codificado en el entorno para poder confiar en lo que se está construyendo, para que nuestra atención humana pueda centrarse en los lugares donde más se necesita.

Ahora, hay resistencia de algunas personas que dicen: "oye, no creo que puedas simplemente automatizar todo esto". No es que estemos automatizando todo, ¿verdad? Pero dado el volumen de código que se está generando, no creo que sea realista que los humanos lo lean todo, especialmente cuando no estamos construyendo cohetes la mayor parte del tiempo, ¿verdad? Estamos construyendo UI, estamos construyendo aplicaciones full stack.

Nuestro juicio, nuestro gusto, se centra mejor en los lugares donde más se necesita. Como, ¿cuáles son las partes más riesgosas de los sistemas? ¿Dónde necesitamos aplicar el gusto humano? Y eso puede ser en el front end. Puede ser en cómo funciona el sistema. No tiene que ser el 100% del mismo.

Mi ancho de banda cognitivo no escala con los agentes

La realidad es que, sí, ahora podemos lanzar docenas, cientos, miles de agentes en paralelo, pero tu propio ancho de banda cognitivo no escala de la misma manera. Esto puede alimentar una deuda cognitiva o de comprensión de la que he hablado antes.

Si recuerdas hace solo cinco o diez años, había mucha discusión en la comunidad de ingeniería sobre el cambio de contexto y su costo. Hablábamos de cómo la gente odiaba cuando un colega o alguien se acercaba a tu escritorio cuando estabas en medio de una tarea. Luego te tomaba mucho tiempo volver a tu estado de flujo porque tenías que ponerte al día en términos de, ¿dónde estaba? ¿Qué estaba haciendo? Incluso si tenías un poco de residuo allí, todavía te tomaba tiempo.

Ahora estamos cambiando de contexto incluso más que antes. En un día cualquiera, si estoy trabajando fuera de una fábrica de software, puedo estar trabajando en cinco o diez proyectos diferentes con agentes al mismo tiempo, o cinco o diez funciones diferentes en un solo proyecto a la vez. Puedo tener cinco o diez sesiones diferentes, se podría decir.

Eso significa que tengo que ser capaz de mantenerme al tanto de al menos algunas de ellas. Es posible que pueda aumentar la autonomía que le doy a algunas tareas si confío en que he definido la tarea lo suficientemente bien, he definido el resultado, cómo va a verificar que está bien hecha. Pero luego habrá tareas en las que quizás no me sienta necesariamente así y haya más riesgo o más matices involucrados. Voy a tener que prestar atención.

Considera optimizar la fábrica de software para tu revisor. Dado que cada uno de esos enfoques aún dirige su salida a la atención de una sola persona, debes preguntarte cuánto más barata está haciendo la fábrica las decisiones que aún tienes que tomar.

Un error de proyecto equivocado

Recuerdo cuando he estado trabajando en múltiples proyectos paralelos con mis agentes, y ha habido momentos en los que accidentalmente he hecho cosas como, tal vez estaba trabajando en una aplicación web donde quería agregar un modo oscuro, y tenía en mi cabeza, bueno, así es como debe verse la forma de esto. Pero accidentalmente fui a la sesión de un proyecto diferente y comencé a poner ese mismo prompt.

Así que comencé a implementar el modo oscuro para algo que absolutamente no lo necesitaba. Y puedo cometer ese error. No quiero que mi fábrica de software cometa ese tipo de error.

Debes pensar en esto realmente en términos de un sistema. Estás tratando de codificar una cultura de ingeniería de software, una cultura de equipo, en un sistema para que tenga esos mismos tipos de comportamientos, para que tenga una propiedad que pertenezca a algún lugar, para que alguien siga siendo responsable de lo que sucede, y estés siendo muy explícito sobre cómo piensas acerca de esas cosas.

Cuando el verde es engañoso

Incluso en estos sistemas, debes tener mucho cuidado, ¿verdad? Muchos de nosotros hemos visto que cuando le has pedido a la IA que te ayude a pasar una prueba, como una prueba de programación, una prueba unitaria, puede cambiar la prueba unitaria para satisfacer esa condición, o puede cambiar la lógica del código para pasar esa condición. Eso no significa que realmente haya seguido tu intención para alinear tanto el comportamiento funcional como lo que se suponía que la prueba debía probar, ¿verdad?

El hecho de que una fábrica de software muestre que todo está en verde no significa que realmente esté en verde, especialmente al principio cuando estás configurando estas cosas. Necesitas prestar mucha atención para asegurarte de que tus verificaciones, tus comprobaciones, todas estén configuradas de la manera correcta. Estén haciendo lo que esperas que hagan. No quieres que sean engañosas.

No quieres una situación en la que tenías pruebas que decían: "oye, en realidad, he ido y cambiado qué proveedores de autenticación son compatibles". Me pediste que agregara GitHub, por ejemplo, como proveedor de autenticación, pero "oye, mi UI solo tenía espacio para tres, así que he ido y eliminado uno de los otros". Y "oye, por cierto, ese resultó ser uno que tus clientes realmente querían". Así que solo debes ser muy explícito sobre cómo quieres que funcionen estos sistemas.

Por cierto, la seguridad también es muy importante y si tu fábrica lee entradas no confiables como un issue de GitHub o un mensaje de Slack, podría ser adversarial e incluir problemas como ataques a la cadena de suministro. Algunos productos en torno a las fábricas de software, como Vercel Sandbox/AI ADK Factory, ejecutan sus agentes en entornos aislados que contienen solo los secretos que necesita una tarea. De esa manera, una ejecución comprometida no puede acceder a lo que el trabajo no necesita. Tu defensa termina siendo en capas.

¿Qué proyectos antiguos merecen otra vida?

También creo que una gran parte de cómo trabajamos hoy en día es decidir qué debería existir. Si recuerdas hace muchos años, antes de la IA, había tantos proyectos de ingeniería de software abandonados, tantos proyectos de fin de semana abandonados, proyectos personales que simplemente no se lanzaban porque no teníamos tiempo para terminarlos. No teníamos el ancho de banda para priorizar sacarlos porque no eran tan importantes para nosotros o no podíamos encontrar el tiempo.

Ahora es bastante trivial para nosotros completar esos proyectos, pero entra en juego la misma pregunta de juicio humano. ¿Merecen esos proyectos existir? ¿Deberían lanzarse? Porque los pones en el mundo e incluso si tiene solo cinco usuarios, tal vez tengas que mantenerlo. Tal vez ahora tengas un estándar de calidad que quieras mantener.

Sé que he tenido tantos proyectos de GitHub a lo largo de los años en los que ahora que tengo un agente, lo primero que hago es lograr que la cosa compile. Porque, por supuesto, lo clonas y ahora no compila porque todas las dependencias han cambiado. La mitad de las cosas están desactualizadas o tienen vulnerabilidades de seguridad por todas partes, así que tienes que actualizarlo.

Luego tienes que agregar pruebas si no tenías pruebas para saber que ese comportamiento al menos va a estar allí si estás actualizando el proyecto de alguna manera, o si lo estás migrando a un lenguaje o marco más moderno o algo así.

Luego empiezas a preguntarte, bueno, tal vez, un ejemplo tonto, pero tal vez usé Twitter Bootstrap en el pasado para esto, pero ahora todo el mundo usa Tailwind y shadcn, así que tengo que reimplementar la UI. Y lo que notarás es que de repente esto te está tomando más tiempo, ¿verdad? Sí, el agente puede hacer gran parte de esto más rápido, pero ahora tienes que tener en cuenta el sentido del producto, el gusto y todas estas cosas.

Todavía te preguntas, bueno, ¿para quién es esto? ¿Tiene mercado? ¿Es para mí? ¿Es para otras personas? Si lo estoy poniendo en el mundo, ¿seguirá siendo tan interesante dado que ahora cualquiera puede crear estas cosas tan rápido?

Así que creo que esa pregunta humana de si estas cosas merecen existir, ¿cómo incorporamos nuestro gusto y juicio? Siento que esas cosas siguen siendo extremadamente importantes. Ahí es donde ese recurso escaso de la atención humana realmente entra en juego. En el pasado, solo teníamos un número finito de horas en el día. Teníamos reuniones. Teníamos que presupuestar tiempo para el diseño y la codificación, etc.

Ahora que tenemos agentes para ayudarnos, creo que realmente debes ser muy explícito sobre dónde estás gastando tu tiempo y por qué.

Qué sucedió cuando construí una de muestra

Así que voy a hablar sobre la ejecución de la fábrica de 82 minutos. La gente me ha estado preguntando durante bastante tiempo: "¿Cómo construyo una fábrica de software?" O "Estoy acostumbrado a usar Claude Code o Codex. ¿Cómo evoluciono mi configuración para usar una fábrica de software?"

Así que lo primero que he estado diciendo es: "Puede que estés bien. Tu trabajo puede estar totalmente bien sin necesidad de una fábrica". Pero quería darle a la gente una configuración de referencia que puedan consultar. Así que lo que armé es un repositorio llamado Factory que puedes ir a ver. También armé una aplicación de demostración y un taller.

Ahora, durante los últimos dos años, mi aplicación de demostración para muchas cosas ha sido una aplicación de películas. Soy un gran fanático de las películas. Me encanta ver películas. Veo películas todo el tiempo, y tengo una aplicación de demostración, que realmente comienza como una aplicación de películas muy simple. Y lo que quiero que la fábrica pueda hacer es implementar una serie de funciones. Hay algunas funciones diferentes. Quiero una función de favoritos. Quiero que pueda hacer búsquedas, y tal vez también quiero un tema oscuro, ese tipo de cosas.

Así que mi fábrica comienza a trabajar con estas cosas. Puedes ver la implementación. Uno de los beneficios fue detectar problemas reales. Estos problemas pueden no haber sido cosas que hubiera detectado si solo le hubiera pedido una implementación de una sola vez.

Tal vez alrededor del minuto 60, estaba sintiendo: "Vaya, esto va inusualmente lento". Le pregunté a mi arnés usando la fábrica: "¿Por qué van las cosas lentas?" Dijo: "Esto está totalmente bien. Todos los verificadores todavía se están ejecutando".

Podrías haber esperado que las tareas individuales tomaran 10 minutos, 15 minutos, 20 minutos, pero pueden tomar de dos a cuatro veces más una vez que comienzas a incluir verificación, reintentos, comprobaciones del navegador, revisión humana, cualquiera de esos retrasos adicionales.

Creo que estos pueden acumularse para lograr una mejor calidad y una mejor confianza en el sistema. Desde una perspectiva de medición, podrías observar métricas como el costo por PR fusionado y la vida útil del código como métricas de deuda de comprensión.

También debes pensar en qué es un retraso útil versus la sobrecarga de la fábrica. Los verificadores, en mi caso, detectaron algunos problemas reales. Un poco de tiempo se invirtió quizás en producir la evidencia que quería. Parte de ello fue la sobrecarga en la ejecución de la fábrica. Realmente no pasé tiempo optimizándolo, pero una fábrica que solo ejecuta muchas comprobaciones que no encuentras valiosas no significa que sea de alta calidad.

Quieres estudiar cómo, para cualquier verificación repetida, ¿son irrelevantes? ¿Son ruidosas? ¿Están haciendo el sistema más seguro?

La verificación necesita un presupuesto

La forma en que pienso sobre el presupuesto para la verificación, esto es básicamente de lo que estamos hablando. Estamos hablando de un presupuesto de verificación. Pienso en ello de la misma manera que históricamente he pensado en los presupuestos de rendimiento.

Habrá ciertos tipos de comprobaciones que puedes ejecutar al principio de tu ciclo de vida de desarrollo de software, y habrá algunas cosas que son tan pesadas, pero que ofrecen tanto valor, que querrás ejecutarlas más tarde. Hay algunos tipos de comprobaciones rápidas, como el linting, por ejemplo, la verificación de tipos. Estas son comprobaciones relativamente rápidas que puedes ejecutar al principio.

Nuestro conjunto completo de pruebas se puede ejecutar más cerca de justo antes de que se esté armando un PR en borrador o después de eso. Eso puede incluir pruebas de mutación, pruebas de navegador, comprobaciones de seguridad, cualquier cosa así.

Creo que no necesariamente quieres reemplazar estas con solo resúmenes. Quieres pruebas reales, pero solo debes asegurarte de que estás presupuestando para ellas en los lugares correctos porque no quieres ralentizar tu ciclo de desarrollo. Ciertamente nunca quiero ralentizar mi ciclo de desarrollo. Tener un ciclo de iteración rápido es importante para mí, pero también quiero tener esos controles y equilibrios.

Cuando una ejecución no se envía

Gran parte de lo que he escrito anteriormente se refiere a las comprobaciones.

En su fábrica de software, Vercel marca cada ejecución de agente como "éxito", "defectuosa", "bloqueada" o "manual" y solo "éxito" se envía a producción. El resto reingresa al sistema. He estado pensando en las ejecuciones en términos similares.

"Defectuosa" aquí significa que se implementó lo incorrecto o tal vez no tenía contexto completo, por lo que eso debe solucionarse. Bloqueada significa que al entorno le faltaba una credencial, por lo que debes proporcionarla. Manual es un límite que la fábrica aún no puede cruzar.

Dos de las tres cosas aquí pueden tener soluciones mecánicas y la última se trata de confianza.

Si bien esto es excelente, lo que la clasificación no te muestra es el costo. Volviendo a mi implementación de fábrica con la aplicación TMDB, el buscador rápido sin rechazos tomó 7 minutos. Favoritos, con dos rechazos y una decisión humana en el medio, tomó 56. Misma fábrica. Por lo tanto, emparejaría la taxonomía con el tiempo por etapa, de lo contrario, sabes que una ejecución volvió defectuosa sin saber cuánto te costó descubrirlo. La otra cosa que arreglaría es la transferencia en el límite: mi fábrica de muestra detuvo el primer issue y lo movió a fábrica:necesita-información, lo cual fue correcto, pero no sabía dónde poner mi respuesta. Una ejecución manual no termina cuando la fábrica se detiene, sino cuando el humano sabe qué hacer a continuación.

La autonomía no es una configuración única

Escribí hace un par de semanas un artículo sobre autonomía agentiva y cómo pensar en la autonomía porque la autonomía no va a ser una configuración única para cada proyecto.

La verificación te compra confianza, y te compra la capacidad de otorgar más autonomía a tus agentes. Entonces, si, por ejemplo, estoy trabajando en un cambio no trivial, pero tengo una serie de comprobaciones, todo se verifica correctamente, y tal vez lo he comprobado yo mismo manualmente. La próxima vez que vaya a hacer una tarea como esa en el mismo proyecto, tal vez me sienta cómodo dándole al agente un poco más de autonomía.

Eso es lo que piensas cuando construyes estas fábricas de software. Tu verificación cambiará con el riesgo. Tu objetivo es la mejor relación señal-ruido. No solo quieres tener una gran lista de verificación que estés ejecutando.

La función que tuve que reaprender

Había una función que había estado posponiendo en un día en el que había estado usando múltiples sesiones con Claude, y estaba trabajando en algunos proyectos diferentes a la vez, algunas funciones diferentes a la vez por proyecto. Y entonces Claude había implementado la función en la que estaba trabajando. Parecía que las pruebas estaban pasando. No había puesto mucho pensamiento en la verificación, pero las pruebas pasaron, y pensé que funcionaba. Lo fusioné.

Y esta era una función de favoritos. Pensé que esto era bastante bueno. Intenté revisarlo en el navegador. Parecía que estaba bien, pero un par de días después, en realidad volví al código porque había algunos ajustes que pensé que podría hacerle.

No quería simplemente pedirle a mi agente que hiciera los cambios, porque era una forma sutil en la que funcionaba. Tocabas el ícono y no mostraba el efecto correcto al tocarlo, así que quería ajustarlo. Quería entender cómo funcionaba para poder guiar a mi agente correctamente.

Volví al código y no podía explicarte cómo funcionaba la función. Este repositorio era mío, ¿verdad? Había aprobado el cambio. Entendía cómo funcionaba gran parte del repositorio, pero mi comprensión no había seguido el ritmo de todo el código que se había ido acumulando.

Lo que no logré asimilar fue cómo funcionaba realmente esta función que se había agregado, cómo funcionaba la interfaz de usuario, cómo funcionaba el efecto en ella. Tuve que rehacer esta función y, paso a paso, preguntarme: "¿Cómo funciona esto? ¿Cómo puedo entenderlo?".

Lo que el trabajo paralelo le hace a la comprensión

Cuando estás haciendo trabajo paralelo, esto amplifica el problema general, y se amplifica aún más cuando lo haces en una fábrica de software. Cuando estás haciendo cinco o diez sesiones, crean mucho más que un simple problema de volumen de revisión. Crean varios modelos mentales que pueden terminar enfriándose bastante mientras trabajas en otra cosa.

Históricamente hemos hablado de los desafíos del cambio de contexto, y tan pronto como el chat se compacta, rechazas algunos enfoques, pruebas cosas diferentes, estás colaborando con el agente, vas a tener dificultades para recordar todo lo que sucedió en tu sesión.

Puedes desplazarte hacia arriba, y a medida que se ha ido compactando, no vas a tener todo allí, y no vas a poder almacenarlo todo en tu cabeza. El código a menudo preserva una decisión que se tomó, pero no el porqué se tomó esa decisión.

Esto es algo que creo que puede ser un aprendizaje útil para ti, donde es importante considerar pedirle a tu agente que realmente almacene información sobre su trayectoria, o lecciones interesantes sobre cómo abordó un problema, para que puedas consultarlo más tarde.

Esto puede o no ser algo que decidas comprometer en un repositorio. Puedes mantenerlo local si quieres, puedes compartirlo con un equipo si quieres, pero puede ser algo que se pueda consultar más adelante. En lugar de depender de que tal vez esté en una sesión, o de que tal vez lo recuerdes después.

¿Qué produce realmente?

@threepointone y @bentlegen publicaron algunas opiniones sobre las fábricas de software con las que estaba muy de acuerdo:

Es fácil fascinarse con la maquinaria del hacer, optimizar la maquinaria y olvidar lo que se suponía que debía producir. Si tu fábrica produce principalmente una fábrica mejor, has construido un software cuyo producto es él mismo.

Creo que invertir en el ciclo está bien y se acumula. El fracaso ocurre cuando el ciclo se cierra, cuando todo lo que produce la fábrica es consumido por la fábrica y nadie fuera notaría si la apagaras. La prueba que aplicaría es la atracción. Algo externo tiene que estar pidiendo la mejora. Si no puedes nombrar quién está tirando, estás puliendo.

La propiedad no desaparece

Hay un principio más amplio debajo de todo esto.

El porcentaje de código escrito físicamente por humanos puede caer drásticamente. No creo que la propiedad humana tenga que caer con él.

• Alguien todavía elige el problema.
• Alguien todavía elige la arquitectura.
• Alguien todavía establece el estándar de calidad.
• Alguien decide qué señales de verificación merecen confianza.
• Alguien decide cuándo la evidencia es suficiente para lanzar.

Y cuando el sistema resultante falla, "el agente lo escribió" no es una excusa válida. Es por esto que no creo que el futuro de la ingeniería de software se describa mejor como humanos saliendo del ciclo. En cambio, el juicio humano se está reubicando.

Deberíamos sacar a las personas de las partes del ciclo donde las máquinas pueden producir señales más fuertes, más rápidas y más deterministas. Al mismo tiempo, deberíamos concentrar a las personas en los lugares donde el contexto, el gusto, el riesgo y la propiedad a largo plazo importan más.

Las mejores fábricas de software no se definirán por lo completamente que eliminen la participación humana.

Se definirán por lo inteligentemente que la coloquen.

Mantén el juicio humano en la corriente arriba de la intención, la forma del sistema y el estándar de calidad. Revisa el código donde la contrapresión automatizada se vuelve débil o las consecuencias se vuelven subjetivas. Empuja cada señal determinista lo más temprano y continuamente posible hacia el ciclo. Aprieta y relaja las restricciones deliberadamente a medida que el sistema gana o pierde confianza.

Un humano todavía tiene que ser dueño de lo que finalmente se envía como código. El código lo suficientemente bueno para enviarse todavía comienza con alguien a quien le importa si debería existir.