Posts

Verified, but not real: my software factory meets its first customer

In my previous post I built a team of blank actors: engineers that start with the same few lines of instructions and learn their jobs by email from an authority. A builder and a verifier came out of that, and a fizzbuzz went from request to signed push to PASS to report. I ended that post with three questions: what is the right size of thing for one agent to own, how does a factory add capacity, and how good must the starting point be. They were questions for a later run, on a real job. This post is about the fourth proof of concept, and that real job. I have a real problem at home: my family needs a shared list of chores, something my wife, my kid and I can all add to and tick off, and I want to host it myself on an old Android TV box I no longer use. The question for me was: can the factory, changed as little as possible, take that on, with me as the customer, more than one builder at once, and an AI in the lead's chair instead of me? As in the previous posts, I did this tog...
Post a Comment
Read more

Blank actors: a software factory team that learns its jobs by email

In my previous post I built a small software factory out of Unix mail: a builder and a verifier, each one a Unix user who gets "You have new mail", plus a post office. I finished that post with two problems still open. The verifier could only judge what the builder decided to describe in an email, because the two shared no workspace. And the roles were prompt files that I had written into the repository, so the builder and the verifier were only what I had told them to be. This post is about the third proof of concept. The question for me was simple: can a factory come out of blank actors plus an authority, instead of hard-coded roles? Every actor starts with the same few lines. It is an engineer on a team, it has an authority, and mail is how it works. What it is responsible for, it learns from the human, by email. As in the first post, I did this together with an AI agent (Claude Code). In my January post about AI (in Spanish) I wrote that I can't accept something...
Post a Comment
Read more

Building a software factory out of Unix mail

"Agentic software factory" became the phrase of 2026. StrongDM decided no human would write or review code. OpenAI shipped about a million lines in five months with a handful of engineers. Uber says about 70% of its pull requests now come from agents. The picture is always a production line: planner agents, coder agents, tester agents, reviewer agents, and engineers who design the line instead of writing code. I wanted to try one. Before building anything, though, I asked a more basic question: why would I want a factory at all, rather than a single actor that produces software? This post covers where that question took me, from first principles to two small proofs of concept built with the most old-fashioned tool I could find: Unix mail. I did this exploration together with an AI coding agent (Claude Code), in a loop of research, argument and building. Some of the best turns came from pushing back on its answers, and I'll point those out as they come. Does softwar...
Post a Comment
Read more

Por qué usar inject() en lugar de inyección por constructor puede perjudicar tu proyecto Angular

Por qué usar inject() en lugar de inyección por constructor puede perjudicar tu proyecto Angular Recientemente, he observado una tendencia creciente en la comunidad Angular: el abandono de la inyección de dependencias por constructor en favor de la función `inject()`. Aunque esta función tiene casos de uso legítimos, su adopción generalizada como reemplazo del patrón clásico introduce problemas sutiles pero significativos en la mantenibilidad y testabilidad del código.  El atractivo de inject() La función `inject()` fue introducida en Angular 14 como una alternativa para obtener dependencias fuera del contexto del constructor. Su sintaxis es innegablemente concisa: @Component({...}) export class UserComponent { private userService = inject(UserService); private router = inject(Router); } Comparado con el enfoque tradicional: @Component({...}) export class UserComponent { constructor( private userService: UserService, private router: Router ) {} } L...
Post a Comment
Read more

AI al inicio de 2026

En la actualidad trabajo como ingeniero de software para mi cliente actual. En este contexto, tengo acceso a los modelos LLM más recientes de distintos proveedores (tres, concretamente). En este post quiero compartir una retrospectiva, a la fecha, sobre cómo ha sido esa experiencia.  Para comenzar, debo aclarar que en muy pocas tareas en las que he utilizado modelos LLM he considerado aceptable permitir que el modelo realice acciones sin una revisión de mi parte. Es decir, en contadas ocasiones he hecho vibe coding. Mi lógica es simple: no puedo aceptar algo que no esté dispuesto a mantener. La experiencia de otros puede variar, y no afirmo que el vibe coding no tenga casos de uso válidos.  Respecto a cómo han cambiado las cosas, cabe mencionar que las soluciones con acceso al proyecto completo y a herramientas han sido una evolución agradable frente a las versiones iniciales que únicamente autocompletan líneas de código. El aumento del contexto disponible ha sido, sin duda, ...
Post a Comment
Read more

Mis Practicas Profesionales - Acerca de las Pruebas

 Recientemente, mis prácticas profesionales han sido puestas a análisis por mis pares y siento que deberia ofrecer un contexto y los criterios que me han guiado hasta aquí. Voy a comenzar tratando las pruebas. Aquí va: Creo que la evolución actúa como una fuerza natural sobre todo lo que hacemos. De ahí que mi práctica profesional ha evolucionado con el tiempo. Lo que voy a describir puede que deje de hacerlo o que lo adapte en un futuro. En mi experiencia pasada los productos se han desarrollado o modificado para alcanzar objetivos económicos: ya sea la realización de una ganancia o la eliminación de un gasto. Este para mí es el vector de selección natural de mis prácticas profesionales. Es el lente a través del cual me analizo en retrospectiva continuamente. Hablemos en términos simples. Hablemos de implementar una nueva funcionalidad en un producto existente. Esta nueva funcionalidad responde a una necesidad del cliente objetivo del producto. Para mí esto requiere que antes de e...
Post a Comment
Read more

Revision de Código

 La revisión de código es una actividad desarrollada por un actor diferente al autor del mismo y que es un prerrequisito para que el código llegue a usarse en producción. Esta es mi experiencia hasta ahora con esta actividad. Motivaciones La documentación al respecto no necesariamente menciona estas motivaciones. Son las que he podido ver en mi experiencia personal. Control Social La revisión de código cuando es realizada por un superior con objetivo de aprobar/desaprobar el trabajo de su subordinado es meramente una herramienta de control social. Esta motivación tiende a ser enmascarada usando otras y no aporta al producto final. Control de la Calidad La revisión de código, cuando es realizada por un par del autor con el objetivo de evaluar desde otra perspectiva, es una herramienta de control de la calidad del producto. Algunos aspectos de la calidad del código que se pueden beneficiar de la revisión son: legibilidad mantenibilidad cohesión, consistencia reducción de errores en p...
Post a Comment
Read more