IA na prática: 20 respostas diretas

Apps desse tipo (o Duet, que mostra seus agentes e projetos no celular, é um exemplo) funcionam bem para quem já tem as ferramentas conectadas por servidores MCP (conectores que deixam o assistente de IA usar outros programas, como e-mail, agenda ou planilha) e quer acompanhar os projetos longe do computador.

O risco é o contrário: abrir o app e encontrar dezessete avisos de coisas que você ainda não fez. Em vez de organizar, isso aumenta o estresse.

A alternativa é abrir de propósito a sessão do assistente em que você quer trabalhar agora, sem que todos os projetos pela metade fiquem chamando sua atenção.

Com os dois aplicativos abertos, você pede ao Codex que acompanhe o Claude: conferir o que ele produziu, navegar, responder uma pergunta, abrir outra sessão ou destravar algo que parou durante a noite.

O que faz isso funcionar é o contexto que você entrega: o objetivo e quais decisões você tomaria no lugar dele.

Atenção: para agir na tela, o Codex precisa de permissão para controlar o computador (mouse, teclado, janelas). Dê essa permissão só numa máquina e numa conta sem dados sensíveis abertos, e acompanhe as primeiras vezes.

Dá para coordenar os dois também pela linha de comando, mas os apps de desktop já resolvem sem manter mais um sistema.

Um exemplo: tirar os testes automáticos do GitHub Actions (o serviço do GitHub que roda tarefas na nuvem e cobra pelo tempo) e passar para computadores próprios do escritório. Pelo terminal (com o Warp, por exemplo, que acessa outras máquinas da rede), dá para ver cada pedido que chega e garantir que cada tarefa roda no computador certo.

Numa construção comum não é preciso acompanhar cada linha de código. Basta que o resultado funcione e os testes certos passem.

Ninguém precisa copiar a configuração de ninguém. Cada pessoa vai ter sua combinação de ferramentas; o que importa é que elas conversem entre si.

A capacidade atual dos modelos já basta para muito trabalho útil. O ponto de atenção é outro: quem já sabe atacar sistemas passa a fazer isso com mais automação e em escala muito maior.

Ao mesmo tempo, empresas continuam lançando aplicativos que não entendem por completo.

Por isso faz sentido dedicar mais tempo a proteger o que já foi construído, ajudar empresas a enxergar seus riscos e preparar o próprio negócio para um ambiente mais difícil.

Quem só desenvolve já sente a pressão: em sites de freelancer aparecem projetos complexos oferecidos por valores muito baixos. Se a única proposta é “eu construo isso com IA”, você disputa com cada vez mais pessoas e ferramentas.

As empresas continuam precisando de alguém que entenda o que elas querem alcançar, saiba onde vale investir, encontre os problemas e ensine a equipe a usar as ferramentas do jeito certo.

Bons clientes de desenvolvimento ainda existem. Mas a atenção vale mais em consultoria empresarial e treinamento de equipes.

Começar com recursos próprios (o chamado bootstrap) mantém o controle na sua mão.

Se precisar de investidor, um critério prático para o prazo: conte quantos meses faltam até a próxima meta que torna a empresa claramente mais valiosa (receita, clientes, produto pronto) e some uma folga de uns seis meses para atrasos. Teste esse prazo no cenário pessimista; se não fechar, o caixa é curto. Se a sua conta der entre 18 e 24 meses, prefira 24: hoje a captação costuma demorar mais do que o planejado.

Mais dinheiro dá margem para atravessar um período ruim, mas uma rodada grande com condições sufocantes cria outro problema. Ao comparar propostas, seja de investidores-anjo (pessoas que investem o próprio dinheiro em empresas no começo) ou de fundos de capital de risco (gestoras que investem dinheiro de terceiros em empresas que podem crescer rápido), lembre que de onde vem o dinheiro, o que esperam dele e quanto controle você mantém pesam tanto quanto o valor anunciado.

