Eu testo toda ferramenta antes da minha equipe. CEO que não testa vira refém do CTO

De onde eu falo

Vou dar minha carteirada antes, pra quem chegou agora. Eu sou CEO de uma empresa de verdade, sou engenheiro de infraestrutura de verdade e eu pago a conta de verdade. Cuido de equipe de desenvolvimento, de suporte e de infraestrutura, e cuido pessoalmente de data center no Brasil e nos Estados Unidos. Data center mesmo, no mesmo ambiente em que estão Google e Meta. Óbvio que a gente é o menorzinho ali, na humildade.

Eu sou CEO hands-on. Eu não saio do tático e do estratégico sem entender produção, principalmente em tecnologia. Eu não sou refém de ninguém: boto a mão na massa e desembolo o que precisar desembolar hoje.

Lógico que eu preciso de gente de confiança pra escalar. Sozinho ninguém consegue nada.

A equipe traz, eu trago, e eu testo antes de virar padrão

Não é que só entra o que eu escolho. A minha equipe tem total liberdade, e muitas vezes são eles que trazem coisa pra gente testar e pôr na rotina. Outras vezes sou eu que levo pra eles.

O que não muda é a ordem: antes de entrar na rotina da empresa, eu testo. Eu vou lá, compro, pago, faço código, quebro, ajusto. Só depois eu falo "vamos botar na equipe".

Estes são os casos que eu citei, do jeito que aconteceram:

Antigravity: três meses e fora

Quando surgiu o Antigravity, eu fui lá e testei. Comprei, paguei, fiz código, quebrei, ajustei. Botamos na equipe.

Aí o meu começou a falhar muito. Levei pra equipe e falei, com essas palavras, que o meu Antigravity estava um cocô: travando, batendo em rate limit, dando pau, estourando a minha máquina toda hora. A resposta foi "o nosso também".

Tiramos do pipeline. Testa rápido, tira rápido. Sinceramente, durou mais ou menos três meses.

Pra você situar: o Antigravity é a plataforma de desenvolvimento com agentes que o Google apresentou em novembro de 2025, em prévia pública. Eu voltei no assunto do Google mais de uma vez aqui no blog, como quando testei o Jules e não serviu pro meu pipeline autônomo.

Cursor: a equipe queria, a conta não fechou

O Cursor eu não lembro se fui eu que trouxe ou se foi a equipe. Não quero ser injusto com ninguém. Sei que veio pro pipeline e que eu testei, organizei e gastei pra caramba.

A ideia é bonita. Foi o Cursor que inovou com aquela lateral pra você conversar com a IA. Por mais que a equipe quisesse, não pagava a conta. Um projeto inteiro que eu rodei em 20 dias, de pau arriado, me custou 500, 700 dólares. Não lembro o valor exato, foi alguma coisa assim.

Obsidian e GitLab: sugestão da equipe, teste em conjunto

"Josimar, o Obsidian, pra controlar as coisas e organizar as ideias." Trouxeram, alguns já estão usando. Eu testei, e está no pipeline.

"Josimar, vamos usar o GitLab e não o GitHub, porque a gente tem mais controle." Isso foi lá atrás, e quem trouxe foi a equipe. Na época eu nem tinha a solidez de conhecimento que eu tenho hoje sobre a minha preferência pelo GitLab. Testamos junto, definimos o pipeline e ficamos com ele. Foi decisão em conjunto. Os motivos que eu tenho hoje estão em por que eu não uso GitHub, Supabase ou Firebase em produção.

Todo dia tem um trem novo, e hype quebra empresa

Com a adoção em massa de ferramenta de inteligência artificial, todo dia aparece um trem diferente. Não dá mais pra ficar testando coisa todo dia.

E eu preciso blindar a minha equipe. Proteger de ficar louca, querendo testar novidade todo dia e trazendo hype pra dentro da empresa. A gente sabe que hype quebra empresa. Hype é feito pra outra coisa.

Pra trazer um negócio sólido pra dentro da empresa e pôr no pipeline, ele tem que ser testado e analisado em três pontos:

• Financeiro. Eu dou conta de pagar essa conta todo mês, pra equipe inteira?
• Ganho real. Produz mais de verdade, ou só é gostoso de usar?
• Visão da empresa. O ganho está de acordo com o caminho que a empresa está seguindo?

Empresa não é caridade, não é igreja, não é ONG. Empresa é um lugar feito pra dar lucro: pro colaborador ter o lucro dele, pra empresa ter o dela, e cada um conquistar o seu objetivo. Eu já escrevi sobre o que acontece quando a decisão é tomada na emoção, em o erro não foi a IA, foi o CEO emocionado.

O dia do mês que eu tiro pra "jogar fora"

