Gemini Conductor: A Nova Ferramenta do Google Para Consertar Programação com IA

O vídeo apresenta o lançamento do Gemini Conductor pelo Google como mais um fluxo de trabalho de engenharia de contexto. O apresentador imediatamente afirma que a ferramenta não é melhor que outros fluxos de trabalho existentes e possui muitos problemas, mesmo dentro do ecossistema Gemini. Após essa introdução crítica, há uma pausa para falar sobre a Automata, empresa que implementa fluxos de trabalho de IA ensinados no canal. A Automata se posiciona como copiloto técnico para transformar ideias em produtos funcionais sem a necessidade de contratar equipes de desenvolvimento, aplicando os mesmos workflows ensinados a milhões de pessoas diretamente nos projetos dos clientes.

Esta seção explica como o Conductor realmente funciona tecnicamente. Ele é instalado como uma extensão no Gemini CLI através de um comando disponível no artigo oficial. Extensões são conjuntos de comandos, MCPs e regras agrupados em pacotes que podem ser compartilhados, similar aos plugins do Claude. Após a instalação, o usuário tem acesso a cinco comandos slash que controlam o fluxo de trabalho. O primeiro comando é o 'setup', que verifica arquivos existentes, cria estruturas chamadas 'tracks' (ao invés de histórias), inicializa um repositório GitHub e pergunta o que o usuário deseja construir.

O apresentador descreve seu teste com um projeto simples focado em verificar se a arquitetura criada seria realmente boa, especificando que deveria ser pronto para produção e escalável. O Conductor criou o arquivo product.md com o conceito do projeto e começou a fazer perguntas para refinar, mas as questões eram simplistas e não levavam a lugar nenhum, então o apresentador deixou gerar automaticamente. O sistema então criou diretrizes do produto focadas em estilo e princípios de design, e definiu a pilha de tecnologia. Esta foi uma das primeiras falhas graves: mesmo sabendo detalhes do projeto, o Conductor não recomendou tecnologias apropriadas e o apresentador teve que corrigir manualmente.

O Conductor possui arquivos chamados guias de estilo de código para linguagens específicas que adiciona automaticamente durante a inicialização se detectar que serão usadas no projeto. O fluxo de trabalho padrão inclui recursos positivos como cobertura de teste de código de 80%, garantindo que testes sejam escritos junto com componentes base. O sistema também implementa commits automáticos após cada tarefa e usa git notes para rastreamento, permitindo identificar onde e quando algo deu errado. Após a configuração inicial, o Conductor criou requisitos de produto de alto nível para entrar na track inicial, mas essa primeira track era muito ampla e precisava ser dividida em tracks menores para evitar bagunça.

Para iniciar o trabalho, usa-se o comando 'implement', que acessa a pasta tracks contendo diferentes tracks implementadas uma por uma. Cada track possui dois arquivos: plan.md (com tarefas a implementar) e spec.md (com objetivo e detalhes técnicos extraídos da pilha de tecnologia). O comando implement consulta o tracks.md e determina ações baseado no status: vazio significa não iniciado, em progresso ou completado. Outros comandos incluem 'status' (fornece relatório do progresso), 'new track' (para novas tarefas) e 'revert' (recurso inteligente com consciência de git para mitigar danos). O apresentador também testou em repositório pré-existente, onde o comportamento foi diferente, olhando arquivos existentes e fazendo perguntas esclarecedoras.

Apesar da estrutura de arquivos não ser ruim, as instruções e comandos precisam de trabalho pois não gerenciam adequadamente o loop de contexto. Durante o processo inicial, houve muitos erros: o sistema não dissecou a ideia adequadamente, exigindo orientação manual. A pilha de tecnologia perdeu componentes cruciais para um aplicativo escalável que o apresentador teve que especificar explicitamente. O esquema do banco de dados gerado estava totalmente incompleto, faltando elementos cruciais para configurar o app. O apresentador suspeita que os problemas estão nos comandos implementados, não no modelo Gemini em si, que é realmente bom. A maior evidência disso veio quando tentou mudar de NPM para PNPM.

Quando o apresentador pediu para mudar de NPM para PNPM, ocorreu o erro mais grave: o Conductor tentou fazer backup primeiro e, ao remover arquivos criados com NPM, deletou a pasta conductor inteira contendo todos os arquivos de planejamento. Após deletar, ficou procurando continuamente pela pasta e, ao não encontrá-la, disse que reconstruiria usando contexto e memória. Isso contradiz completamente o que um fluxo de trabalho de contexto normal deveria fazer: mudanças deveriam afetar apenas arquivos de contexto principais e arquivos relacionados àquela tarefa específica, como o 'be mad' faz para operar eficientemente. Este erro demonstra falhas fundamentais na arquitetura dos comandos.

Durante a implementação da primeira trilha, ao configurar variáveis de ambiente para conexão com Supabase, o Conductor marcou automaticamente a tarefa como concluída mesmo colocando uma chave fictícia. Não pediu para configurar o projeto Supabase nem forneceu chave real, e tentou enviar o esquema do banco de dados, falhando por falta de chave válida. As tarefas não estavam sendo atualizadas corretamente e o sistema não as seguia adequadamente. O apresentador conclui que não usaria o Conductor para desenvolvimento de ponta a ponta, afirmando que 'be mad' é opção muito melhor, e para projetos pequenos prefere fazer seus próprios arquivos de contexto. Finaliza convidando espectadores a apoiar o canal através do botão 'super thanks'.