SABER PROGRAMAR NÃO É SOBRE ESCREVER CÓDIGO...

Introdução

O problema não está no 'vibe coding', o grande problema está na pessoa, se ela de fato entende o que IA está entregando de código. Observa-se uma mudança de paradigma na função do programador, que, independentemente do seu nível de senioridade, assume o papel de analista de sistemas. Sua responsabilidade primordial migra da escrita de código para a revisão de código (code review), estimando-se que esta ocupe 90% de seu tempo, restando 10% para a codificação. Recomenda-se, inclusive para profissionais de áreas não-técnicas (negócios), o estudo dos fundamentos da programação, pois o letramento digital é fundamental para todos.

O Risco do "Blind vibe coding"

O vibe coding sem fundamentos é o efeito "black box". Se o dev ou a pessoa que pode ser alguém que não é da área tech, não entende a complexidade assintomática (Big O), o gerenciamento de memória ou como aquele trecho de código impacta o main thread no Next.js, ele está apenas empilhando peças que "parecem" funcionar como estivesse brincando de lego. O resultado disso é o que chamo de AI-Driven Technical Debt (Débito técnico impulsionada por IA), um sistema que funciona hoje, mas que ninguém sabe como debugar amanhã porque a lógia não nasceu de um processo deliberado de design.

O Dev como Analista de sistemas

Um grande ponto fundamental, é a responsabilidade que mudou para o Code Review. No dia a dia de um Sênior, o write code está se tornando a parte muito mais pequena do que já era se antes da IA era 20% de write code, hoje com a cai para uns 10%. O valor real está em:

• Identificar gargalos de performance: A IA pode entregar um código funcional, mas que causa N+1 queries no banco de dados.
• Security Oversight: Validar se aquele código gerado não introduziu uma vulnerabilidade de Insecure Direct Object Refrence (IDOR).
• Arquitetura: Garantir que o código respeite os princípios de Single Responsibillity.

Letramento digital para negócios

Minha sugestão, como desenvolvedor Sênior, para profissionais de negócios, é a aquisição de conhecimento, no mínimo, dos fundamentos da programação. Tal iniciativa fomenta o desenvolvimento do Pensamento Crítico Computacional (Critical Computational Thinking).

• Para um PO (Product Owner) ou Gerente de Projetos, a compreensão da funcionalidade de uma API ou do que constitui um estado de aplicação mitiga as falhas de comunicação.
• Permite evitar o compromisso com features tecnicamente inviáveis ou que demandam custos proibitivos de infraestrutura.

Otimizando este conceito

Se adotarmos essa postura de 90% Review e 10% Writing, precisamos fortalecer nossas ferramentas de Automação de testes e Analise. O tempo economizado na escrita deve ser reinvestido em:

• Testes de Integração e E2E (Playwright/Vitest): Para garantir que o que a IA entregou atende ao contrato.
• Documentação Técnica: Para que o "porquê" das decisões arquiteturais não se perca.

A IA é, inegavelmente, uma ferramenta notável e deve ser empregada estritamente como tal, pois carece da visão holística do projeto. O Engenheiro de Software (SWE) é o responsável por guiar o processo e garantir que a aceleração tecnológica não resulte em um colapso técnico.

Conclusão

Para iniciantes e profissionais de negócios, a inclinação natural é a busca direta pela "solução". Contudo, o valor intrínseco reside na abstração e formulação do problema. Para Desenvolvedores Juniores, sugere-se a documentação e a análise de requisitos e domínio de negócio como fontes primárias de conhecimento, o que os elevará da posição de meros "digitadores de código" para "solucionadores de problemas". Para o pessoal de negócios, o estudo dos fundamentos proporciona uma comunicação técnica básica, permitindo avaliar o impacto de uma requisição síncrona e elevando o nível da discussão sobre viabilidade e prazos de um produto. A recomendação final é que todos devem possuir conhecimentos de programação; não se trata de uma questão de independência do desenvolvedor, mas sim de alcançar a autossuficiência.