Na semana passada, um de nossos gerentes de produto (PMs) criou e enviou um recurso. Não especificei isso. Não arquivei um ticket para isso. Construí-lo, testá-lo e enviá-lo para produção. Em um dia.
Alguns dias antes, nosso designer percebeu que a aparência visual de nossos plug-ins IDE havia se desviado do sistema de design. No velho mundo, isso significava capturas de tela, um ticket JIRA, uma conversa para explicar a intenção e um slot de sprint. Em vez disso, ele abriu um agente, ajustou o layout sozinho, experimentou, iterou e ajustou em tempo real e, em seguida, pressionou a correção. A pessoa com a intuição de design mais forte fixou o design diretamente. Nenhuma camada de tradução necessária.
Nada disso é novo em teoria. A codificação Vibe abriu as portas da criação de software para milhões de pessoas. Essa era uma aspiração. Quando compartilhei os dados sobre como nossos engenheiros dobraram o rendimento, passaram da codificação para a validação e trouxeram o design antecipadamente para experimentação rápida, ainda era uma história de engenharia. O que mudou é que a teoria virou prática. Veja como realmente aconteceu.
O gargalo mudou
Quando adotamos a IA em primeiro lugar em 2025, o custo de implementação entrou em colapso. Os agentes assumiram o controle dos andaimes, dos testes e do código de cola repetitivo que costumava consumir metade do sprint. Os tempos de ciclo caíram de semanas para dias, de dias para horas. Os engenheiros começaram a pensar menos em arquivos e funções e mais em arquitetura, restrições e planos de execução.
Mas assim que a capacidade de engenharia deixou de ser o gargalo, percebemos algo: a velocidade de decisão sim. Todos os mecanismos de coordenação que construímos para proteger o tempo de engenharia (especificações, tickets, transferências, preparação de pendências) eram agora a parte mais lenta do sistema. Estávamos otimizando para uma restrição que não existia mais.
O que acontece quando construir é mais barato que coordenar
Começamos a fazer uma pergunta diferente: como seria se as pessoas mais próximas da intenção pudessem enviar o software diretamente?
Os PMs já pensam nas especificações. Os designers já definem estrutura, layout e comportamento. Eles não pensam em sintaxe. Eles pensam em resultados. Quando o custo de transformar a intenção em software funcional caiu o suficiente, essas funções não precisaram "aprenda a codificar." O custo de implementação simplesmente caiu ao seu nível.
Pedi a um de nossos PMs, Dmitry, que descrevesse o que mudou em sua perspectiva. Ele me disse: "Enquanto os agentes geram tarefas no Zenflow, há alguns minutos de tempo ocioso. Apenas ar morto. Eu queria construir um pequeno jogo, algo para interagir enquanto você espera."
Se você já dirigiu uma equipe de produto, conhece esse tipo de ideia. Não move um KPI. É impossível justificar em uma reunião de priorização. Fica adiado para sempre. Mas acrescenta personalidade. Faz com que o produto pareça que alguém se importa com os pequenos detalhes. Essas são exatamente as coisas que são otimizadas em cada sessão de preparação do backlog e exatamente as coisas que os usuários lembram.
Ele construiu em um dia.
No passado, essa ideia teria morrido numa planilha de priorização. Não porque fosse ruim, mas porque o custo de implementação tornava irracional prosseguir. Quando esse custo cai para perto de zero, o cálculo muda completamente.
Frete ficou mais barato do que explicar
À medida que mais pessoas começaram a construir diretamente, camadas inteiras de processos desapareceram silenciosamente. Menos ingressos. Menos transferências. Menos "você pode explicar o que você quer dizer com…" conversas. Menos momentos perdidos na tradução.
Para uma classe significativa de tarefas, tornou-se mais rápido apenas construir a coisa do que descrever o que você queria e esperar que outra pessoa a construísse. Pense nisso por um segundo. Toda organização de software moderna está estruturada em torno da suposição de que a implementação é a parte cara. Quando essa suposição é quebrada, a organização precisa mudar junto.
Nosso designer que consertou a interface do plugin é um exemplo perfeito. O antigo fluxo de trabalho (capturar a tela do problema, registrar um ticket, explicar a lacuna entre a intenção e a implementação, aguardar um intervalo de sprint, revisar o resultado, solicitar ajustes) existia inteiramente para proteger a largura de banda da engenharia. Quando a pessoa com intuição de design pode agir diretamente, toda aquela pilha desaparece. Não porque eliminamos o processo por si só, mas porque o processo estava resolvendo um problema que não existia mais.
O efeito agravante
Aqui está o que mais me surpreendeu: ele se compõe.
Quando os PMs constroem suas próprias ideias, suas especificações ficam mais nítidas, porque agora eles entendem o que o agente precisa para executar bem. Especificações mais nítidas produzem melhor resultado do agente. Melhor resultado significa menos ciclos de iteração. Estamos vendo a velocidade aumentar semana após semana, não apenas porque os modelos melhoraram, mas porque as pessoas que os utilizam ficaram mais próximas do trabalho.
Dmitry colocou bem: o ciclo de feedback entre a intenção e o resultado passou de semanas para minutos. Quando você consegue ver o resultado de sua especificação imediatamente, você aprende qual precisão o sistema precisa e começa a fornecê-la instintivamente.
Há um efeito de segunda ordem que é mais difícil de medir, mas impossível de ignorar: a propriedade. As pessoas param de esperar. Eles param de preencher multas por coisas que poderiam consertar. "Construtor" deixou de ser um cargo. Tornou-se o comportamento padrão.
O que isso significa para a indústria
Muito do "todos podem codificar" a narrativa do ano passado foi teórica ou focada em fundadores individuais e pequenas equipes. O que vivemos é diferente. Temos cerca de 50 engenheiros trabalhando em uma base de código brownfield complexa: múltiplas superfícies e linguagens de programação, integrações empresariais, todo o peso de um sistema de produção real.
Não acho que somos únicos. Acho que chegamos cedo. E com cada nova geração de modelos, a lacuna entre quem pode construir e quem não pode está diminuindo mais rápido do que a maioria das organizações imagina. Toda empresa de software está prestes a descobrir que seus gerentes de projetos e designers estão presos a uma capacidade de construção não realizada, bloqueados não pela habilidade, mas pelo custo de implementação. À medida que esse custo continua a cair, as implicações organizacionais são profundas.
Começamos com a intenção de acelerar a engenharia de software. O que estamos nos tornando é algo diferente: uma empresa onde todos enviam.
Andrew Filev é fundador e CEO da Zencoder.
Fonte ==> Cyberseo