Responda com números: quais são os custos fixos por mês? Quanto custa crescer? Se o produto ganhar mais clientes, quanto sobe a conta de infraestrutura? Quanta folga você precisa para atrasos ou para um contrato que demora mais que o previsto?

Faça a simulação otimista e a pessimista. Depois pergunte se vai precisar de outra rodada.

Cuidado com a armadilha da avaliação (quanto o investidor diz que a empresa vale): captar com avaliação alta e depois precisar de dinheiro com avaliação menor faz você entregar muito mais da empresa do que esperava. A maior rodada disponível nem sempre é a melhor.

Um ritmo prático é dividir em níveis: uma verificação rápida semanal e uma análise mais profunda mensal.

Um terceiro nível, com testes bem mais abrangentes (e mais caros), pode entrar a cada trimestre. Esse nível completo ainda exige um especialista ou uma ferramenta avançada; enquanto isso, um especialista contratado pode fazer esse papel.

Com o tempo, guarde os padrões encontrados em cada rodada: assim os testes ficam mais úteis e você não precisa explicar a mesma abordagem ao agente toda vez.

“Modelo sem censura” é um modelo de IA em que alguém removeu as travas que o fazem recusar pedidos arriscados. Só isso não o transforma numa ferramenta de segurança: o software em volta do modelo define quais ferramentas ele pode usar, o que ele memoriza, como dá seguimento a uma descoberta e o que tenta quando uma abordagem falha.

Um sistema feito sob medida para testes de segurança dá ao modelo um fluxo de trabalho muito mais útil que uma janela genérica de bate-papo. Palestras de conferências de segurança, como a Black Hat, são uma boa base para ver como esses agentes e suas ferramentas são montados.

Por isso vale separar sempre o modelo da estrutura que o envolve: o mesmo modelo dá resultados muito diferentes conforme o sistema é construído.

Rodar por conta própria dá mais controle sobre a configuração. Um serviço hospedado cuida da infraestrutura e cobra por essa comodidade. O RunPod, um serviço que aluga por hora computadores com placa de vídeo (GPU) potente, é uma opção para hospedar o modelo quando sua máquina não dá conta.

Separe onde o modelo roda de onde as ferramentas rodam. Pôr o modelo na nuvem não leva automaticamente o resto do fluxo de testes junto.

E sempre: testes só com permissão do dono do sistema e com o escopo (o que pode e o que não pode ser testado) combinado por escrito antes de começar.

Os modelos de ponta entendem melhor o que você quis dizer, então dá para deixar mais coisas subentendidas.

Com modelos menores, funciona dar objetivos mais claros, mais contexto e mais direção quando eles empacam.

Num trabalho de segurança, tudo começa pela pergunta específica do cliente: os dados dos clientes estão expostos? Uma trava de pagamento pode ser burlada? Ou é uma análise geral? São trabalhos diferentes, e o pedido e o escopo precisam refletir isso.

Pense num teste autorizado numa loja virtual pequena: o agente tenta comprar um produto mudando o preço no meio do caminho.

Há uma diferença grande entre o agente tentar algo e provar que funcionou. Ver uma tentativa de alterar um preço não prova que o servidor (o computador da loja que registra o pedido de verdade) aceitou a alteração.

Durante os testes o sistema junta informação: uma abordagem que falhou pode revelar um endereço ou detalhe que vale investigar na próxima tentativa. Na prática, ainda vale ter uma pessoa orientando o agente; anote o que funcionou para repetir o teste sem explicar tudo de novo.

Construir algo sem olhar os detalhes de engenharia e inspecionar um sistema atrás de falhas são atividades muito diferentes. Segurança exige atenção aos detalhes.

Virar desenvolvedor e depois se requalificar em segurança dá muito trabalho — e pode nem ser do seu interesse.

Algumas pessoas se dão melhor ensinando, prestando consultoria ou ajudando empresas a perceber quando precisam de um especialista. Escolha a função antes de encarar mais um currículo longo.

