Vibe coding, code review e o novo gargalo

Eu vi ontem uma entrevista com CPTO do G4 (sei que não são a referencia em tech mas enfim…) o foco lá é exatamente esse. Disse que foi dificil virar a cultura e teve muita resistencia. Falou que estao reescrevendo tudo que eles possuem de sistema “tradicionalmente com codigo” usando replit e claude code.

E ele fala “E isso não é experimental ou algo do tipo. Já temos aplicações com milhares de usuários e funcionando bem”

É como Gui e eu temos feito com time aqui no future studio. Não se escreve mais código, e mal se lê código. Gargalos começam a ser outros — trocas de contexto, especificar as tarefas, validar a solução

Sim. Evidentemente esse é o futuro. O problema tá em todo mundo que não opera assim (99.99%?). Ao mesmo tempo tá a oportunidade…

O problema maior tá no injection que vamos levar um susto algum dia kkkk

Só vamos descobrir quando chegar

Vou brigar aqui com o “mal se lê código”. :) O momento do projeto atual de vcs permite isso. O dev que tá trabalhando em um produto que já tem impacto, ele precisa se preocupar se vai quebrar coisa. Mesmo que a tech chegue lá (ainda não tá, se vcs tivessem revisando código, vcs teriam visto 😂), vai levar tempo pras empresas decidirem que é ok tirar o accountability do humano.

Sobre nao escrever código mais, tô 100% dentro, nao faz mais sentido escrever ponto-e-virgula. Delega pra LLM que ela faz. Code monkey.

Acho que precisamos achar uma maneira de deixar claro qual parte do nosso discurso pro mundo de fora…

A gente ta testando o edge aqui, mais dificil fazer na alurona, eu concordo (e vivi isso ate mes passado rs). Mas sim o futuro é não ler código.

Aniche, to com um sofrimento forte na equipe agora. A gente gerou um pull request de +1200 linhas. E agora? Como ler 1200 linhas. Sendo realista, NINGUEM vai ler. Nao adianta eu mandar o dev ler. Eu pensei em mandar a ferramenta pegar pull requests de 1200 linhas, quebrar em pull requests por historia menor de 200 linhas no max. Algo do genero? E pedir pra ela ir extraindo regras que queremos validar em checklists. Pensei tambem em implementar validacoes dos medos que temos de forma programatica (preciso de uma bateria de seguranca automatizada deterministica, nao da LLM dizendo se sim ou nao — alem disso)

Guilherme, esse é o desafio, o gargalo muda de lugar. E esse é o trade-off difícil de fazer. Minha AI gerou 1200 linhas de código em 5 minutos, o que é mais importante: mergear logo pra eu ir pra próxima com a chance de quebrar o planeta, ou diminuir o throughput um pouco para garantir a qualidade da entrega? Meu chute é que sistemas que estao em um estágio mais maduro, cujo custo de uma falha é significante, vao pender pro segundo.

E o gargalo nem é só code review. Ele se espalha por todo o ciclo. O time também sabe que precisa validar a funcionalidade em prod, abrir a feature flag aos poucos, monitorar pra ver se nao quebrou nada mesmo que o teste passou… Etc. Accountability do humano.

(dito isso, acho que temos um espaço muito grande pra explorar, pra treinar o VIBE CODER. O cara, tecnico ou nao tecnico, que tem um problema que um sistema conseguiria resolver, que se falhar o mundo continua, e que antes ele nao tinha a menor chance de fazer mas agora tem. Nesse aí, é realmente só prompt com AI + brincar com o prototipo gerado. Em outras palavras, curso de Lovable, Replit, etc.)

esse gargalo de revisar codigo sinto que é o maior obstaculo hoje e onde pessoal ta se dedicando mais pra resolver. é exatamente a startup la do ex-ceo do github que mandei, pq ele entendeu que ver diff em PR nao funciona, e ta pensando em algo novo com IA tbm nessa etapa. ainda tem bastante agua pra rolar nessa parte, concordo. mas nao ler codigo é o end goal sem duvida