PRIVATE TOOLING
Tooling para workflows de ingeniería asistida por IA
Herramienta personal para incorporar agentes y automatización sin perder control sobre Git, validaciones, estado y decisiones humanas.
Contexto y problema
Utilizar agentes para desarrollar software introduce una pregunta que va más allá de generar código: ¿cómo automatizar trabajo sin perder control sobre lo que está ocurriendo?
En un workflow real existen repositorios, branches, archivos modificados, tests, resultados de CI y decisiones pendientes. Sin una representación clara de ese contexto, un cambio técnicamente válido puede resultar difícil de auditar o de continuar. Esta herramienta personal surgió para experimentar con ese problema dentro de mi propio proceso de desarrollo.
Mi responsabilidad y restricciones
Diseñé y desarrollé personalmente el tooling para coordinar tareas asistidas por agentes alrededor de workflows de Git, incluidos escenarios con múltiples repositorios. El propósito es mantener explícitos el estado del trabajo, la evidencia y las decisiones humanas.
La autonomía está limitada de forma deliberada. Analizar una situación y proponer una continuación son capacidades distintas de tener autorización para ejecutarla. La herramienta permanece en evolución activa dentro de mi entorno personal de ingeniería.
Evidencia y contratos entre etapas
El enfoque evidence-first exige algo más que una declaración de tarea completada: estado de Git, archivos producidos, tests o resultados de CI que puedan comprobarse. Los agentes aportan análisis y trabajo asistido; los scripts y las validaciones deterministas permiten contrastar resultados con condiciones explícitas.
El diseño contract-first define qué información necesita una etapa, qué resultado puede producir y qué condiciones deben cumplirse para avanzar. Esto reduce la dependencia de instrucciones informales entre agentes y scripts, sin convertir una respuesta del agente en evidencia suficiente.
En escenarios multi-repo importa comprobar qué repositorio cambió y qué trabajo sigue pendiente. Que un comando termine correctamente no demuestra por sí solo que el conjunto esté preparado para la siguiente operación. Utilizo testing y harnesses para simular situaciones y comprobar comportamientos de forma reproducible.
Persistencia y reconciliación
La persistencia permite retomar trabajo sin depender exclusivamente del contexto conversacional de un agente. Esa continuidad requiere reconciliar lo registrado con el estado actual de Git y con las validaciones disponibles.
Una afirmación anterior no sustituye la observación del estado presente. Si el trabajo cambia, la evidencia previa puede dejar de ser válida y necesitar una nueva comprobación. Conservar un resultado y comprobar que sigue vigente son responsabilidades diferentes.
Gates humanos y límites de autonomía
Determinar la próxima acción segura no significa ejecutarla automáticamente. El tooling puede analizar estado, comprobar condiciones y proponer qué debería ocurrir después; determinadas transiciones requieren una decisión humana explícita.
Los gates mantienen visibles las decisiones sensibles. Una validación automatizada no concede permiso para avanzar y una propuesta no equivale a una acción realizada. Parte del workflow puede analizarse y automatizarse, mientras la responsabilidad de autorizar esas decisiones permanece en la persona.
La evidencia se considera junto con su estado y su vigencia: una declaración previa debe contrastarse con lo observado. Si dejó de ser válida, corresponde volver a validar y reconciliar antes de proponer una continuación.
Validación, resultados y alcance demostrado
La implementación cuenta con contratos, estado persistente, reconciliación y suites automatizadas para comportamientos críticos, con respaldo privado de tests, harnesses y CI. Esas pruebas han permitido detectar problemas de límites entre repositorios, validaciones insuficientes y estados considerados completos sin evidencia suficiente.
La utilizo como apoyo en mi propio proceso de desarrollo. Ese uso no demuestra operacionalmente cada capacidad implementada: un comportamiento ejercitado mediante pruebas internas tiene un alcance distinto del que se acredita en un flujo de trabajo real.
Algunas capacidades siguen pendientes de habilitación o de demostración operacional. La integración de una capacidad y el éxito de sus pruebas no permiten presentarla como una operación real ya realizada. El resultado actual es un laboratorio de ingeniería de workflows con control humano y autonomía limitada.
Qué demuestra
- Diseñar workflows asistidos por agentes con contratos y condiciones comprobables.
- Integrar Git, testing y CI en la evaluación de evidencia y el control de cambios.
- Abordar persistencia y reconciliación para continuar trabajo con estado cambiante.
- Delimitar automatización e intervención humana con criterio de ingeniería.
Tecnología y evidencia
Tecnología y prácticas: Bash · Git · testing · harnesses · CI · integración con agentes · contratos · persistencia · reconciliación.
El relato se apoya en evidencia privada de implementación, pruebas y ejecuciones reproducibles. El diagrama público comunica principios de ingeniería y sus límites; su carácter conceptual no lo convierte en evidencia de operación de cada capacidad.
Nota de privacidad
PRIVATE TOOLING
El portfolio expone el problema, los principios técnicos y una representación derivada. El código y la implementación interna permanecen privados.