Uma vez no mês, às vezes um pouco menos, eu paro. Eu trabalho quase 24x7, um fim de semana ou outro, às vezes todos, porque adoro o que eu faço. E é num desses que eu paro pra testar o que os meninos trazem.

"Tem isso, tem aquilo." Eu vou anotando. Aí eu tiro um dia pra jogar fora e testar direto e reto. Sai coisa boa desse jogar fora. Foi assim que eu descobri várias coisas que hoje estão na nossa rotina.

E foi assim que eu descartei outras. O advisor do Claude eu testei, botei no pipeline e vi que não dava bom pra gente. Pra quem não conhece: é o recurso que a Anthropic documenta como advisor tool, em que o modelo que executa a tarefa consulta um modelo mais forte no meio do caminho. Pra gente não deu bom, e eu só sei disso porque rodei.

Quando eu gravei, o pessoal já falava do Mythos, que nem tinha saído da casinha, e do Qwen 3.7 Max, que eu ainda não tinha testado e ia testar. A fila não acaba, e é por isso que o teste tem dia marcado.

CEO não pode delegar pro CTO e esquecer

Esta é a parte que eu recomendo pra qualquer CEO. Você não pode delegar pro CTO e esquecer.

Se o seu CTO for fã do GitHub, você viu o que aconteceu? Supply chain: mato infectado. E eu tinha acabado de ler que aconteceu mais coisa no repositório do npm. A gente ia ter que checar até as nossas libs, porque não afetou só quem tinha coisa no GitHub. Afetou o npm. Olha o nível a que a gente chegou.

Eu fui atrás do que era público naquela semana, pra você não ficar só com a minha palavra. A Red Hat registrou no boletim RHSB-2026-006 que, em 29 de maio de 2026, uma conta do GitHub comprometida foi usada pra empurrar código malicioso em pacotes de uma organização dela, e que 32 pacotes npm do escopo @redhat-cloud-services foram afetados. Segundo o boletim, nenhum fazia parte de produto lançado. Dias depois, a Snyk descreveu um worm no npm que se espalha sozinho e roda na instalação do pacote, por um arquivo binding.gyp, sem passar pelos scripts de instalação que todo mundo já monitora.

É por isso que eu digo que o CEO não pode delegar e esquecer. Onde o código mora e de onde vêm as dependências é escolha que pesa na empresa inteira: naquela semana eu tive que pôr na lista checar as nossas próprias libs. Eu voltei nesse assunto meses depois, quando o GitHub caiu pela terceira vez.

E se eu não sou técnico?

Então teste as ferramentas do jeito que dá. Se você não é técnico, não tem cabeça pra isso, é um cara de negócio, senta do lado do seu CTO e fala: "me explica. Vou sentar aqui e você vai me mostrar".

Você não está aí à toa. Você entende de muita coisa, não caiu de paraquedas nesse negócio. Então você vai pedir pra ele explicar e vai entender.

"Não tenho CTO, sou eu e os devs." Senta do lado do dev e fala "vamos testar junto". Pede pra ele te explicar e traduzir o que está acontecendo, pra você saber se aquilo entra no pipeline ou não.

Devs: conversem entre si e definam um padrão

Pra quem é dev, o recado é outro: conversem entre si, testem, definam. Cada um usando um padrão diferente é muito ruim pra empresa e até pro crescimento da própria equipe.

Hoje quem coloca o padrão na empresa sou eu. Mas eu testo junto com a equipe e converso com ela. Quando a equipe fala "não, isso aqui realmente é melhor, vai ajudar a gente", eu coloco.

O que eu testo é se eu vou dar conta de pagar, se a conta fecha, se vai ser produtivo. Pra decisão não ter só a visão do dev, só a visão do RH ou só a visão do CTO. Tem que ter a do CEO e a de todo mundo junto.

Nota de cronologia: o Cursor voltou

Gravei isso em 7 de junho de 2026, com o Cursor fora da equipe. Em agosto de 2026 eu testei de novo, por causa do Composer, e ele voltou pro nosso dia a dia. Contei essa volta em eu tinha parado de usar o Cursor, voltei e levei a equipe.

Sair do pipeline não é sentença pra sempre. A ferramenta mudou, eu testei de novo e ela voltou. O que não muda é a ordem: só entra depois de testada.

O que eu faço hoje

Eu testo tudo que entra na empresa, venha da minha equipe ou não, se aquilo vai virar padrão. E recomendo que todo mundo faça isso.

Se você quer ver esse tipo de decisão sendo tomada com a mão na massa, é o que eu mostro na Imersão de Sites: o pipeline real que eu uso pra publicar, atualizar e escalar site em produção.

Perguntas frequentes