Em 2026, surgiram várias propostas excelentes de kits para padronizar o trabalho com agentes de IA e desenvolvimento moderno: Spec Kit da GitHub, Development Kit da Anthropic, kits internos de outras grandes empresas. São esforços sérios, públicos, com comunidade. Ainda assim, na Steply, escolhemos construir o nosso próprio kit e styleguide. Este post conta por quê, em que momento essa decisão faz sentido para uma empresa, e em que momento adotar um kit pronto é claramente o caminho melhor.
O objetivo não é vender o Steply Kit, é compartilhar o raciocínio. Se você está pensando "vou adotar Spec Kit / Development Kit / outro" ou "vou construir o meu", os argumentos aqui vão ajudar a decidir com clareza.
O que é um "kit", afinal
Kit, neste contexto, é um pacote de convenções, templates, prompts, comandos, fluxos e ferramentas que padroniza como uma equipe trabalha com agentes de IA e desenvolvimento de software. Inclui coisas como: formato de spec, padrão de commit, prompts de sistema reutilizáveis, comandos slash (/review, /test, /docs), playbooks de PR, padrões de estrutura de projeto, regras de revisão automatizada.
O valor de um kit está em previsibilidade: qualquer pessoa do time entrega no mesmo padrão; qualquer agente recebe o mesmo briefing; qualquer cliente vê a mesma qualidade. Sem kit, cada projeto é uma improvisação e a empresa não escala qualidade.
Os kits prontos que avaliamos
Spec Kit (GitHub): foco em Spec-Driven Development com formato padronizado de spec consumida por copilots e agentes. Forte para alinhamento entre produto e engenharia. Development Kit e ferramental da Anthropic: foco em ciclo de trabalho com Claude Code, padrões de agente, evals. Outros kits abertos ou semi-abertos de grandes empresas com peças reutilizáveis.
Todos têm qualidades reais. São esforços públicos, mantidos por times sérios, com comunidade. Em muitos casos, adotá-los integralmente seria a decisão certa.
Por que mesmo assim construímos o nosso
Cinco razões pesaram, em ordem de impacto.
1. Cultura de entrega é diferencial competitivo, não commodity. A forma como a Steply entrega, do briefing à revisão final, é parte do que nos contrata. Adotar um kit pronto integralmente significa que nossa entrega vira indistinguível de qualquer outra empresa que adote o mesmo kit. Construir um kit próprio ancora a forma de trabalhar na nossa identidade e permite afinar o que faz diferença no nosso público.
2. Padrões prontos otimizam para o "caso médio" da comunidade. Kits abertos têm que servir do hackathon ao banco multinacional. Isso é uma virtude para adoção, mas força concessões. Nosso kit pode otimizar para o nosso perfil de cliente, nosso stack predominante, nossos processos. Cada conveniência grande tem custo de generalidade.
3. Velocidade de evolução depende de propriedade. Quando algo precisa mudar, novo padrão, novo prompt, nova regra, em kit próprio leva minutos. Em kit aberto, é PR, debate, espera, talvez ser recusado, talvez ficar em fork divergente. Para empresa que ajusta processo continuamente, possuir a ferramenta é não-negociável.
4. Integração profunda com o ecossistema interno. Nosso kit conversa com nossa harness de agentes, nosso pipeline de evals, nossa observabilidade, nossos templates de cliente. Cada peça do kit é desenhada para encaixar nessa stack. Um kit externo pediria adaptação contínua e perda de coesão.
5. Conhecimento que fica em casa. Construir o kit força o time a articular cada decisão, registrar cada padrão, justificar cada convenção. Esse processo, em si, é treinamento. As pessoas que constroem o kit entendem o porquê de cada peça, e o conhecimento fica internalizado, não delegado a um README externo.
Onde adotamos coisas prontas
Construir kit próprio não é rejeitar tudo. Em camadas onde o padrão da comunidade é claramente superior e estável, adotamos. MCP para tools de agente, sem hesitação. OpenAPI para descrição de API REST. JSON Schema para validação. Conventional Commits para mensagem de commit. Padrões de SDD abertos para spec inicial, com extensões nossas. SDKs oficiais de provedores de LLM. Onde existe padrão útil e neutro, usamos; onde a decisão é cultural ou de identidade, construímos.
O que entra no Steply Kit
O kit cobre cinco eixos. 1. Templates de spec: formato padronizado de briefing, com seções obrigatórias e opcionais, prontos para serem consumidos por agentes de codificação. 2. Prompts de sistema: para agentes de cada papel (revisor, redator, gerador de teste, especialista em legacy), com tom, princípios e formato de saída padronizados. 3. Comandos slash: comandos reutilizáveis dentro do nosso ambiente de trabalho (/review, /spec, /eval, /deploy, /audit), cada um disparando um fluxo predefinido. 4. Styleguide: voz, vocabulário, formatação, regras de comunicação visual e textual, do código ao Slack interno ao deck para cliente. 5. Playbooks operacionais: como conduzir kickoff, como fazer code review, como entregar release, como gerenciar incidente. Cada playbook é versionado e revisado em intervalo regular.
Styleguide: voz e identidade
O styleguide é a parte mais subestimada. Sem styleguide, cada PR, cada e-mail, cada conversa com cliente tem tom diferente. Com styleguide, há coerência entre canais. O nosso styleguide define: pessoa do verbo (terceira, plural, ou primeira por canal), uso de gírias técnicas, nível de detalhe esperado em cada formato, regras de adjetivação ("não exagere", "evite superlativos"), formatação preferida em markdown, padrão de emoji (parcimônia consciente), e exemplos comentados de "como soa Steply".
Isso é tratado como código: tem repositório, tem PR, tem revisor, tem versão. Mudança discutida e documentada. Sem dono claro, styleguide vira ficção que ninguém segue.
Quando construir o próprio NÃO faz sentido
Seja honesto. Construir kit próprio não vale a pena quando: (a) o time é pequeno e ainda não tem padrão para extrair; (b) o stack varia muito entre projetos sem consistência; (c) não há ninguém para manter o kit ao longo do tempo (kit órfão apodrece); (d) o kit aberto cobre 95% do que você precisaria e os 5% restantes são cosméticos.
Para a maioria das empresas pequenas começando agora, adotar Spec Kit ou similar integralmente é a decisão certa no curto prazo. Construir vem depois, quando a identidade da entrega já está clara o suficiente para que o kit reflita uma forma de trabalhar madura.
O custo real de manter um kit próprio
Honestidade: kit próprio tem custo recorrente. Precisa de dono, precisa de tempo para evoluir, precisa de onboarding interno, precisa ser revisado. Em compensação, ele composição: cada melhoria de processo vira melhoria do kit, que vira melhoria automática em todo projeto futuro. Esse efeito composto, ao longo de anos, justifica o investimento para empresa séria sobre qualidade.
O que aprendemos
Três aprendizados que faríamos diferente se começássemos hoje. 1. Começar menor. Nosso primeiro kit tentou cobrir tudo; ficou pesado. Hoje, o kit é mínimo viável, e cresce com tração interna. 2. Versionar agressivamente. Sem versão clara, mudança vira regressão silenciosa. 3. Documentar o "porquê", não só o "como". Padrão sem justificativa cai. Padrão com história sobrevive a mudança de time.
Resumo prático
Para empresa pequena ou que começa agora: adote kit aberto, ganhe velocidade, foque em entregar. Para empresa onde a forma de entregar virou diferencial competitivo, onde o ciclo de melhoria é constante, e onde existe propriedade clara: construa seu próprio kit, mantenha versionado, integre com seu ecossistema, e veja a qualidade composta crescer projeto após projeto. Não existe resposta universal. Existe a resposta certa para o estágio da empresa.
