Venía usando IA fuerte en desarrollo, pero me pasaba algo: en algunos proyectos arrancaba muy bien y en otros perdía tiempo por falta de contexto.
No era un problema de modelo. Era un problema de método.
Por eso armé esta herramienta:
La idea no es “pedile código y listo”. La idea es usar IA como compañera de desarrollo con reglas claras desde el minuto cero.
El problema real: empezar sin encuadre
Cuando una IA arranca sin encuadre, pasa lo que todos vimos:
- asume arquitectura sin validar,
- propone herramientas que no aplican,
- mezcla buenas prácticas con humo,
- y te deja una base que después cuesta mantener.
Con un start-up bien armado, el enfoque cambia: primero entender el proyecto, después decidir.
Qué cambia con este start-up
Lo diseñé para forzar un flujo simple, pero serio:
- Pregunta obligatoria de contexto: tipo de proyecto + arquitectura esperada.
- Análisis del repo real: stack, estructura, convenciones, riesgos.
- Diseño de AGENTS.md por capas: reglas útiles, no decorativas.
- Skills accionables: concretas, chicas y reutilizables.
- Validación técnica obligatoria: linter o equivalente, siempre.
Esto evita el clásico “queda lindo en markdown, pero no corre en el proyecto”.
Por qué la veo como compañera (y no como atajo)
La diferencia para mí está en esta frase:
La IA propone. El criterio técnico decide.
Si no tenés proceso, la IA te acelera errores.
Si tenés proceso, te acelera aprendizaje, ejecución y calidad.
En mi caso, esta herramienta me ordenó mucho el arranque de proyectos nuevos y me sacó fricción en algo que antes era bastante caótico: alinear documentación, arquitectura y práctica real.
Dos decisiones que para mí fueron clave
1) Mantenerlo genérico, pero no vacío
El start-up es genérico para cualquier proyecto, pero obliga a adaptar todo al contexto real. O sea: no te deja copiar recetas.
2) Meter skills para crear y sincronizar skills
Incluí guías en Skills/ para dos tareas que suelen romper consistencia:
- crear skills nuevas con estructura clara,
- y sincronizar metadatos para auto-invocación en AGENTS.
Eso baja el quilombo cuando el repo crece y ya no alcanza con “acordarnos de memoria”.
Es un proceso iterativo (y no se termina)
Algo importante: esto no es un setup que haces una vez y te olvidas.
Es un proceso vivo.
El proyecto cambia, el equipo cambia y los problemas cambian. Entonces el sistema de trabajo también tiene que evolucionar.
Por eso, para mí hay tres reglas simples:
- agregar skills cuando aparece un patrón nuevo que se repite,
- eliminar skills cuando ya no aportan valor o quedaron obsoletas,
- mejorar skills cuando la realidad del proyecto pide ajustes.
La herramienta ayuda, pero la responsabilidad sigue siendo nuestra.
No hay piloto automático.
Hay criterio, iteración y mejora continua.
Si ya venís usando IA, esto te puede servir
Si te pasó como a mí y ya usás IA para programar, este enfoque encaja muy bien con lo que conté en estos posts:
- Lo que me cambió desde que programo con IA
- Cómo cambié mi forma de programar con IA (opencode, agentes y método)
La diferencia es que acá no hablo solo de mindset. Hablo de una base concreta que podés copiar y adaptar para arrancar mejor.
Cierre
No creo en vender IA como magia.
Creo en usarla con método.
Y para eso, tener un start-up que te obligue a preguntar contexto, validar arquitectura y correr checkers desde el inicio, te cambia el resultado final.
Menos improvisación.
Más decisiones técnicas con intención.