Tem uma pergunta que eu não conseguia responder direito até cair no trabalho do Cory Hymel: se a IA escreve código tão rápido, por que tantas equipes não ficaram tão mais produtivas assim? A resposta é que estávamos olhando para o lugar errado. O gargalo nunca foi só a digitação. E a IA, ao resolver a digitação, deixou isso escancarado.
O V-Bounce, da tese de mestrado de Cory Hymel (V-Bounce: AI-Native SDLC), é o modelo que melhor explica essa virada pra mim. Quero contar o que ele diz e, principalmente, como o que chamo de paradigma 70/30 sai do diagrama e entra na rotina.
Do V-Model ao V-Bounce
Quem trabalha com engenharia conhece o velho V-Model: de um lado, você desce dos requisitos para a arquitetura, para o design, até chegar ao código no fundo do "V"; do outro lado, você sobe de volta, testando e validando contra cada etapa. Por décadas, o fundo desse "V" — codificar — foi a parte mais cara e demorada do ciclo.
O V-Bounce parte de uma observação simples: a IA comprime justamente esse fundo. A forma do "V" continua a mesma, mas a base encolhe. Codificar virou barato e rápido. Os braços do "V" — entender o problema, desenhar, planejar os testes, validar o que voltou — continuam exigindo julgamento humano e, agora, pesam proporcionalmente muito mais.
É como apertar uma sanfona pelo meio: o que estava espremido nas pontas ganha espaço. O esforço não desaparece. Ele "quica" (daí o bounce) de volta para as extremidades, onde mora o pensamento.
O paradigma 70/30
Hymel coloca uma proporção aproximada nisso, e é ela que eu carrego como bússola: cerca de 70% do valor está no que vem antes e depois do código — intenção, arquitetura, especificação, julgamento — e cerca de 30% na execução acelerada pela IA.
Não leia isso como número exato de planilha. Leia como mudança de centro de gravidade. Quando eu sento para resolver um problema hoje, a pergunta não é mais "quanto tempo vou levar para programar isso". É "eu entendi o problema bem o bastante para que a máquina — e eu — acertemos de primeira?".
Porque tem um detalhe cruel: quando o código era artesanal, a ambiguidade do requisito se resolvia no meio do caminho, o desenvolvedor "descobria" a regra enquanto programava. Com geração automática, ambiguidade na entrada vira ambiguidade na saída, só que mais rápido e em maior volume. A qualidade do que a IA entrega é proporcional à clareza do que você pede.
O que isso muda na prática
Se o valor migrou para as pontas, o trabalho migra junto. E foi aí que eu mais tive que desaprender vícios antigos.
O primeiro foi sobre a especificação. Eu tratava spec como aquele documento chato que a gente escreve por obrigação e depois esquece numa pasta. Hoje ela é o coração do processo: é dela que sai o código e é contra ela que eu valido o resultado. O Martin Fowler descreve isso muito bem no que ele chama de Structured Prompt-Driven Development, em que o próprio prompt vira um artefato de verdade, versionado e revisado como qualquer código. Tem até uma regrinha que eu adotei e gosto demais: quando o código e a intenção brigam, eu conserto a especificação primeiro, e só depois o código.
O segundo vício foi achar que validar era tarefa de segunda categoria. Quando a máquina escreve, o gargalo passa a ser quem confere. Revisar com olho crítico, testar de verdade, julgar se o que veio presta — isso deixou de ser aquela correria do fim da sprint e virou, pra mim, a parte mais importante do trabalho.
E o terceiro foi parar de medir volume. Contar linha de código ou commit sempre foi frágil; com IA virou quase piada, porque qualquer um gera milhares de linhas em minutos. O que interessa é outra coisa: quão rápido e com quanta confiança uma ideia vira valor na mão do usuário. Os números do mercado batem nisso. O 2026 State of Software Delivery (CircleCI) mostra o throughput subindo 59%, mas a taxa de sucesso na main caindo para 70,8%. Ou seja: acelerar a digitação sem cuidar da entrada gera mais retrabalho, não menos. O DORA 2025 fecha a conta numa frase que eu repito sempre — adoção bem-sucedida de IA é problema de sistema, não de ferramenta.
Por que isso me empolga
O V-Bounce não diminui o papel de quem faz engenharia. Ele redistribui. Tira da gente a parte mecânica e devolve a parte difícil e interessante: pensar bem o problema, decidir, validar, assumir a responsabilidade pelo resultado.
É por isso que eu insisto: a barreira técnica caiu, e o que ficou escasso é critério e clareza. O 70/30 é só a forma matemática de dizer uma coisa que eu sinto no dia a dia — o jogo se decide fora do editor de código.
Referências
- Cory Hymel – The AI-Native Software Development Lifecycle (modelo V-Bounce), arXiv 2408.03416
- Martin Fowler – Structured Prompt-Driven Development (SPDD)
- DORA – 2025 AI-Assisted Software Development Report
- CircleCI – 2026 State of Software Delivery
- GitHub – Does GitHub Copilot improve code quality? Here's what the data says (2024)