Engenharia de Software com Claude Code em 4 Semanas
Um arquiteto da Base/labs dedicado, durante 4 semanas, para levar seu time a desenvolver software com IA de forma spec-driven, com o harness certo em volta do agente e governança desde o primeiro dia.
4 semanas em período integral, ou diluídas proporcionalmente · 1 arquiteto Base/labs dedicado · 1 time do cliente de até 10 pessoas
Empresas de engenharia que querem usar Claude Code como método de trabalho, e não só como autocomplete turbinado, começando por um time de até 10 pessoas: entregar features e refatorações reais com mais velocidade, sem perder controle de qualidade, segurança e custo.
Claude Code sem método vira "vibe coding": um pedido vago, o modelo adivinha os requisitos que ninguém disse, e o resultado é escopo que cresce no meio da tarefa, implementação pela metade e código que não segue os padrões do projeto. Quanto maior a mudança, maior o estrago. A resposta não é um prompt melhor, e sim processo e ambiente: primeiro se decide o que construir, depois como, e só então se escreve código, dentro de um harness que limita e verifica o que o agente faz.
O processo spec-driven, na prática
Em vez de um prompt solto, cada mudança passa por três documentos e quatro portões de revisão. Spec e plano são arquivos no repositório: sobrevivem entre sessões, entram no pull request e podem ser lidos por qualquer pessoa do time.
1. Spec: o quê e por quê
O agente conduz perguntas de design (formato, fontes de dados, casos de borda, o que fica fora do escopo) e escreve a especificação. Uma pessoa do time revisa e aprova antes de existir qualquer plano.
2. Plano: em quais passos
A partir da spec aprovada, o plano define o que é "pronto", quais arquivos mudam e uma lista ordenada de tarefas, cada uma com o teste que a valida. A revisão humana pega tarefas grossas demais ou fora de ordem.
3. Código: tarefa por tarefa
Para cada tarefa: um teste que falha, o código que o faz passar, refatoração e a revisão de um subagente que lê a mudança sem o contexto de quem a escreveu. Se uma tarefa contradiz a spec, o trabalho para e volta para a spec.
4. Revisão final: contra a spec
Um revisor independente confere o conjunto da mudança com a spec e o plano antes do merge, e uma pessoa aprova.
O harness: o ambiente que controla o agente
A qualidade do que o agente entrega depende do ambiente em que ele trabalha, não só do modelo. Harness engineering é projetar esse ambiente. O entregável mais importante das 4 semanas é a primeira versão do harness da sua empresa, com um tutorial curto de como usá-lo. O arquiteto a constrói junto com o time piloto, e ela fica no repositório.
Contexto
O que o agente precisa saber do projeto: arquitetura, padrões de código, comandos de build e teste e decisões já tomadas, em um CLAUDE.md enxuto.
Memória
O que precisa sobreviver entre sessões: specs, planos e convenções versionados no repositório, em vez de depender do histórico de uma conversa.
Skills
Procedimentos repetíveis do time (abrir uma spec, revisar um PR, gerar um relatório), com passos determinísticos onde o resultado não pode variar.
Ferramentas
O que o agente pode usar: servidores MCP aprovados, integração com o CI, o rastreador de tarefas e o repositório, cada um com permissões mínimas.
Restrições
Guardrails e política de permissões que definem o que o agente não faz, com hooks para as regras que não admitem exceção e limites claros de autonomia.
Verificação
Testes, checagens automáticas e revisão independente que provam que a mudança faz o que a spec pede antes de chegar ao merge.
O que entregamos
- A primeira versão do harness da sua empresa, no repositório: CLAUDE.md, skills, hooks, permissões e templates de spec, plano e tarefas. É o entregável mais importante do trabalho.
- Um tutorial curto de como usar o harness no dia a dia, para o time e para quem entrar depois.
- Um arquiteto da Base/labs dedicado ao trabalho durante todo o período, conduzindo-o na prática.
- Curso hands-on de engenharia com IA para o time, em 3 encontros de meio período, usando o seu código e o seu backlog.
- Fluxo completo de desenvolvimento com agentes: tarefa e spec, implementação (feature, correção e hotfix), revisão de PR, CI/CD, validação de QA, identificação de bugs e monitoramento.
- Detecção de bugs, vulnerabilidades e problemas de performance com apoio de IA, e relatórios de software gerados por skills.
- Escolha de modelo por tarefa, janela de contexto e estimativa de custo de uso.
- Política de permissões, servidores MCP aprovados, telemetria e limites de gasto, definidos com o seu time de segurança.
- Um runbook para levar o processo a outros times da empresa.
Como funciona
Antes de começar
Em conjunto com plataforma, segurança, identidade e rede, fechamos as decisões que precisam existir antes de qualquer pessoa instalar a ferramenta. Escolhemos o time (até 10 pessoas), o repositório e as features reais do trabalho, e capturamos a linha de base no histórico do Git: cycle time, tempo de revisão e retrabalho.
Semana 1: harness v1 e primeira spec
O arquiteto faz um diagnóstico do repositório e monta a primeira versão do harness. O time faz o curso hands-on, em três encontros de meio período, e termina a semana com a spec aprovada de uma feature real.
Semana 2: da spec ao PR
Plano e tarefas com testes, implementação com TDD, skills com passos determinísticos e revisão por subagente, em pair com o arquiteto. Feature, correção e hotfix passam pelo fluxo normal de pull request, e as primeiras mudanças chegam ao merge. O harness é ajustado a cada aprendizado.
Semana 3: do PR à produção
CI/CD, validação de QA, detecção de bugs, vulnerabilidades e performance com IA, e agentes de longa duração para eventos específicos. Entram integrações via MCP, escolha de modelo e custo, e um segundo ciclo de mudanças maiores, que tocam vários arquivos. Começamos a escrever o tutorial a partir do uso real.
Semana 4: autonomia e handover
O time roda o ciclo completo sozinho e o arquiteto só revisa. Definimos juntos os limites de autonomia dos agentes. Seu time assume o harness, a política, a lista de MCP e o relatório de gasto, e recebe o tutorial final e o runbook para outros times. Readout com os números.
- A primeira versão do harness da sua empresa, versionada no repositório, com um tutorial curto de uso.
- Um time de até 10 pessoas que conduz o ciclo spec, plano, código e revisão no seu próprio código.
- Features, correções e refatorações reais entregues durante as 4 semanas, pelo fluxo normal de pull request.
- Templates e política versionados no repositório.
- Runbook para estender o processo a outros times.
- Números do trabalho contra a linha de base, para o readout.
Medimos cycle time, throughput de PRs e tempo de revisão contra a linha de base capturada no histórico do Git antes do trabalho, além de uso e gasto por semana. Acompanhamos também o retrabalho na revisão e as falhas de mudança, para saber se a velocidade não está custando qualidade.
- Um time de até 10 pessoas, e um backlog de features, correções e refatorações reais para ele.
- Os integrantes do time disponíveis para os três encontros do curso e para o pair com o arquiteto.
- Liderança de engenharia definindo qual repositório entra e o que fica fora.
- Segurança, identidade e rede disponíveis para as decisões iniciais.
- Um administrador por área de responsabilidade para receber o handover.
Perguntas frequentes
Como funciona a dedicação do arquiteto?
Um arquiteto da Base/labs fica dedicado ao seu time. O formato de referência é de 4 semanas em período integral. Se as 4 semanas forem diluídas em um calendário mais longo, a dedicação do arquiteto é proporcional: o esforço total é o mesmo, distribuído por mais tempo. Combinamos isso ao desenhar a oferta.
Posso contratar o arquiteto depois da conclusão?
Sim. Depois do handover, a empresa pode contratar horas avulsas do arquiteto para acompanhamento, por exemplo para revisar o harness, tirar dúvidas ou apoiar a chegada de outros times.
O que é o harness?
É o ambiente que cerca o agente de código: contexto do projeto, memória entre sessões, skills, ferramentas, restrições e verificação. Em vez de depender de um prompt perfeito, o time projeta esse ambiente uma vez e o reaproveita em toda tarefa. A primeira versão do harness da sua empresa, com um tutorial curto de uso, é o principal entregável do trabalho.
Por que um único time de até 10 pessoas?
Porque um arquiteto dedicado consegue acompanhar de perto um time desse tamanho, em trabalho real, durante as 4 semanas. O harness e o runbook que sobram servem de base para levar o processo a outros times depois.
Isso é só treinamento?
Não. O curso é uma parte da primeira semana. O restante é engenharia: o time entrega mudanças reais do seu backlog, pelo fluxo normal de pull request, com o arquiteto ao lado.
Qual a diferença para o modo de planejamento do Claude Code?
O modo de planejamento gera um plano dentro da própria sessão. No processo spec-driven, spec e plano são arquivos no repositório, revisados por pessoas e reaproveitados entre sessões e entre times.
Vocês usam Spec Kit, Superpowers ou BMAD?
Escolhemos o fluxo pelo seu contexto. Frameworks abertos como esses ajudam a estruturar o processo, e o que importa é que spec e plano fiquem no repositório e passem por revisão. Para mudanças pequenas, como um ajuste de estilo, o processo completo é exagero, e ensinamos o time a distinguir.
O código fica exposto?
A política de permissões define a que o Claude Code acessa e quais comandos executa, e é desenhada com o seu time de segurança. A rota de acesso ao modelo (Claude Enterprise, Console ou uma nuvem como Bedrock, Google Cloud ou Foundry) é uma das primeiras decisões, e os termos de dados da sua contratação continuam valendo.
Quer conversar sobre esta oferta?
Começamos por uma conversa para entender o seu escopo. Cada oferta tem escopo e preço fechados por fase.