En 2026 surgieron varias propuestas excelentes de kits para estandarizar el trabajo con agentes de IA y desarrollo moderno: Spec Kit de GitHub, Development Kit de Anthropic, kits internos de otras grandes empresas. Son esfuerzos serios, públicos, con comunidad. Aun así, en Steply, elegimos construir nuestro propio kit y styleguide. Este post cuenta por qué, en qué momento esa decisión tiene sentido para una empresa, y en qué momento adoptar un kit ya hecho es claramente el mejor camino.
El objetivo no es vender el Steply Kit, es compartir el razonamiento. Si estás pensando "voy a adoptar Spec Kit / Development Kit / otro" o "voy a construir el mío", los argumentos aquí van a ayudarte a decidir con claridad.
Qué es un "kit", al final
Un kit, en este contexto, es un paquete de convenciones, templates, prompts, comandos, flujos y herramientas que estandariza cómo un equipo trabaja con agentes de IA y desarrollo de software. Incluye cosas como: formato de spec, estándar de commit, prompts de sistema reutilizables, comandos slash (/review, /test, /docs), playbooks de PR, estándares de estructura de proyecto, reglas de revisión automatizada.
El valor de un kit está en la previsibilidad: cualquier persona del equipo entrega en el mismo estándar; cualquier agente recibe el mismo briefing; cualquier cliente ve la misma calidad. Sin kit, cada proyecto es una improvisación y la empresa no escala calidad.
Los kits ya hechos que evaluamos
Spec Kit (GitHub): enfoque en Spec-Driven Development con un formato estandarizado de spec consumido por copilots y agentes. Fuerte para la alineación entre producto e ingeniería. Development Kit y herramental de Anthropic: enfoque en el ciclo de trabajo con Claude Code, estándares de agente, evals. Otros kits abiertos o semiabiertos de grandes empresas con piezas reutilizables.
Todos tienen cualidades reales. Son esfuerzos públicos, mantenidos por equipos serios, con comunidad. En muchos casos, adoptarlos por completo sería la decisión correcta.
Por qué aun así construimos el nuestro
Cinco razones pesaron, en orden de impacto.
1. La cultura de entrega es un diferencial competitivo, no una commodity. La forma en que Steply entrega, del briefing a la revisión final, es parte de lo que nos contrata. Adoptar un kit ya hecho por completo significa que nuestra entrega se vuelve indistinguible de cualquier otra empresa que adopte el mismo kit. Construir un kit propio ancla la forma de trabajar en nuestra identidad y permite afinar lo que hace la diferencia en nuestro público.
2. Los estándares ya hechos optimizan para el "caso medio" de la comunidad. Los kits abiertos tienen que servir desde el hackathon hasta el banco multinacional. Eso es una virtud para la adopción, pero fuerza concesiones. Nuestro kit puede optimizar para nuestro perfil de cliente, nuestro stack predominante, nuestros procesos. Cada gran conveniencia tiene un costo de generalidad.
3. La velocidad de evolución depende de la propiedad. Cuando algo necesita cambiar, un nuevo estándar, un nuevo prompt, una nueva regla, en un kit propio lleva minutos. En un kit abierto, es un PR, un debate, una espera, tal vez ser rechazado, tal vez quedar en un fork divergente. Para una empresa que ajusta su proceso continuamente, poseer la herramienta es innegociable.
4. Integración profunda con el ecosistema interno. Nuestro kit conversa con nuestra harness de agentes, nuestro pipeline de evals, nuestra observabilidad, nuestros templates de cliente. Cada pieza del kit está diseñada para encajar en ese stack. Un kit externo pediría adaptación continua y pérdida de cohesión.
5. Conocimiento que se queda en casa. Construir el kit obliga al equipo a articular cada decisión, registrar cada estándar, justificar cada convención. Ese proceso, en sí mismo, es entrenamiento. Las personas que construyen el kit entienden el porqué de cada pieza, y el conocimiento queda internalizado, no delegado a un README externo.
Dónde adoptamos cosas ya hechas
Construir un kit propio no es rechazar todo. En capas donde el estándar de la comunidad es claramente superior y estable, lo adoptamos. MCP para tools de agente, sin dudar. OpenAPI para la descripción de API REST. JSON Schema para validación. Conventional Commits para el mensaje de commit. Estándares de SDD abiertos para la spec inicial, con extensiones nuestras. SDKs oficiales de los proveedores de LLM. Donde existe un estándar útil y neutro, lo usamos; donde la decisión es cultural o de identidad, construimos.
Qué entra en el Steply Kit
El kit cubre cinco ejes. 1. Templates de spec: un formato estandarizado de briefing, con secciones obligatorias y opcionales, listos para ser consumidos por agentes de codificación. 2. Prompts de sistema: para agentes de cada rol (revisor, redactor, generador de pruebas, especialista en legacy), con tono, principios y formato de salida estandarizados. 3. Comandos slash: comandos reutilizables dentro de nuestro entorno de trabajo (/review, /spec, /eval, /deploy, /audit), cada uno disparando un flujo predefinido. 4. Styleguide: voz, vocabulario, formato, reglas de comunicación visual y textual, del código al Slack interno al deck para el cliente. 5. Playbooks operativos: cómo conducir un kickoff, cómo hacer un code review, cómo entregar un release, cómo gestionar un incidente. Cada playbook está versionado y se revisa a intervalos regulares.
Styleguide: voz e identidad
El styleguide es la parte más subestimada. Sin styleguide, cada PR, cada correo, cada conversación con el cliente tiene un tono diferente. Con styleguide, hay coherencia entre canales. Nuestro styleguide define: persona del verbo (tercera, plural, o primera por canal), uso de jergas técnicas, nivel de detalle esperado en cada formato, reglas de adjetivación ("no exageres", "evita superlativos"), formato preferido en markdown, estándar de emoji (parquedad consciente), y ejemplos comentados de "cómo suena Steply".
Esto se trata como código: tiene repositorio, tiene PR, tiene revisor, tiene versión. Cada cambio es discutido y documentado. Sin un dueño claro, el styleguide se vuelve ficción que nadie sigue.
Cuándo construir el propio NO tiene sentido
Sé honesto. Construir un kit propio no vale la pena cuando: (a) el equipo es pequeño y todavía no tiene un estándar para extraer; (b) el stack varía mucho entre proyectos sin consistencia; (c) no hay nadie para mantener el kit a lo largo del tiempo (un kit huérfano se pudre); (d) el kit abierto cubre el 95% de lo que necesitarías y el 5% restante es cosmético.
Para la mayoría de las empresas pequeñas que empiezan ahora, adoptar Spec Kit o similar por completo es la decisión correcta en el corto plazo. Construir viene después, cuando la identidad de la entrega ya está lo suficientemente clara para que el kit refleje una forma de trabajar madura.
El costo real de mantener un kit propio
Honestidad: un kit propio tiene un costo recurrente. Necesita un dueño, necesita tiempo para evolucionar, necesita onboarding interno, necesita ser revisado. A cambio, compone: cada mejora de proceso se vuelve mejora del kit, que se vuelve mejora automática en todo proyecto futuro. Ese efecto compuesto, a lo largo de los años, justifica la inversión para una empresa seria sobre la calidad.
Lo que aprendimos
Tres aprendizajes que haríamos diferente si empezáramos hoy. 1. Empezar más pequeño. Nuestro primer kit intentó cubrir todo; quedó pesado. Hoy, el kit es mínimo viable, y crece con tracción interna. 2. Versionar agresivamente. Sin una versión clara, un cambio se vuelve una regresión silenciosa. 3. Documentar el "porqué", no solo el "cómo". Un estándar sin justificación cae. Un estándar con historia sobrevive a un cambio de equipo.
Resumen práctico
Para una empresa pequeña o que empieza ahora: adopta un kit abierto, gana velocidad, enfócate en entregar. Para una empresa donde la forma de entregar se volvió un diferencial competitivo, donde el ciclo de mejora es constante, y donde existe una propiedad clara: construye tu propio kit, mantenlo versionado, intégralo con tu ecosistema, y observa cómo la calidad compuesta crece proyecto tras proyecto. No existe una respuesta universal. Existe la respuesta correcta para la etapa de la empresa.