Quem já fez obras em casa conhece a regra sem a ter lido em lado nenhum: pintar uma parede faz-se ao fim de semana; mudar uma tomada, com cuidado, também; mexer no quadro elétrico ou deitar abaixo uma parede é outra conversa — precisa de quem saiba, e às vezes de projeto e licença. O critério não é o tamanho da casa. É o que acontece se correr mal, e quanto custa aprender a fazer bem.
Com a IA passa-se o mesmo, e a diferença de 2026 é que as ferramentas de "fazer sozinho" ficaram muito boas. Um gestor sem formação técnica consegue hoje, com o Codex, o Claude Code ou o Copilot, construir uma automação, um protótipo ou uma análise que há dois anos exigia uma equipa. Isso é verdade e é bom. Também é verdade que nunca foi tão fácil construir uma coisa que funciona na demonstração e que ninguém consegue manter três meses depois.
Este artigo é uma tentativa honesta de responder à pergunta que nos fazem todas as semanas: "isto fazemos nós ou precisamos de ajuda?" — incluindo os casos em que a resposta certa é "façam vocês", que são muitos.
O que estas ferramentas mudaram
Vale a pena separar três coisas que costumam vir misturadas.
Assistentes no editor. O GitHub Copilot nasceu como sugestão de código dentro do IDE e hoje também responde a perguntas sobre o código e executa tarefas — mas o seu lugar natural é ao lado de quem programa, a acelerar o que essa pessoa já sabe fazer. Se não há ninguém a programar, não há a quem sugerir.
Agentes de código. O Codex da OpenAI e o Claude Code da Anthropic são outra categoria: recebem uma tarefa ("liga este formulário à base de dados e envia um email quando chega um pedido"), leem o projeto, escrevem o código em vários ficheiros, correm os testes e devolvem o resultado. Funcionam no terminal, no editor, na nuvem. É isto que permite a alguém sem equipa técnica construir coisas reais.
Os modelos por trás. Os mesmos LLMs que alimentam estas ferramentas estão disponíveis por API para construir produtos e automações. É outro nível de trabalho, e o único em que as ferramentas de "fazer sozinho" não chegam por si.
O que as três têm em comum: baixaram brutalmente o custo de começar. Não baixaram o custo de manter, de integrar nem de responder quando algo falha com dados de clientes lá dentro.
Quando fazer sozinho é a resposta certa
Há mais casos do que uma consultora gostaria de admitir. Estes são os que vemos funcionar bem sem ajuda externa:
Uso pessoal e da equipa. Resumir reuniões, preparar a primeira versão de um documento, analisar uma folha de cálculo, escrever um email difícil. Não há integração, não há dados de terceiros a sair da empresa (desde que a ferramenta seja a certa — ver abaixo), e o único risco é perder uma hora. Façam.
Protótipos para decidir. "Será que um assistente sobre a nossa base de conhecimento serve para alguma coisa?" A melhor forma de responder é construir um em dois dias com um agente de código e mostrá-lo a três pessoas. Um protótipo assim vale mais do que um estudo de viabilidade de quarenta páginas — e se depois se decidir avançar a sério, o protótipo é o melhor briefing que uma consultora pode receber.
Processos internos de baixo risco. Um script que renomeia ficheiros, uma automação que compila um relatório semanal a partir de três fontes, um formulário interno. Se falhar, alguém repara e faz à mão. Não vale a pena envolver ninguém de fora.
Equipas técnicas que só precisam de acelerar. Se já há programadores, o Copilot ou o Claude Code são ferramentas de produtividade, não um projeto. Cabe à equipa adotá-los — com um aviso, mais à frente, sobre o que os estudos dizem.
Quando o objetivo é aprender. Há empresas que querem que a equipa perceba o que a IA faz e não faz antes de decidir onde investir. Construir coisas pequenas, com as mãos, é a melhor formação que existe. Nenhum curso substitui isso.
O que estes casos têm em comum: o custo de errar é baixo, os dados são os vossos e nada depende daquilo para funcionar amanhã de manhã.
Quando fazer sozinho sai caro
Os sinais de que a obra já não é de fim de semana:
Dados de clientes. No momento em que a solução toca em nomes, emails, contratos, faturas ou histórico de compras, há RGPD, há subcontratantes, há a pergunta "para onde é que isto vai?" A maior parte dos problemas que vemos em soluções feitas em casa não é o código — é o modelo a receber dados que não devia, sem ninguém ter decidido isso.
Integração com sistemas críticos. ERP, CRM, faturação, banco. Um agente de código escreve a integração em meia hora; o que ele não sabe é que a tabela de clientes tem três campos legados que ninguém documentou, que o ERP rejeita atualizações fora de horas e que a sincronização a correr duas vezes duplica faturas. Quem já partiu uma integração dessas sabe o que custa.
Processos que atravessam equipas. Se a solução muda a forma de trabalhar de comercial, operações e financeiro ao mesmo tempo, o problema deixou de ser técnico. É desenho de processo, é gestão da mudança, é decidir quem faz o quê. Nenhuma ferramenta de código resolve isso.
"Funciona no meu portátil." A solução vive na máquina de uma pessoa, com uma chave de API pessoal, sem controlo de versões, sem ninguém que a perceba se essa pessoa sair. É o equivalente a uma instalação elétrica improvisada: funciona até ao dia em que não funciona.
Sem métrica de resultado. Construiu-se porque era possível. Ninguém definiu o que devia mudar — tempo, custo, erros, receita — nem está a medir. Ao fim de seis meses, ninguém sabe se valeu a pena.
Sem ninguém para manter. Os modelos mudam, as APIs mudam, os preços mudam. Uma solução com IA não é uma folha de cálculo: precisa de alguém que a acompanhe. Se essa pessoa não existe, a solução tem prazo de validade.
E há o aviso que prometemos sobre equipas técnicas. Um estudo da METR de 2025, com programadores experientes em projetos open-source reais, mediu o que ninguém esperava: com ferramentas de IA, demoraram 19% mais tempo a fechar as tarefas — e continuaram convencidos de que tinham sido 20% mais rápidos. O relatório DORA de 2024 aponta na mesma direção: a IA aumentou a produtividade individual e a satisfação, mas piorou a estabilidade e o débito das entregas. A lição não é "não usem"; é que a sensação de velocidade não é velocidade, e que sem processo à volta a ferramenta acelera a pessoa e trava o sistema.
O meio-termo que resulta
Na prática, a escolha raramente é binária. Os dois modelos híbridos que mais vezes funcionam:
Diagnóstico externo, execução interna. Alguém de fora mapeia o processo, identifica onde a IA vale a pena e onde não vale, define métricas e desenha a solução — e a equipa constrói com as ferramentas de agente. A empresa fica com o conhecimento; a consultora entra onde a experiência conta (saber o que costuma correr mal) e sai antes de se tornar uma dependência.
Piloto interno, escalar com ajuda. A equipa constrói o protótipo, prova que há valor, e só depois entra quem vai tornar aquilo robusto: integração, segurança, dados, monitorização, formação. É a versão de "pintei a sala sozinho, chamei o eletricista para o quadro".
Em ambos, a pergunta a fazer à consultora é a mesma: "quando é que saem?" Se a resposta for vaga, é sinal de que o modelo de negócio é ficar.
As ferramentas, sem preços
Os preços mudam de mês para mês e ficam desatualizados antes de este artigo ser lido; para estimar custos de utilização, temos um guia de custos de IA atualizado. O que não muda tão depressa é o posicionamento de cada uma:
- GitHub Copilot — o mais integrado no fluxo de quem já programa (editor, GitHub, revisão de código). A escolha natural para equipas técnicas que querem acelerar sem mudar de ferramentas.
- OpenAI Codex — agente de código com CLI, extensão para o editor e ambiente na nuvem; executa tarefas inteiras, incluindo em paralelo, e integra-se com o ecossistema da OpenAI.
- Claude Code — agente de código que lê o projeto todo, edita ficheiros, corre comandos e se liga a ferramentas externas (documentos, tickets, bases de dados) por MCP; disponível no terminal, no editor, em app e no browser.
Para quem não é técnico e quer construir protótipos ou automações, os dois agentes (Codex e Claude Code) são o ponto de partida; o Copilot pressupõe um programador na cadeira. Para quem já tem equipa, qualquer um serve — o que decide é o que a equipa já usa.
Uma nota que vale para as três: ler o que cada uma faz com os dados que lhe são dados (o código, os documentos, o que é escrito nos prompts) e escolher os planos de empresa quando há dados de clientes envolvidos. É a diferença entre pintar a parede e mexer no quadro elétrico.
Matriz de decisão
Três perguntas, e a resposta sai quase sozinha.
| Risco baixo (dados internos, reversível) | Risco alto (dados de clientes, sistemas críticos, dinheiro) | |
|---|---|---|
| Capacidade interna (há quem construa e mantenha) | Fazer sozinho. Ferramentas de agente, métrica definida, revisão ao fim de um mês. | Diagnóstico externo, execução interna. Alguém de fora desenha e define os limites; a equipa constrói. |
| Sem capacidade interna | Fazer sozinho para aprender, com âmbito pequeno. Protótipos, automações pessoais, sem integração. | Consultoria com data de saída. Diagnóstico, implementação até estar a funcionar, formação da equipa para manter. |
A terceira pergunta é a urgência: se o resultado é preciso em semanas e não há capacidade interna, o custo de aprender pelo caminho é maior do que o custo de quem já fez.
O que perguntar a uma consultora antes de assinar
Se a matriz apontou para ajuda externa, estas perguntas separam quem acelera de quem vende horas:
- "O que é que vão decidir que não fazer?" Uma boa consultora tira coisas do âmbito. Uma má aceita tudo.
- "Qual é a métrica, e quando a medimos?" Se a resposta é "produtividade" sem número, não há métrica.
- "O que é que fica connosco no fim?" Código, documentação, acessos, e uma equipa que saiba manter. Se ficam dependências, ficam faturas.
- "Quando é que saem?" Uma data, ou um critério. "Quando estiver a funcionar" é uma resposta aceitável se vier com a definição de "a funcionar".
- "Mostrem-me um caso em que disseram a um cliente para não usar IA." Quem nunca o disse ou não tem experiência ou não é honesto.
- "Quem faz o trabalho?" As pessoas que apresentam a proposta são as que vão executar? Se não, quem, e com que experiência em processos como o nosso?
- "O que acontece quando o modelo muda?" Os fornecedores retiram modelos, mudam preços, mudam comportamentos. Quem acompanha isso depois?
A nossa resposta a estas perguntas está em como trabalhamos: decidimos o que muda, ficamos até estar a funcionar, com entregas semanais e uma data de saída. Se a resposta certa para o caso for "façam vocês", é o que dizemos — e o diagnóstico gratuito serve precisamente para descobrir isso antes de haver contrato.
Perguntas frequentes
Consigo construir uma automação com IA sem saber programar? Com um agente de código como o Codex ou o Claude Code, sim, para casos de âmbito pequeno e risco baixo: automações internas, protótipos, análises. O que não se consegue sem experiência é integrar com sistemas críticos, garantir a proteção de dados e manter a solução quando os modelos mudam.
Copilot, Codex ou Claude Code — qual escolher? Se há programadores, o que a equipa já usa; o Copilot é o mais integrado no fluxo de quem programa. Se não há, os agentes (Codex, Claude Code) são o ponto de partida, porque executam tarefas inteiras a partir de uma descrição.
Quando é que uma consultora se justifica? Quando os dados são de clientes, a solução toca em sistemas críticos, o processo atravessa equipas, ou o resultado é preciso em semanas sem capacidade interna. E deve entrar com data de saída.
Os estudos dizem que a IA torna os programadores mais lentos? Um estudo controlado da METR (2025) mediu programadores experientes 19% mais lentos com ferramentas de IA, embora se sentissem mais rápidos; o DORA 2024 viu produtividade individual a subir e estabilidade das entregas a descer. A conclusão é que a ferramenta sem processo acelera a pessoa e trava o sistema — não que não se deva usar.
O protótipo que fizemos internamente serve para alguma coisa se depois chamarmos ajuda? Serve para muito: prova que há valor, mostra o processo real e é o melhor briefing possível. O que normalmente não serve é o código do protótipo, que foi feito para demonstrar e não para durar.
Fontes
Escreve sobre IA aplicada, operação, GEO/SEO e como transformar empresas em máquinas que continuam a funcionar mesmo quando ninguém está a olhar.