O loop fecha: do Slack ao deploy com humanos só no merge
As três gerações de software
O autor parte de uma palestra de Andrej Karpathy sobre LLMs, que divide a história do software em três gerações: código escrito manualmente por pessoas (1.0), machine learning estreito (2.0) e código escrito por LLMs (3.0). Trabalhando no piloto automático da Tesla, Karpathy descreveu como o ML substituiu partes do código 1.0, e como os LLMs agora escrevem código cada vez melhor, corroendo bases 1.0 no mundo inteiro. O autor estende a analogia para 'empresas 1.0': processos organizacionais desenhados e operados por humanos estão sendo substituídos por agentes mais rápidos, paralelizáveis ao infinito e que nunca dormem.
Do alerta ao deploy sem intervenção
No exemplo do engenheiro de plantão, erros postados no Slack pelo Sentry - ferramenta de monitoramento - são imediatamente recolhidos pelo Claude, que pede informações ao Sentry, lê logs, roda diagnósticos, verifica a saúde do site e, se necessário, escreve uma solicitação de mudança para corrigir o código. A única etapa humana é clicar em 'merge'; depois, os pipelines de deploy automatizados colocam o código no ar.
Com pedidos de produto, o fluxo antes passava por um sistema de tickets com triagem manual semanal. Agora, alguém pede a mudança no Slack, o Claude ajuda a especificá-la com o usuário, escreve o código e adiciona o ticket ao backlog. De novo, o engenheiro só clica em 'merge', e o Claude marca o ticket como concluído e avisa o solicitante.
No QA, o Claude abre um navegador, percorre passos de teste e registra no ticket o que verificou; como os modelos enxergam, checam regressões visuais e, segundo o autor, têm 'taste' para julgar se o design está bom. O humano apenas aprova o deploy.
O papel humano encolhendo
O autor observa que esses ainda são loops abertos - o time técnico não se tornou redundante - mas seu papel diminui, com humanos servindo apenas como porta final. E ele sugere que até essa porta pode ser removida. Como o produto lida com dinheiro, ele hesita em terceirizar tudo a agentes. Ele mesmo se ocupa pedindo coisas ao Claude e carimbando o trabalho; ocasionalmente detecta um bug que escaparia sem supervisão. Mas, com modelos mais poderes, melhoram em escrever código sem erros e revisar o próprio trabalho: rodando revisores de código LLM com 'effort' maior - parâmetro que faz o modelo pensar mais - os defeitos e comentários em solicitações de mudança caíram a quase zero. O último bug introduzido foi um erro de configuração causado por ele mesmo ao preencher um formulário de configurações.
Estratégia de produto como última fronteira
A fronteira final talvez seja a estratégia de produto e a gestão da organização. Os LLMs ainda não são bons em dizer o que falta num produto: sugerem coisas úteis, mas carecem do contexto acumulado por um bom gerente de produto após anos de interação com stakeholders e o mercado. O autor suspeita que, quanto mais contexto for canalizado - documentos, wiki da empresa, atas de reuniões, tickets antigos do Jira, uma década de e-mails -, melhor o modelo poderá se colocar no lugar de um gestor especialista e tomar decisões tão boas quanto as humanas.
Um amigo dele diz que o time hoje basicamente só faz reuniões: é o que os humanos ainda fazem bem - absorver, interpretar e compartilhar contexto entre si. As notas dessas reuniões alimentam o LLM, e dele saem os bens intermediários organizacionais: e-mails, tickets, documentos de requisitos, planos de implementação e código. Quando isso também puder ser automatizado, o loop finalmente se fecha - e restaria, nas palavras do autor, apenas 'continuar pagando a conta'.