Vibe coding e IA: executar não é ter competência

Quando contratas um trabalho profissional, esperas que alguém compreenda o que precisas, faça escolhas que consegues discutir e entregue um resultado em que podes confiar. A facilidade de produzir alguma coisa não resolve nenhuma dessas expectativas.

Hoje, uma pessoa consegue chegar muito depressa a uma apresentação convincente. O aspeto sugere que o trabalho está concluído. As decisões sobre a sua utilidade, os limites e as consequências podem continuar por fazer. É nessa distância entre produzir e saber entregar que encontro o problema.

Uma aplicação pode estar bem desenhada e organizar mal o trabalho. Uma alteração pode ser aplicada sem erro e interromper uma função importante. Uma campanha pode atrair atenção e comunicar uma promessa que a empresa não consegue cumprir. A qualidade inclui adequação, identidade e funcionamento, além da segurança.

A IA é uma excelente ferramenta para ampliar competências. O salto indevido acontece quando a capacidade de a operar é vendida como conhecimento do assunto. Ter acesso à execução não dá, por si só, competência para decidir o que deve ser executado, verificar o resultado e responder por ele.

Já conhecemos esta pergunta: se a ferramenta faz, para que serve o profissional?

A pergunta não começou com os modelos de linguagem. As ferramentas têm vindo a reduzir a dificuldade de executar tarefas que antes exigiam equipamento, aprendizagem ou tempo de produção consideráveis. Vale a pena distinguir essa mudança da conclusão de que o trabalho profissional ficou resolvido.

Em 2009, a Apple apresentou o iPhone 3GS com gravação, corte e partilha de vídeo no telefone. A captação e uma parte da edição cabiam no mesmo aparelho. Isso facilitava produzir um vídeo; a mensagem, os planos necessários, o som e o ritmo continuavam a precisar de decisões.

Em 2013, o lançamento do Canva apresentou uma ferramenta de design com elementos que se arrastavam para a composição. O próprio comunicado incluía utilizações por designers profissionais. Em 2016, a Wix anunciou o ADI, prometendo construir websites a partir de respostas a perguntas simples. São exemplos concretos de execução que se tornou mais acessível.

Perante estas ferramentas, é tentador concluir que deixa de ser necessário contratar quem conhece o ofício. Essa conclusão confunde o acesso ao meio de produção com o domínio do trabalho. Uma composição pronta não responde automaticamente pela marca. Uma página publicada não demonstra que o negócio foi compreendido.

A própria Wix lançou o Studio para agências e profissionais independentes em 2023. Isto mostra que ferramentas de execução acessível e trabalho profissional podem coexistir. Para mim, a consequência prática é adaptar o serviço, escolher onde faz sentido intervir e demonstrar o valor das decisões que a ferramenta não tomou.

A IA deve ampliar uma competência que consegues exercer

Uso IA no desenvolvimento para explorar soluções, acelerar implementação e apoiar revisão. O ganho é relevante quando consigo perceber o que foi proposto, confrontar a resposta com os requisitos e verificar as consequências. Se deixo de conseguir avaliar o resultado, a velocidade deixou de ser uma medida suficiente de progresso.

O mesmo critério aplica-se a modelos como os da família GPT da OpenAI, o Claude da Anthropic e o Gemini da Google, e a ferramentas de desenvolvimento como o Cursor, que integram modelos no trabalho sobre um projeto. A escolha da ferramenta interessa. Continua a ser necessário decidir que contexto lhe dar, que ações permitir e que critérios usar para aceitar a resposta.

Um agente acrescenta ao modelo um ambiente em que pode agir: ler ficheiros, alterar código, executar comandos ou comunicar com serviços. A capacidade de fazer mais coisas aumenta a importância de perceber quais delas fazem sentido e com que autoridade.

O limite profissional que defendo é claro: só deves vender um âmbito que consegues compreender, justificar e validar. Podes recorrer a colaboração especializada quando uma parte do trabalho ultrapassa esse domínio, deixando claras as responsabilidades. O cliente não deve receber uma promessa de competência baseada apenas na expectativa de que a próxima resposta do modelo estará certa.

Aprender continua a exigir experiências, erros e revisão. Fazê-lo num ambiente de teste, com dados fictícios e orientação adequada, permite desenvolver capacidade. Apresentar uma experiência como produto concluído transfere para quem compra o risco de descobrir aquilo que ainda não sabes avaliar.

Numa app, o critério transforma-se em regras verificáveis

Considera uma aplicação de reservas utilizada por duas empresas. Cada uma tem clientes, horários e documentos próprios. A interface mostra um calendário limpo, permite escolher uma hora e confirma a marcação. A apresentação parece concluída.

A primeira decisão é perceber o que significa reservar naquela operação. A marcação pode depender de uma sala, de um profissional disponível e de tempo para preparar a sessão seguinte. Se o sistema desconhece uma dessas condições, pode aceitar uma escolha que a empresa não consegue cumprir, mesmo sem expor dados ou apresentar erros no ecrã.

