Um Ano Sem Escrever Código Manualmente: A Distinção Crucial Entre 'Vibe Coder' e Engenheiro de IA

Há mais de um ano, não escrevo código manualmente. Todo o código é gerado por IA. No entanto, não me considero um 'vibe coder'. Eu me defino modestamente como um engenheiro de IA. A distinção não reside em quem digita as teclas – em ambos os casos, é a IA que o faz. A diferença crucial está na abordagem: o 'vibe coder' aceita o que o modelo gera sem compreendê-lo, enquanto eu verifico cada aspecto. Dependendo da complexidade da tarefa, analiso linha por linha ou funcionalmente, pois poderia ter escrito o código eu mesmo, apenas de forma mais lenta. À primeira vista, a ação pode parecer a mesma, mas em essência, são profissões opostas. E essa diferença, em breve, custará caro às empresas, como demonstrarei com o cliente Git que desenvolvi.

Minha jornada começou em um ambiente restrito: trabalho em uma grande empresa do setor energético, operando em um circuito fechado com um serviço de segurança da informação (SI) ativo. A realidade desse tipo de ambiente é que a instalação de um cliente Git convencional, como Fork, GitKraken ou SourceTree, é proibida. A lógica da SI é clara e justificável: esses clientes são proprietários, conectam-se a servidores estrangeiros e coletam telemetria. Para um circuito fechado, isso representa uma recusa automática. Resta apenas o console Git puro. Não tenho nada contra o uso do Git no terminal, mas em projetos grandes, com múltiplas branches, conflitos e um histórico de milhares de commits, é desejável visualizar o grafo de commits em vez de reconstruí-lo mentalmente. Isso é especialmente importante quando se trabalha com colegas que praticam o 'vibe coding' de forma agressiva, commitando diretamente sem verificar o repositório. Submeter código às cegas é o pior cenário possível. Cansado de buscar alternativas, decidi criar meu próprio cliente, batizando-o de GitBor.

Tecnicamente, o que significa 'passar pela SI'? O GitBor é um cliente Git desktop construído em Electron, utilizando o Git do sistema. Ele está disponível para Windows e Linux, com planos para macOS. O objetivo principal era obter aprovação da SI interna e criar um análogo robusto que realmente auxiliasse no desenvolvimento. A razão pela qual ele pode ser aprovado pela SI, ao contrário de alternativas estrangeiras, é multifacetada: opera localmente, não se conecta a servidores externos para acessar seu código, não possui telemetria nem conexões 'domésticas'. Além disso, existe uma versão de build sem IA. Essa opção foi implementada porque a versão com IA integrada não foi permitida em nosso ambiente. Para os requisitos de SI mais rigorosos, ele não possui funções de nuvem, sendo uma ferramenta puramente local. Se a IA for necessária, ela deve ser executada localmente, utilizando Ollama, LM Studio ou qualquer endpoint compatível com OpenAI. O código nunca sai da máquina. Possui um titular de direitos autorais russo, o que é importante tanto para a SI quanto para o Registro de Software Russo. Para ser transparente, meu cliente passou pela revisão interna de SI da minha empresa, e nada mais. Não o apresento como uma certificação oficial ou aprovação para uso em bancos. No entanto, arquitetonicamente, o produto foi projetado desde o início para ambientes fechados, o que é um fator que a SI pode considerar para aprovação.

O motivo pelo qual escrevo este artigo é a proliferação de modelos de IA fechados em empresas, como o Qwen e outros similares. No entanto, sejamos honestos: a inteligência desses modelos é significativamente inferior à de modelos de ponta como o Opus. Em projetos de grande escala, esses modelos falham em identificar as conexões entre módulos e, por vezes, até mesmo entre funções, pois não possuem uma visão holística do sistema. Testes automatizados não cobrem todas as falhas, e a revisão manual do código gerado é árdua, especialmente na ausência de ferramentas adequadas no ambiente corporativo. Foi nesse contexto que percebi que meu cliente deixou de ser apenas um substituto para o Fork; ele se tornou um 'microscópio' sobre o trabalho da IA. Ao abrir o GitBor, não vejo apenas o que a IA 'disse' que fez, mas sim o que ela realmente executou, linha por linha. Eu seleciono apenas os blocos de código que verifiquei e rejeito o restante diretamente no diff. Não comito tudo indiscriminadamente, mas sim compilo commits significativos a partir do que está realmente pronto. Trabalho em ciclos: quando solicito uma função ou componente, verifico imediatamente no diff do GitBor para onde o agente enviou o código. Modelos menos capazes geram grandes volumes de código e o espalham indiscriminadamente. Isso é claramente visível no programa, e o mais importante é que posso intervir rapidamente para corrigir. Um benefício adicional surge quando uma parte do código já está funcionando, mas há o receio de que o próximo prompt possa quebrar tudo – algo comum com agentes menos sofisticados. Para mitigar esse risco, coloco o trecho de código funcional em uma seção 'preparada' no GitBor. Na prática, você obtém duas versões do mesmo arquivo simultaneamente: pode aceitar o que o agente fez em segundos ou reverter para o estado anterior, sem a necessidade de um rollback complexo. Essa é a linha divisória entre um 'vibe coder' e um engenheiro. O 'vibe coder' aceita e segue em frente. Eu analiso o que estou aceitando. O GitBor é uma ferramenta para aqueles que se responsabilizam pelo seu código. Um 'vibe coder' dificilmente precisará dele, pois já aceita tudo sem olhar.

O que há dentro do GitBor (brevemente e de forma objetiva)? Para garantir que não seja 'apenas mais um cliente Electron': existem 5 níveis de proteção de dados: git reflog, auto-stash antes de operações destrutivas, salvamento do hash HEAD, log de operações WAL e um RecoveryManager na inicialização. O objetivo é tornar a perda de dados praticamente impossível. Um worker pool gerencia parsers pesados, decompondo grafos com milhares de commits em um thread separado, evitando que a interface do usuário trave. Motores independentes para múltiplos repositórios garantem que um pull demorado em um repositório não bloqueie operações em outro. São 635 testes unitários, pois uma ferramenta confiável para gerenciar código não pode falhar. O cliente oferece um grafo com virtualização, rebase interativo, diff inline/split com destaque, blame e resolução de conflitos em duas colunas.

Sendo honesto sobre os pontos fracos, e não apenas os aspectos positivos: não há code signing. No Windows, o SmartScreen pode exibir avisos, e no Windows 11 mais recente com Smart App Control, a instalação pode ser rigidamente bloqueada sem contornar as restrições. Para máquinas domésticas, isso representa uma barreira real. Atualmente, lidar com certificados na Rússia é complicado – CAs ocidentais não vendem, e um certificado russo é inútil para o SmartScreen. Portanto, a assinatura digital permanece uma questão em aberto. Não pretendo substituir o Fork para todos; resolvi minha própria dor e a de meus colegas. O código-fonte é fechado, uma escolha consciente que pode ser debatida. Por que este artigo? Não estou vendendo o GitBor, ele é gratuito. Meu interesse reside em discutir a tese com a qual comecei: na era da IA, o valor se deslocou de 'escrever código' para 'verificar se o código não está mentindo'. Gerentes frequentemente acreditam que um júnior com IA substitui um engenheiro. Eu acredito que essa crença terá um custo. O GitBor é minha maneira de manter esse controle visível. Ele está disponível para Windows e Linux, com uma build sem IA. Se tiver interesse, visite https://gitbor.ru. Ficarei feliz em receber feedback rigoroso nos comentários, especialmente daqueles que operam em ambientes fechados semelhantes.