A engenharia de plataforma e o DevOps estão passando por uma transformação impulsionada por agentes de IA. Recentemente, em meus estudos de arquitetura, infraestrutura e governança, comecei a utilizar o SpecKit, uma ferramenta que atua desde a especificação técnica até a implementação de código.
Neste artigo, quero compartilhar minha experiência prática integrando o SpecKit no dia a dia para desenhar arquiteturas Cloud, escrever Terraform e automatizar fluxos, destacando o que funciona bem e os pontos de atenção.
O que é o SpecKit e sua Importância
O SpecKit funciona como um assistente avançado que ajuda a planejar e codificar soluções técnicas. A grande vantagem é que ele não apenas "gera código", mas segue um fluxo de engenharia estruturado que é vital para nós, Platform Engineers: Create the spec > Create a technical implementation plan > Break down into tasks > Execute implementation, isso integrado a minha IDE like Vscode ao chat de agente, já o utilizei com o Copilot e com o Antigravity.
Isso significa que, antes de cuspir dezenas de arquivos .tf, ele gera um documento de constituição (constitution.md) ou especificação técnica e um plano de ataque, permitindo que o arquiteto revise as premissas, a segurança e a modularização antes da execução.
Como eu configuro e utilizo (Hands-on)
A inicialização da ferramenta no repositório local é bem direta. Eu começo instalando o specify na pasta do projeto:
$ uvx --from git+https://github.com/github/spec-kit.git specify init --here
(Fonte de referência dos meus estudos de setup).
A mágica do SpecKit para DevOps acontece quando injetamos Skills específicas no agente. Dependendo do projeto, eu adiciono pacotes de habilidades voltadas para Terraform, GitHub Actions, ou skills de provedores de infraestrutura em nuvem:
npx skills add https://github.com/hashicorp/agent-skills --skill terraform-stacks
npx skills add https://github.com/jeffallan/claude-skills --skill terraform-engineer
npx skills add https://github.com/callstackincubator/agent-skills --skill github-actions
(Adicionando contexto técnico para o agente não alucinar com práticas ruins).
Com o ambiente preparado, eu utilizo o comando /speckit.constitution para passar meu prompt detalhado e iniciar o planejamento. Eu costumo preparar um prompt em outras ferramentas como Gemini ou ChatGPT, etc.
Casos de Uso Reais (e como o SpecKit se saiu)
Durante minhas validações técnicas, apliquei o SpecKit em variados cenários de infraestrutura. Aqui um exemplo ficticio:
O objetivo era definir uma estratégia de migração de aplicações containerizadas para uma arquitetura com isolamento de rede mais robusto, mantendo compatibilidade com integrações externas.
O prompt especificava requisitos como separação entre camadas públicas e privadas, roteamento de saída controlado, alta disponibilidade entre zonas de disponibilidade e impacto mínimo nas aplicações existentes.
Resultado: A ferramenta gerou uma proposta arquitetural completa, incluindo diagramas de fluxo, plano de migração, dependências técnicas e validações necessárias para garantir conectividade entre componentes. Durante a evolução do projeto, ajustes de segurança e requisitos de integração puderam ser incorporados sem reestruturar a documentação original.
Prós e Contras
Com em PoCs executadas, aqui está o meu veredito sobre o uso do SpecKit no contexto de plataforma:
Prós
- Fluxo Racionalizado: A quebra do problema em "Especificação técnica" -> "Plano de tarefas" -> "Código" evita que a IA crie arquivos caóticos. Se a especificação arquitetural estiver errada (ex: usar EKS em vez de Fargate), eu posso corrigir antes que ele gere o Terraform.
- Refinamento Contínuo: É muito fácil pedir alterações granulares, como aplicar testes HCL nativos (
.tftest.hcl) ou injetar variáveis específicas de ambiente (variables.tfvars) nos módulos.
- Adoção de Padrões: Usando as Skills externas, a ferramenta já herda boas práticas de módulos oficiais da comunidade.
Contras
- Dependência de Prompts Extremamente Detalhados: O SpecKit só é incrível se você souber exatamente o que quer. Eu precisei especificar até restrições como "NÃO usar tecnologia X ou Y" e "manter tasks stateless" para garantir que a IA não tomasse decisões que ferissem os princípios de custos e ou anti-patterns.
- Revisão Frequente: Arquiteturas baseadas em nuvem envolvem políticas sensíveis de IAM e rede (ex:
s3:PutObject ou peering de VPCs). O código gerado exige um olhar crítico com ferramentas como Checkov ou Trivy para evitar misconfigurations geradas por IA.
Conclusão
O SpecKit se mostrou um copiloto poderoso para Engenharia de Plataforma. Ele não substitui o arquiteto de soluções — pelo contrário, ele exige que o arquiteto faça as perguntas certas e defina os guardrails corretos. Contudo, ao reduzir o tempo gasto na escrita de boilerplate (módulos Terraform, pipelines do GitHub Actions, Task Definitions do ECS), ele libera a equipe de plataforma para focar em segurança, governança e experiência do desenvolvedor.