yeiniel

"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...

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...

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, ...

 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...

 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...

This entry is going to be brief. It is about a not so pleasant experience creating a package for Debian. In my work I have packaged several projects for Debian and this week I try to do it for a project based on QT. As I had already packaged other QT projects, I download one of them to copy/paste part of the contents of the debian/directory . At the time of executing the command debuild -b -uc -us  it fails me during the execution of the dh_install helper. This is because the helper executes a binary that has just been compiled.  After a lot of searching the Internet I find this comment. Basically if the files debian/*.dirs or debian/*.install are executable the helper dh_install will execute them and guess what was the first line of debian/install : the binary that was compiled as part of the package. And it turns out that this file when downloaded from the internet the OS for some reason put this bit. The documentation of the helper dh_install gives an idea in ...