Caso 06 Rails · React · Desenvolvimento assistido por IA
Contexto relevante: Rails e React no mesmo repositório
Em um projeto da NAK na Alemanha, propus manter o backend Rails e o frontend React no mesmo repositório. A equipe preferia repositórios separados; expliquei os trade-offs e a proposta foi adotada.
Contexto
O projeto é um sistema de gestão de colaboradores orientado a metas para a NAK, na Alemanha, com contato direto com clientes internacionais. É um projeto diferente de outros trabalhos para a NAK citados neste site.
O desenvolvimento usava assistentes de IA no dia a dia, para implementar funcionalidades, corrigir bugs e responder perguntas sobre o sistema.
Problema
A equipe seguia o padrão familiar de repositórios separados para frontend e backend. Em desenvolvimento assistido por IA, isso tem um efeito pouco visível: ao investigar um bug ou implementar uma funcionalidade, o assistente enxerga um lado do contrato e precisa supor o outro.
Contexto de menos esconde contratos e dependências. Contexto demais, sem relação com a tarefa, distrai do problema real.
Minha responsabilidade
Propus manter o backend Ruby on Rails e o frontend React no mesmo repositório GitHub. Outros desenvolvedores preferiam, a princípio, a separação habitual.
Expliquei o raciocínio e os trade-offs, e a equipe adotou o repositório compartilhado.
Decisão
Manter o código relacionado junto facilita inspecionar os dois lados de uma funcionalidade ou de um bug, e ainda permite selecionar apenas o contexto necessário para cada tarefa.
A decisão não é "colocar tudo no prompt". É deixar o contexto relevante ao alcance, para que ele possa ser escolhido.
In AI-assisted development process: Context is King.
Alternativas e trade-offs
Análise atual, escrita para este site. Não é um registro das alternativas avaliadas na época.
- Um repositório compartilhado também tem custos: pipelines, permissões e convenções precisam considerar as duas partes, e o volume de código cresce.
- Ele não resolve sozinho a qualidade das respostas de uma IA. Repositórios separados podem funcionar bem com outras formas de expor contratos, como especificações de API versionadas. O que importa é conseguir reunir o contexto certo para cada tarefa.
Implementação
Como a decisão se traduz no trabalho diário:
Contrato visível
Componente, chamada de API, controller e serializer ficam acessíveis na mesma busca, e mudanças no contrato aparecem juntas na revisão.
Contexto selecionado
Para cada tarefa, o assistente recebe os arquivos que importam dos dois lados, não o repositório inteiro.
Verificação humana
A resposta continua sendo revisada e testada; contexto melhor reduz suposições, mas não substitui julgamento.
Visualização
Repositórios separados
Frontend React
ReportStatus.tsx(no contexto)api/reports.ts(no contexto)useReportStatus.ts(no contexto)Sidebar.tsx(no contexto)theme.css(no contexto)
GET /reports/:id { id, title, ??? } (formato suposto)Backend Rails
reports_controller.rb(fora do contexto)report_serializer.rb(fora do contexto)report.rb(fora do contexto)mailer.rb(fora do contexto)seeds.rb(fora do contexto)
O assistente vê o frontend. O contrato com o backend precisa ser suposto.
Resposta provável: Sugere mudar o componente, sem saber que o serializer não envia o campo.
Repositório compartilhado, contexto selecionado
Frontend React
ReportStatus.tsx(no contexto)api/reports.ts(no contexto)useReportStatus.ts(no contexto)Sidebar.tsx(fora do contexto)theme.css(fora do contexto)
GET /reports/:id { id, title, status } Backend Rails
reports_controller.rb(no contexto)report_serializer.rb(no contexto) sem o campo statusreport.rb(no contexto)mailer.rb(fora do contexto)seeds.rb(fora do contexto)
Os arquivos relevantes dos dois lados entram no contexto; o restante fica de fora.
Resposta provável: Aponta o campo ausente no serializer e ajusta os dois lados do contrato.
Resultado
Na minha experiência nesse projeto, funcionalidades e correções de bugs ficaram mais rápidas, e as perguntas sobre o sistema passaram a receber respostas mais precisas e úteis, porque o assistente podia inspecionar frontend e backend juntos.
São observações qualitativas. Não tenho um percentual medido de melhoria para publicar, e um monorepo, sozinho, não garante respostas melhores.