Depois de quase oito anos trabalhando na mesma empresa, estou novamente à procura de uma oportunidade profissional.
Por si só, isso já seria uma mudança significativa. Mas existe um pequeno detalhe: estou voltando ao mercado numa época em que a Inteligência Artificial consegue escrever código, criar testes, explicar sistemas, encontrar bugs e, ocasionalmente, inventar uma biblioteca que nunca existiu com absoluta confiança.
Como Senior Full-Stack Developer, não consigo olhar para esse momento apenas com medo ou entusiasmo. Preciso olhar com experiência.
E é daí que surge uma ideia que tenho chamado de vibe architecture.
Antes veio o vibe coding
O vibe coding popularizou uma maneira diferente de desenvolver software: você descreve o que deseja, conversa com uma IA, aceita algumas sugestões, ajusta outras e, depois de vários prompts, alguma coisa aparece no ecrã.
Às vezes é exatamente o que você pediu.
Às vezes é um sistema de autenticação completo quando você só queria mudar a cor de um botão.
É uma abordagem extremamente poderosa para protótipos, experimentação, automação e validação rápida de ideias. A distância entre imaginar uma funcionalidade e vê-la funcionar tornou-se muito menor.
Mas existe uma diferença importante entre:
“Funcionou no meu computador.”
e:
“Pode colocar em produção, processar pagamentos e atender milhares de utilizadores.”
Normalmente, essa diferença chama-se engenharia de software.
Então, o que seria vibe architecture?
Para mim, vibe architecture é usar a velocidade da IA sem abandonar a responsabilidade técnica.
É permitir que a IA ajude a implementar, investigar, documentar e testar, enquanto o engenheiro continua responsável por perguntas como:
- Onde cada responsabilidade deve ficar?
- Como os componentes comunicam entre si?
- O que acontece quando uma dependência falha?
- Como protegemos dados sensíveis?
- Como observamos o sistema em produção?
- Como a aplicação será mantida daqui a dois anos?
- Por que a IA criou seis abstrações para uma função de doze linhas?
Vibe architecture não significa desenhar algumas caixas, adicionar setas e chamar tudo de microsserviço.
Significa transformar intenção em estrutura.
A IA pode gerar uma API rapidamente. Mas alguém ainda precisa decidir se aquela API deve existir, quais limites deve respeitar, como será versionada e o que acontece quando receber cinquenta mil pedidos por minuto.
A IA pode escrever código.
Arquitetura é decidir qual código deveria ser escrito.
A experiência não perdeu valor
Existe uma narrativa recorrente de que a IA tornará desenvolvedores experientes menos necessários.
Eu vejo de outra forma.
Quanto mais código conseguimos produzir, mais importante se torna saber distinguir código útil de código apenas convincente.
Uma pessoa sem experiência pode pedir:
“Crie uma plataforma escalável para milhões de utilizadores.”
Um engenheiro experiente provavelmente perguntará:
“Quantos utilizadores temos hoje?”
Essa segunda pergunta pode economizar seis meses, três microsserviços, dois clusters Kubernetes e várias reuniões sobre custos de cloud.
Depois de anos trabalhando com frontend, backend, APIs, bancos de dados, infraestrutura, integrações, deploys e sistemas em produção, aprendi que o desafio raramente é apenas fazer uma funcionalidade funcionar.
O verdadeiro desafio é fazê-la funcionar:
- com segurança;
- sob carga;
- quando uma dependência está indisponível;
- sem destruir funcionalidades existentes;
- com logs que realmente ajudem;
- e de uma maneira que outro desenvolvedor consiga entender numa segunda-feira de manhã.
IA acelera a implementação. Experiência reduz as decisões erradas.
As duas coisas juntas são muito mais valiosas do que qualquer uma delas isoladamente.
O novo papel do Senior Developer
O Senior Developer da era da IA provavelmente escreverá menos código manualmente em algumas tarefas.
Isso não significa trabalhar menos.
Significa concentrar mais energia em:
- compreender o problema real;
- especificar requisitos com clareza;
- definir limites arquitetónicos;
- criar contexto para agentes de IA;
- validar decisões técnicas;
- revisar código gerado;
- construir estratégias de testes;
- avaliar segurança e privacidade;
- controlar dívida técnica;
- e garantir que velocidade não seja confundida com progresso.
Em outras palavras, deixamos de ser apenas autores de código e passamos também a ser orquestradores de sistemas, contexto e agentes.
O prompt torna-se parte da engenharia.
A especificação torna-se mais importante.
A arquitetura torna-se o guardrail.
E o git diff continua sendo obrigatório, porque confiança é importante, mas revisão de código também.
“Mas a IA fez tudo sozinha”
Uma demonstração de cinco minutos pode criar a impressão de que a IA desenvolveu um produto inteiro sozinha.
Normalmente, ela criou:
- uma interface bonita;
- algumas rotas;
- um banco de dados;
- autenticação;
- e pelo menos uma chave de API exposta no frontend.
Transformar isso num produto confiável exige decisões que não aparecem no vídeo da demonstração.
É necessário pensar em autorização, rate limiting, migrações, recuperação de falhas, auditoria, acessibilidade, monitorização, custos, dependências, licenças, backups e manutenção.
O botão “Generate App” pode gerar a aplicação.
Infelizmente, ainda não existe um botão “Generate Accountability”.
Não quero competir contra a IA
Estar novamente no mercado depois de quase oito anos na mesma empresa naturalmente provoca algumas reflexões.
As ferramentas mudaram. Os processos mudaram. A velocidade mudou.
Mas não acredito que o melhor caminho seja tentar provar que consigo escrever código mais rapidamente do que uma máquina.
Seria como desafiar uma calculadora para uma competição de divisão.
Meu objetivo é mostrar que sei utilizar a IA para entregar software melhor, mais rapidamente e com responsabilidade.
Quero trabalhar em ambientes nos quais a IA não seja tratada nem como mágica, nem como ameaça, mas como uma ferramenta poderosa dentro de um processo de engenharia sólido.
Não quero ser o desenvolvedor que ignora a IA.
Também não quero ser aquele que aceita todo código gerado porque “os testes passaram” — especialmente quando os testes também foram escritos pela mesma IA.
Quero ocupar o espaço entre esses dois extremos.
Os fundamentos continuam vivos
Mesmo com agentes, modelos avançados e desenvolvimento orientado por linguagem natural, algumas coisas continuam surpreendentemente importantes:
- requisitos claros;
- separação de responsabilidades;
- baixo acoplamento;
- testes confiáveis;
- segurança;
- observabilidade;
- documentação;
- revisão;
- simplicidade;
- e bom senso.
A IA não elimina esses fundamentos.
Ela aumenta o impacto de aplicá-los — ou de ignorá-los.
Com ferramentas tradicionais, uma decisão arquitetónica ruim poderia levar semanas para se espalhar pelo sistema.
Com agentes de IA, podemos replicá-la em todo o repositório antes do almoço.
Minha próxima fase
Estou a iniciar uma nova etapa profissional como Senior Full-Stack Developer numa era em que desenvolver software está a ser profundamente transformado pela IA.
Levo comigo quase oito anos de contexto, entregas, incidentes, decisões difíceis, integrações, sistemas legados, deploys e aprendizagem contínua.
Também levo curiosidade.
Quero explorar desenvolvimento assistido por IA, agentes, RAG, avaliação de modelos, guardrails, automação e arquiteturas preparadas para sistemas cada vez mais inteligentes.
Mas pretendo fazer isso sem esquecer uma lição básica:
Software não precisa apenas ser gerado. Precisa ser compreendido, operado e mantido.
Talvez esse seja o verdadeiro significado de vibe architecture.
Não é permitir que a IA escolha toda a arquitetura baseada nas vibes.
É criar uma arquitetura tão clara que humanos e agentes consigam trabalhar juntos sem transformar o repositório num escape room.
A IA pode ajudar a construir o futuro do software.
Mas alguém ainda precisa revisar o pull request.