Eu começaria por escrever condições verificáveis. Se uma sala só pode receber uma sessão de cada vez, duas marcações sobrepostas não podem ser confirmadas. Se dois pedidos chegam ao mesmo tempo, ambos podem ter visto a sala como disponível. Verificar a disponibilidade e confirmar sem proteger esse intervalo deixa uma oportunidade para aceitar os dois.

O controlo tem de existir junto dos dados que decidem a disponibilidade, mantendo a regra válida durante a confirmação. Este é um problema de concorrência, isto é, de ações que chegam ao mesmo tempo. A OWASP recomenda tratar estas condições de corrida nas operações sensíveis. Desativar um botão no ecrã de um utilizador não protege o sistema de outro pedido.

Depois há que verificar quem pode aceder a cada reserva. Autenticação identifica a pessoa; autorização determina se ela pode executar uma operação sobre aquele registo. Numa aplicação partilhada, isso inclui confirmar a empresa a que o registo pertence. Esconder os dados de B na interface de A não impede que A os peça diretamente ao servidor.

Num ambiente de teste autorizado e com dados fictícios, eu exigiria pelo menos estes casos:

1. A conta de A consegue consultar e alterar uma reserva sua.
2. A mesma conta pede uma reserva de B e o acesso é recusado sem divulgar informação.
3. Uma tentativa de alteração mantém os dados de B intactos.
4. Duas tentativas simultâneas de reservar o mesmo recurso respeitam a capacidade definida.
5. As mesmas regras continuam válidas nas exportações, nos anexos e nas tarefas em segundo plano.

Os pagamentos acrescentam outra situação. Se o fornecedor repetir uma notificação após uma falha de comunicação, o sistema tem de reconhecer o evento já tratado e evitar processar a encomenda duas vezes. Esta propriedade chama-se idempotência. Precisa de uma decisão explícita sobre a identificação e o registo dos eventos; a confirmação visual do pagamento não a demonstra.

O trabalho começa na compreensão da operação, passa pela implementação da regra e termina na sua verificação. É assim que explicaria o valor da engenharia de aplicações web, incluindo quando a IA produziu uma parte importante do código.

Gerir uma operação exige saber o que uma alteração pode interromper

Num servidor, o comando pode terminar sem erro e o serviço voltar a arrancar. Isso confirma uma parte da execução. Não responde por todas as funções que dependem daquela máquina.

Considera uma alteração de firewall, o conjunto de regras que permite ou recusa ligações. Um agente pode gerar regras para fechar portas. Sem conhecer as dependências, pode também cortar a ligação usada pelos backups ou pelo serviço que envia alertas. A aplicação continuar a abrir não demonstra que esses percursos continuam operacionais.

Eu exigiria uma sequência explicável antes da execução: identificar as ligações necessárias, guardar o estado anterior, definir uma forma de recuperar o acesso e testar os serviços afetados depois da alteração. Se a mudança pode interromper a sessão remota, a recuperação não pode depender dessa mesma sessão continuar aberta.

A existência de um ficheiro de backup também não demonstra que a aplicação pode ser recuperada. O guia de preparação da CISA recomenda testar as cópias num cenário de recuperação. É preciso verificar, num ambiente separado, se a cópia permite restaurar os dados e retomar o funcionamento necessário. Quem vende gestão de servidores tem de definir quem acompanha estes controlos e atua quando falham.

A mesma lógica aplica-se a um agente que consulta clientes e emite reembolsos. A OWASP documenta o risco de prompt injection: instruções introduzidas numa mensagem ou num documento podem desviar o comportamento do modelo. O risco ganha consequências operacionais quando esse modelo dispõe de ferramentas capazes de agir.

A operação de reembolso precisa de verificar utilizador, organização, encomenda, limite e autorização fora do modelo. Um pedido para agir com cuidado no prompt não implementa essas regras. A minha recomendação é limitar permissões e exigir aprovação nas ações cujo impacto o justifique. O artigo sobre instruções maliciosas indiretas em agentes desenvolve esse problema.

Automatizar uma operação transfere ações para uma ferramenta. A responsabilidade de definir os limites, observar o funcionamento e saber recuperar continua a precisar de alguém competente.

A aparência e as métricas podem esconder uma entrega desajustada

A qualidade profissional também se perde em trabalhos que não têm uma vulnerabilidade técnica evidente. Um resultado pode ser seguro, visualmente cuidado e inadequado ao público ou à identidade da empresa.

Imagina uma empresa de instalação que só serve determinados concelhos e precisa de visitar o local antes de apresentar orçamento. Uma campanha pode gerar muitos formulários ao prometer um preço imediato. Se atrair pessoas de fora da área ou criar a expectativa de uma proposta sem visita, está a otimizar uma ação que a operação não consegue cumprir. O painel pode mostrar contactos baratos enquanto a equipa perde tempo a desfazer a promessa do anúncio.

Eu começaria por definir o que conta como contacto útil: serviço adequado, localização atendida, informação suficiente para avançar e uma expectativa que a empresa pode cumprir. Depois verificaria a passagem do anúncio para a página e da página para quem recebe o pedido. A avaliação acompanharia os contactos até à qualificação, em vez de terminar na contagem dos formulários.

