No construyas tu propia fábrica de software: es una pérdida de tiempo

Creo que tiene razón en que la fábrica de software debería surgir de algún modo. No deberías empezar un proyecto diciendo "bueno, primero debería construir una fábrica de software para hacer esto más rápido". Empieza construyendo la cosa dirigiendo un agente. Si te encuentras escribiendo lo mismo una y otra vez, mételo en una skill que deberías pensar y tratar como una macro. Cuando te encuentres desarrollando patrones claros sobre qué skill se invoca cuándo, podría ser el momento de empezar una fábrica de software que, en esencia, pone esas decisiones e información relevante detrás de una interfaz bonita.

Mi fábrica de software surgió así y para el 50-70% de las tareas más simples en las que trabajo me ahorra muchísimo tiempo y, más importante, carga mental.

Lo que saco del contenido del blog post es que hay una lucha constante del autor con su audiencia que resumo como "creo que tu esfuerzo es una tontería y no deberías hacerlo, pero no soy tu jefe así que qué más da, pero es una mala idea, pero podría ser útil, pero no deberías hacerlo".

Creo que si tienes planes para una fábrica de software (léase: algún tipo de marco conceptual para un bucle que convierte tareas en código/features), deberías probarlo. Mi opinión es que incluso si tu implementación es un fracaso o nunca la llevas más allá de una prueba de concepto, al menos has hecho algo para informarte sobre lo que hay por ahí y lo que has probado.

Mejor tener un cementerio de proyectos apenas iniciados que den profundidad a tu conocimiento en lugar de relegarte a la esclavitud de prompts porque [modelo de frontera del trimestre financiero] puede hacer Marvel + Bioshock + Ted Lasso + Command and Conquer o cualquier Consumptionslop™ horripilante que gente como Nikita Bier adora.

Me suena a que la gente entiende cosas diferentes bajo "fábrica de software".

Creo que una fábrica de software es simplemente el siguiente paso en el mantra de que todo es código.

Uno quiere escribir una descripción de feature y criterios de aceptación en la "caja" lo más difusa y con menos detalles posible.

Para permitir esto, uno crea para la fábrica acceso a información del dominio, requisitos y stack de software según lo requiera el entorno.

Y uno intenta todo esto con herramientas, documentación y procesos optimizados para la IA.

Todo con el objetivo de usar menos tokens, contexto y acelerar cada acción tomada por un agente tanto como sea posible.

Por eso hay una tendencia hacia harnesses auto-evolutivos basados en plugins que intentan automatizar esto con soluciones opinionadas.

Por lo tanto, no veo razón por la que construir herramientas para pruebas más fáciles y menor uso de tokens sea una pérdida de tiempo, especialmente porque uno aprende más y más áreas en su trabajo que puede automatizar y porque, dependiendo de tu elección de herramientas, se puede hacer sin tu intervención y uno pierde la oportunidad de experimentar si tu intervención en ese sentido mejorará la fábrica o no.

Estoy totalmente de acuerdo con el sentimiento, pero ¿está atacando a un hombre de paja o la gente realmente está construyendo "fábricas de software"? Esta es la primera vez que veo el término usado en el contexto de LLMs. ¿Cómo se vería siquiera una fábrica de software sobre un LLM?