Boa parte do aprendizado vem de testar os próprios aplicativos e ler, passo a passo, o que o agente tentou.

Quando aparecer algo que você não entende, pare e investigue: o que significa esse termo? Por que ele tentou esse caminho? O que impediria esse problema?

Decida também se o interesse é segurança ofensiva (atacar para achar falhas, com autorização) ou defensiva (proteger) — os cursos são diferentes. E seja transparente com clientes sobre a sua experiência: não ter certificação não é problema, fingir ser especialista em tudo é.

Uma abordagem melhor: empresas do setor deles estão enfrentando certos problemas — eles gostariam de ajuda para verificar se isso os afeta também?

Dê um motivo para a conversa. Peça permissão. Explique o que você pode examinar e para o que está qualificado.

Chegar dizendo “encontrei todos os seus defeitos” é um péssimo começo de relacionamento.

A empresa pode já ter uma ferramenta que atende tudo o que ela precisa. Dizer que a sua versão personaliza mais pode não fazer diferença para ela.

Um sistema empresarial de base serve para as pessoas construírem em cima — não é promessa de que toda empresa precisa de alguém para instalar exatamente aquilo.

A oferta fica mais forte dentro de um serviço maior: entender o negócio, descobrir o que está faltando e entregar o sistema se ele resolver esse problema. Mais um recurso, por si só, não cria demanda.

Primeiro, os nomes: a API é a porta que o seu sistema oferece para outros programas conversarem com ele. O servidor MCP (o conector usado pelos assistentes de IA) e a CLI (a versão de linha de comando, usada no terminal) são dois jeitos de usar essa mesma porta.

Escreva no AGENTS.md (o arquivo de instruções que os agentes de programação leem ao abrir o projeto) uma regra simples: quando a API mudar, confira o servidor MCP e a CLI e aplique as mudanças necessárias.

A API é a base de que essas interfaces dependem. Mudar a base e esquecer o que foi construído em cima vira problema de organização e manutenção.

Cada lançamento só termina quando as interfaces ligadas a ele também receberam a mudança.

Alguns provedores de IA têm programas para profissionais de segurança: você se identifica, explica o trabalho e o provedor libera um uso mais amplo, com regras e acompanhamento. Um modelo com as travas removidas não tem nada disso.

No trabalho defensivo, deixe claro o que é seu, o que o cliente autorizou e o que você está testando. Não espere que o provedor adivinhe o contexto de um pedido ambíguo.

Uma diferença prática: no programa do provedor, você paga pelo uso e ele cuida da hospedagem; o modelo próprio você mesmo hospeda e mantém.

Tenha um motivo para o projeto de treino. Um modelo pequeno para uma tarefa específica é uma proposta bem diferente de tentar criar mais um modelo de uso geral.

Para a maioria, o caminho mais útil é aprender a adaptar modelos que já existem e tirar deles o comportamento que você precisa.

E desconfie das afirmações sobre modelos que “melhoram sozinhos”: nem toda promessa desse tipo prova que isso já acontece do jeito que as pessoas imaginam.

Parâmetros são os “números aprendidos” do modelo; quanto mais parâmetros, mais memória ele ocupa. Uma regra prática aproximada é reservar para o modelo cerca de metade da RAM — aqui, uns 24 GB. É uma regra conservadora para começar (o Mac até permite usar mais), não um limite técnico.

A conta: na versão comprimida mais comum (quantizada em 4 bits), cada bilhão de parâmetros ocupa por volta de 0,6 GB. Um modelo de 20 bilhões fica perto de 12 GB, e o resto dos 24 GB cobre a memória da conversa. O sistema e os outros programas continuam com a outra metade.

Não escolha de cara o maior modelo que cabe na máquina: com folga, o computador continua usável enquanto o modelo roda. Em Mac, procure a versão MLX do modelo, feita para os chips da Apple.