Cómo trabajamos
Software Factory
Escribir código dejó de ser el cuello de botella. El cuello de botella es confiar en lo que se escribió. Nuestro método existe para producir esa confianza, tarea por tarea.
Una fábrica de software no es una herramienta. Es el recorrido que sigue toda tarea —siempre el mismo— para que la calidad no dependa de qué tan buen día tuvo el modelo.
El problema
Un proceso escrito no es un proceso que se usa
Casi todo equipo que trabaja con agentes tiene un documento que dice cómo debería trabajar. Y casi ninguno lo sigue, porque un documento sólo funciona si el agente lo lee y decide obedecer.
Lo comprobamos en nuestro propio producto. Existían 22 pruebas automáticas, escritas y funcionando. Nada las ejecutaba al abrir un cambio. La regla estaba escrita; el mecanismo que la hiciera cumplir, no.
Ninguno de los tres se encontró leyendo código. Los tres salieron de medir: comparar lo que el sistema decía que hacía contra lo que un número real mostraba. Eso es lo que el método obliga a hacer en cada tarea.
El recorrido
Cuatro tiempos, en orden, siempre
Toda tarea pasa por los mismos cuatro. El orden importa: cada uno existe porque saltárselo cuesta algo concreto, y lo que cuesta se paga más caro mientras más tarde se descubre.
Aislar
Nada empieza sin un ticket, y la rama de trabajo se llama como el ticket. Así el trabajo nunca se despega del tablero: cualquiera puede ver qué se está haciendo y por qué, sin preguntar.
Antes de escribir una línea se revisa qué otros cambios están abiertos sobre los mismos archivos. Dos personas —o dos agentes— editando lo mismo se descubre al final, cuando ya hay dos versiones y ninguna quiere ceder.
Y se declara la medición: qué número existe hoy y cómo vamos a saber si cambió. Si el medidor no existe todavía, construirlo es parte del trabajo, no un pendiente para después.
Garantiza que el trabajo sea rastreable y que nadie pise a nadie.
Construir
Cada proyecto tiene reglas que cuestan dinero si se rompen. En el nuestro: el consumo se cobra por resultado entregado, no por intento; una persona es un solo registro aunque aparezca en diez publicaciones; cuando se escribe en dos sistemas a la vez, el orden no es negociable.
Esas reglas viven escritas, en un solo lugar, en el lenguaje del negocio. No en la memoria de quien las descubrió la primera vez. Un agente que llega mañana las lee antes de tocar nada.
Garantiza que un cambio nuevo no rompa una decisión vieja que costó descubrir.
Probar
«Ya quedó» no es una entrega. Una entrega trae un par de números —antes y después, mismo insumo, mismo comando— o un comando que cualquiera puede volver a correr mañana y que falla solo si algo se rompió.
El «antes» se mide antes de arreglar, mientras se reproduce la falla, que es cuando es barato. Después ya no se puede volver a ese estado sin deshacer el trabajo.
Garantiza que lo que se afirma se pueda verificar sin tener que creerle a nadie.
Entregar
Subir el cambio no es terminar. La entrega cierra cuando las pruebas pasan en el servidor —no en la máquina de quien lo hizo— y cuando el cambio trae escrito qué se probó y cómo. Si las pruebas salen en rojo, eso es trabajo de hoy, no de mañana.
Nunca se desactiva una prueba para llegar a verde. «Ha de ser un falso positivo» no es un diagnóstico.
Garantiza que lo que llega a revisión ya esté en verde, y que revisarlo tome minutos.
La diferencia
Lo que se describe contra lo que se ejecuta
Aquí es donde la mayoría de los «procesos con IA» se caen. Un documento de instrucciones es una recomendación. Un mecanismo que corre solo es una garantía.
El documento de instrucciones
Portátil: cualquier herramienta lo lee. Pero depende de que el agente lo lea completo y decida seguirlo, en cada tarea, sin excepción. Es el piso, no el techo.
Los mecanismos del repositorio
Corren siempre, sin depender de la memoria de nadie. Bloquean lo que no debe pasar antes de que pase. Y viajan con el proyecto: otra computadora, otro desarrollador, un agente en la nube.
- En cada instrucción
- Detecta que empieza una tarea e impone el primer tiempo antes de que se escriba código.
- Antes de cada guardado
- Bloquea la rama principal y cualquier rama que no esté ligada a un ticket.
- Al terminar el turno
- Avisa de trabajo sin subir, o de un cambio subido que nadie verificó en verde.
Los mecanismos viven en el proyecto, no en la computadora de quien lo montó. Si el proceso depende de la configuración personal de una persona, no es el proceso del equipo.
Portabilidad
Sirve con la herramienta que sea
Las herramientas de agentes cambian cada trimestre y los modelos cada mes. Amarrar el proceso a una sola es garantizar rehacerlo. El nuestro no está amarrado: el recorrido, las reglas y el conocimiento del negocio son lo valioso; la herramienta es intercambiable.
Lo mismo aplica hacia ti. Todo vive en tu repositorio, en texto plano, sin depender de una plataforma nuestra. Si algún día trabajas con otro equipo, el método se va con el código.
Costo
La revisión, de barata a cara
Revisar cada cambio con un servicio que cobra por revisión castiga justo lo que uno quiere hacer más: cambios chicos y frecuentes. Escalamos la revisión según lo que el cambio toca, no por costumbre.
| Nivel | Quién revisa | Costo por cambio | Cuándo |
|---|---|---|---|
| 0 | Pruebas automáticas y verificación de tipos | ~0 | Siempre |
| 1 | El propio agente, sobre su cambio, antes de subirlo | ~0 | Siempre |
| 2 | Revisión de seguridad | ~0 | Si toca accesos, datos personales o cobros |
| 3 | Revisor externo especializado | alto | Sólo si entra en la zona de riesgo declarada |
| 4 | Una persona | su tiempo | Siempre al final. Publicar es decisión humana |
La zona de riesgo se declara por proyecto, por escrito: qué partes tocan dinero, datos personales o información que no se puede perder. Un cambio de textos nunca llega al nivel 3. Uno que toca cobros, siempre.
Qué hacemos
Lo que esto te permite pedirnos
La fábrica no es el producto. Es la razón por la que podemos entregar estas cosas con evidencia y en semanas, no en trimestres.
Plataformas a la medida
Sistemas web con cuentas, cobros recurrentes, panel de administración y las integraciones que tu operación ya usa.
- Cada entrega llega con el número que movió
- El código y el método se quedan contigo
Automatización de procesos
El trabajo repetitivo que hoy hace una persona a mano: sincronizaciones, reportes, publicación, seguimiento.
- Alertas que gritan cuando algo falla
- En vez de fallar en silencio y descubrirlo tarde
Asistentes conectados a tu negocio
Agentes que trabajan sobre tus datos y tus herramientas, con límites explícitos de qué pueden y qué no pueden hacer.
- No demos: sistemas en producción
- Con registro de lo que hicieron y por qué
Montar la fábrica en tu equipo
Instalamos este mismo método en tus repositorios y entrenamos a tu gente para operarlo.
- Se queda contigo, en texto plano
- Sin dependencia de nosotros ni de una plataforma
Preguntas
Lo que nos preguntan antes de empezar
¿Esto no es simplemente tener buenas prácticas?
La diferencia es que una buena práctica es una recomendación y esto es un mecanismo. Un documento que dice «siempre corre las pruebas» funciona sólo si quien trabaja se acuerda. Un mecanismo que bloquea el guardado hasta que las pruebas pasen no depende de la memoria de nadie. Nosotros descubrimos la diferencia por las malas: teníamos 22 pruebas escritas y nada las ejecutaba.
¿Funciona con la herramienta de IA que ya usamos?
Sí, y esa es una decisión de diseño, no una casualidad. El método vive en archivos de texto plano en tu repositorio, con el formato estándar que leen las herramientas de agentes actuales. Si el mes que entra sale una mejor, se cambia la herramienta, no el método.
¿Qué pasa si dejamos de trabajar con ustedes?
Te quedas con todo. El método son archivos en tu repositorio, no una plataforma nuestra a la que te suscribes. Tu siguiente equipo lo lee y lo usa igual. Lo consideramos un requisito, no un riesgo.
¿Un agente puede publicar cambios sin que nadie los revise?
No. La autonomía llega hasta dejar el cambio listo y verificado, con la evidencia de que funciona. Aprobar y publicar es siempre decisión de una persona. Ese límite no es configurable.
¿Esto hace el desarrollo más lento?
Al inicio de cada tarea cuesta unos minutos: abrir el ticket, revisar qué más está abierto, decidir qué número se va a mover. Lo que ahorra es más grande: cambios que llegan a revisión ya en verde, con la prueba de que funcionan, en vez de ciclos de ida y vuelta descubriendo problemas que se pudieron atrapar solos.
¿Sirve si mi equipo no es de programadores?
El método es de ingeniería, pero lo que produce es para cualquiera: cada entrega trae en lenguaje simple qué cambió, qué número movió y cómo comprobarlo. Si hoy recibes entregas que no sabes cómo verificar, ese es justo el problema que resuelve.
Si ya trabajas con agentes y no confías en lo que entregan, el problema no es el modelo.
Es que nada obliga a probar lo que afirman. Eso se arregla, y se arregla rápido. Media hora de diagnóstico y te digo qué le falta a tu proceso.