Trabalhar com várias IAs no mesmo time virou um problema de processo · drumas

Nos últimos meses, uma coisa foi ficando muito clara para mim: usar IA para desenvolver software é relativamente fácil; o difícil é fazer isso de forma consistente quando cada pessoa do time usa uma ferramenta diferente.

Tem gente trabalhando com GitHub Copilot.
Tem gente preferindo Claude.
Tem quem teste Codex ou outros agentes.
E, na prática, cada um desses runtimes tem um jeito próprio de operar, guardar contexto e conduzir a execução.

O resultado quase sempre é o mesmo: o time até ganha velocidade em pontos isolados, mas perde coerência no processo.

Foi justamente desse incômodo que nasceu o meu repositório pessoal, o ia_boilerplate.

Ele não foi criado como framework de aplicação, nem como coleção de prompts, nem como “truque” para fazer IA programar sozinha. Eu fiz esse repositório porque queria resolver um problema muito específico que eu estava enxergando no uso real de IA entre pessoas, fluxos e ferramentas diferentes: como criar uma forma de trabalho que sobreviva à troca de agente, à troca de sessão e até à troca de pessoa no time.

Repositório: https://github.com/mlucascosta/ia_boilerplate

O problema real não é a IA. É a fragmentação.

Hoje, muita coisa feita com IA ainda depende demais do chat.

A decisão fica numa conversa.
O racional fica em outra.
O plano fica só parcialmente explícito.
A execução acontece em uma ferramenta.
A continuação vai para outra.
E, quando alguém precisa revisar ou assumir aquela tarefa depois, grande parte do contexto já evaporou.

Na prática, isso cria um cenário ruim para times:

a IA ajuda individualmente, mas o conhecimento não se consolida como ativo do projeto.

Foi por isso que eu quis inverter a lógica.

Em vez de tratar o histórico de conversa como fonte principal de contexto, eu quis tratar o repositório como fonte de verdade. A ideia central do ia_boilerplate é justamente essa: oferecer um workflow repositório-cêntrico e orientado por artefatos, para que diferentes agentes trabalhem sobre a mesma base operacional.

Por que eu fiz isso

Eu fiz esse repositório porque não queria depender da “memória mágica” de cada ferramenta.

Queria algo em que:

o planejamento fosse explícito;
o estado atual do trabalho estivesse documentado;
as regras do fluxo fossem estáveis;
os artefatos fossem compartilhados;
e qualquer agente pudesse entrar no processo sem precisar reinventar o contexto do zero.

No fundo, eu quis criar uma camada de disciplina em cima do uso de IA.

Não para engessar o trabalho, mas para impedir que ele virasse uma sucessão de interações descartáveis.

Minha motivação não foi “usar mais IA”. Foi usar melhor, de um jeito que funcione também em ambiente de time, com revisão, continuidade e responsabilidade técnica.

Como eu fiz

A estrutura do repositório foi desenhada para centralizar esse modelo operacional.

O projeto traz:

um workflow canônico em docs/ai/WORKFLOW.md;
um contrato canônico de artefatos em docs/ai/ARTIFACTS.md;
adaptadores para Copilot, Claude e Codex;
uma estrutura .planning/ para roadmap, estado, planos, sumários e verificação.

Ou seja: em vez de cada agente trabalhar “do seu jeito”, a intenção é fazer todos convergirem para o mesmo processo.

O WORKFLOW.md existe para definir a maneira de trabalhar.
O ARTIFACTS.md existe para definir o que precisa ser produzido e mantido.
A pasta .planning/ existe para funcionar como memória operacional persistente.
Os adaptadores existem para reconectar cada runtime à mesma fonte de verdade do repositório.

Isso foi importante para mim porque eu não queria uma solução dependente de uma única plataforma. Eu queria um modelo que pudesse continuar útil mesmo quando a ferramenta mudasse.

O ponto central: documentação como memória operacional

Uma das ideias mais importantes desse repositório é tratar documentação não como “decoração” ou burocracia, mas como parte ativa da execução.

Esse ponto, para mim, é o coração da proposta.

Porque o maior risco no uso cotidiano de IA não é só errar tecnicamente.
É construir um fluxo que ninguém consegue continuar com segurança depois.

Quando a memória do processo fica só no chat, o projeto depende demais da sessão, da ferramenta e da pessoa que estava ali naquela hora.

Quando a memória vai para artefatos do repositório, o trabalho fica mais durável.

Também fiz questão de manter exigência técnica

Outra coisa que eu não queria era transformar IA em desculpa para baixar o nível da engenharia.

Por isso, o repositório assume algumas regras explícitas, como a presença de documentação completa no código e uma arquitetura orientada a SOLID.

Isso foi intencional.

Eu não queria um workflow que só acelerasse geração de código.
Eu queria um workflow que empurrasse a entrega para algo mais legível, revisável e sustentável.

É um projeto pessoal, mas eu quis abrir para contribuição

Esse repositório é pessoal no sentido mais direto da palavra: ele nasceu da forma como eu venho pensando e organizando meu próprio uso de IA no desenvolvimento.

Não surgiu como produto.
Não surgiu como template comercial.
Surgiu como uma tentativa prática de resolver um problema real que eu enxerguei no trabalho com múltiplos agentes.

Mas justamente por isso eu achei que valia abrir.

Porque esse problema não é só meu.

Quanto mais times começam a usar ferramentas diferentes ao mesmo tempo, mais aparece a necessidade de um processo comum por trás delas.

Então a ideia de publicar isso não é “olhem o meu template”.
É mais: eu construí isso para resolver um problema que venho vivendo, e quero transformar essa base em algo que também possa ser útil para outras pessoas.

O que ele entrega hoje

Hoje o ia_boilerplate entrega uma base pequena, mas com propósito bem definido.

Ele oferece um modelo compartilhado para agentes como Copilot, Claude e Codex trabalharem contra as mesmas regras, os mesmos artefatos e as mesmas restrições de execução. Também já traz um script de bootstrap para adaptar o boilerplate ao nome do projeto clonado e ajustar identificadores internos, caminhos locais e metadados principais.

Isso ajuda a transformar o repositório numa fundação reaproveitável, e não só numa documentação isolada.

A discussão que eu queria abrir

Para mim, a discussão mais interessante nem é “qual IA é melhor”.

A discussão é outra:

como um time mantém consistência quando pessoas diferentes usam IAs diferentes?
como evitar que a produtividade fique refém de contexto efêmero?
como transformar planejamento, estado e decisão em ativos do projeto?
como manter portabilidade entre ferramentas sem recomeçar do zero a cada troca?

Foi tentando responder isso que eu criei o ia_boilerplate.

Repositório: https://github.com/mlucascosta/ia_boilerplate

Queria compartilhar porque é um projeto pessoal no qual venho organizando essa visão de trabalho, e porque acredito que esse tipo de contribuição pode ficar mais útil se for debatido e tensionado por outras pessoas que também estão lidando com IA no dia a dia do desenvolvimento.

Alguém aqui já sentiu esse problema no time?
Vocês centralizam a memória operacional no repo, em ADR, em docs, em issues, ou ainda deixam boa parte disso espalhada entre chats e ferramentas?

#ia #desenvolvimento #copilot #claude #codex #workflow #documentacao #opensource