Depois que o uso de LLMs chegou para o grande público em meados de 2021, era questão de tempo até que elas se integrassem cada vez mais ao nosso cotidiano. O que não esperávamos era que essa adoção fosse tão rápida, impactando basicamente todos os setores. De lá para cá, tivemos Codex, Copilot, Claude e, a cada dia que passava, estávamos correndo para um cenário que é justamente o que encontramos hoje: agentes capazes de executar aplicações inteiras usando linguagem natural.
A popularização do vibe coding
Aplicações utilizando “vibe coding” — termo popularizado por Andrej Karpathy, cofundador da OpenAI, no início de 2025 — se tornaram algo muito comum na rotina de muitos devs. Para muitos, isso foi vendido como um grande facilitador. A ideia era simples: qualquer um poderia fazer código; bastava conversar, ter força de vontade e, com isso, você teria uma aplicação de milhões na sua mão. Em um primeiro momento, isso pode até parecer verdade. Até porque, se tem uma coisa que acontece muito na programação, é algo funcionar mesmo que não tenha sido feito da maneira ideal.
Oras, se uma consulta demora 1200ms ou 25ms, ambas estão funcionando, não é mesmo?
Até quando “fazer funcionar” realmente faz sentido?
É justamente aqui que mora o risco. Quando se vende a ideia de que “funcionar” basta, a discussão sobre arquitetura, performance, segurança, manutenção e boas práticas começa a parecer secundária. E não é. Nos últimos poucos meses, tivemos vários casos de influenciadores que colocavam o terror dizendo que “acabou pros devs”, sendo hackeados logo em seguida.
O pessoal da Escape Research Team conseguiu encontrar, em 5.600 apps publicamente disponíveis, mais de 2.000 vulnerabilidades, mais de 400 secrets disponíveis e diversos outros dados sensíveis de usuários expostos. Esse tipo de dado serve como alerta para uma questão bem simples: acelerar entrega sem critério técnico cobra um preço.
O que esse cenário exige de nós
É inegável que não temos conhecimento de tudo, e nem podemos esperar que teremos tempo suficiente para fazer nossas entregas do jeito ideal sempre. Mas também precisa ficar claro que, mais do que nunca, precisamos ter conhecimento sólido das bases de arquitetura, boas práticas, system design, Big O e por aí vai. Até porque, para chegar a bons resultados, precisamos saber guiar muito bem os agentes. Mas não apenas isso. Também precisamos saber revisar, questionar, validar e sustentar tecnicamente aquilo que foi gerado.
Neste cenário, resta a nós, desenvolvedores, entendermos o que podemos fazer para tirar proveito do avanço das LLMs, sem abrir mão de uma aplicação manutenível, segura e tudo isso em uma janela de entrega cada vez menor. Porque, no fim, vibe coding pode sim ser um facilitador, mas que sem base técnica é só uma bola de neve de problema.
Os agentes evoluíram, e o seu fluxo de desenvolvimento?
O começo do desenvolvimento com IA era bem caótico: o chat ficava separado do código, o termo “engenharia de prompt” não era levado a sério e o contexto pro robô trabalhar era: “resolve aí”. Depois o Copilot se integrou no nosso fluxo de trabalho e as coisas ficaram mais simples, principalmente por conta do autocomplete. A integração não era tão fluída, mas já ajudava ter uma LLM mais próxima ao código.
Então o Cursor lançou e fez uma integração muito mais robusta, podendo arrastar arquivos, referenciar eles com mais facilidade, escolher diversos modelos, e funcionava tudo muito bem principalmente pelo fato de o próprio editor procurar entender arquivos adjacentes àquele que você estava mexendo. Hoje, com o Cursor 3.0, o código possui uma atuação secundária: o objetivo é conversar, explanar, corrigir, melhorar e tudo acontece por trás dos panos.
Diferente de alguns anos atrás, nosso problema não é mais puramente capacidade tecnológica: os agentes não são burros, não são incapazes, pelo contrário. O ponto é que precisamos também nos modernizar. Amadurecer nosso processo, melhorar nossa metodologia. Qual o próximo passo?
Spec Driven Development
Agentes trabalham melhor quando possuem diretivas claras, sem ambiguidade, com caso de sucesso, casos de borda, resultados inválidos e especificações bem definidas do problema.
O desenvolvimento baseado em especificações, como o nome já diz, aborda o processo de forma em que, antes da implementação, deve haver uma especificação clara do problema, do que fazer para resolvê-lo e como iremos implementar as soluções. Não é uma abordagem formalmente definida, então os nomes podem variar, mas a ideia é essa. O ponto aqui é acabar com dúvidas que geralmente acontecem durante o desenvolvimento, já que o briefing antes da implementação não foi tão claro. E melhor do que isso: desenvolver uma documentação daquela implementação para discussão interna ou até mesmo como histórico de futuras especificações.
O ciclo de uma spec
O ciclo de uma spec, em linhas gerais, se define como:
Especificação: definição do problema, contexto base, o que fazer para corrigir.
Planejamento: definição de como resolver, quais tecnologias, arquitetura, bibliotecas e contratos, modelos/entidades e afins.
Análise: revisar o processo para verificar lacunas, ambiguidades, defeitos na solução e afins.
Quebra em tarefas: segmentação da resolução em pequenas tarefas que devem ser implementadas para resolver o problema.
Implementação: execução de todo o processo definido até aqui: neste estágio, todos os requisitos, cenários, tasks e tecnologias já estão documentados para o agente.
Com esse processo, conseguimos chegar em um resultado mais rápido, documentado, com testes e muito mais previsível. Nas próximas postagens iremos ver diferentes frameworks e como eles se diferem.