Gerar títulos e descrições também não resolve uma estratégia de pesquisa. É preciso compreender as perguntas do público e organizar conteúdo que lhes responda. Desenvolvemos a escolha de objetivos no artigo sobre SEO e publicidade paga. A ferramenta pode ajudar na execução depois de existir uma hipótese de trabalho que se consegue testar.

Na comunicação visual, a pergunta é que identidade e que promessa o material precisa de transmitir. Um logótipo convincente isoladamente pode ser indistinto dos concorrentes; uma interface bonita pode destacar a ação errada. A Joana Vidal desenvolve essa diferença no artigo sobre design com IA, identidade de marca e critério profissional.

No design de produto, uma imagem deixa por verificar o uso e as condições de produção. Na videografia, uma sequência cuidada ainda precisa de mensagem, ritmo e contexto de exibição. Há decisões próprias de cada ofício que não ficam resolvidas por gerar um material plausível.

Mesmo na interface, a apresentação não confirma a utilização. Consegues completar o formulário com teclado? Percebes por que razão um campo foi recusado? A W3C alerta para os efeitos de ARIA mal aplicado, porque acrescentar atributos de acessibilidade sem os comportamentos esperados pode piorar a experiência. É preciso observar o percurso, não apenas reconhecer os elementos no ecrã.

Nos projetos sujeitos ao RGPD, é preciso identificar quem decide o tratamento dos dados pessoais e quem os trata por sua conta. O EDPB explica essas funções e responsabilidades. Um aviso de privacidade gerado não resolve essa análise; desenvolvemos o tema no artigo sobre RGPD na prática.

Ser valorizado exige tornar o critério visível e adaptar a oferta

O profissional tem de acompanhar a mudança. Se uma ferramenta reduz o esforço de execução, repetir a oferta anterior e esperar que o cliente pague pela mesma dificuldade deixa uma parte importante da conversa por fazer.

Há tarefas que passam a ser executadas pelo próprio cliente. Há outras em que a assistência de IA pode reduzir tempo de produção. A resposta profissional é perceber que problemas consegue resolver melhor, para quem são relevantes e como demonstra esse trabalho. Pode ser necessário mudar de especialização, de âmbito ou de tipo de cliente.

Um negócio que precisa de organizar reservas entre equipas tem exigências diferentes de quem procura apenas publicar informação. Uma empresa com vários serviços e mercados pode precisar de coerência de marca e critérios editoriais que outra ainda não tem de gerir. Escolher um segmento deve partir de necessidades reais e da capacidade para lhes responder. Inventar complexidade para justificar preço também falha esse princípio.

A valorização começa por apresentar melhor as decisões. Mostra que informação procuraste, que alternativas comparaste, o que excluíste e porquê. Explica os critérios de aceitação e entrega exemplos dos testes relevantes. Quando a ferramenta poupou tempo, usa essa vantagem para melhorar o resultado ou tornar a proposta mais eficiente; não precisas de fingir trabalho manual para dar legitimidade ao serviço.

Um amigo que abriu recentemente um negócio recebeu, num mês, várias propostas de websites já construídos, antes de uma conversa sobre as suas necessidades. Esse caso ilustra a ordem invertida: primeiro produz-se alguma coisa e depois procura-se o negócio que a compre. Apresentar como pronta uma solução que não se procurou adequar é uma falha de serviço. O cliente fica encarregado de descobrir omissões que o profissional deveria saber identificar.

O critério aplica-se além desse exemplo. Quando vendes um âmbito que não consegues explicar ou validar, atribuis à tua própria aprendizagem menos importância do que o trabalho merece e transferes o risco para outra pessoa. A confiança no serviço exige que saibas reconhecer onde termina a tua autonomia, pedir revisão e recusar uma promessa que ainda não podes sustentar.

Na Webxtek Studio, é essa a função que atribuo à consultoria técnica: enquadrar a decisão antes de aumentar a quantidade de software. Para quem compra, a competência precisa de se tornar observável. Para quem presta o serviço, precisa de existir antes da venda.

O preço tem de corresponder a um trabalho que se consegue explicar

Um orçamento deve permitir perceber a necessidade identificada e o compromisso de entrega. A rapidez da geração não determina, sozinha, o valor desse compromisso. Também não autoriza cobrar por validação ou acompanhamento que não foram feitos.

O preço não se justifica por invocar experiência de forma abstrata. Justifica-se tornando claro o trabalho necessário, a capacidade de o executar e a responsabilidade que se assume. Um resultado bonito e cheio de pressupostos por verificar não se transforma numa entrega concluída por se emitir uma fatura.

A minha posição é exigir competência antes de vender o serviço e tornar essa competência mais útil através da IA. As ferramentas mudam o esforço de produzir e obrigam a rever a oferta. O profissional precisa de continuar a aprender, escolher problemas que domina e demonstrar por que razão as suas decisões merecem confiança.