Durante a maior parte da história do software, o planejamento foi sagrado. Precisávamos ter um plano antes que alguém tocasse no teclado. Porque o custo de fazer algo errado pode ser muito alto. Especialmente para startups, acertar era a única estratégia razoável.
A implementação era cara, o tempo de engenharia era limitado e poderia levar meses até que a equipe mudasse de direção depois de decidir sobre uma abordagem.
Todo o aparato de desenvolvimento de software moderno, seus roteiros, estruturas de prioridades e rituais de planejamento trimestrais cresceram em resposta a um fato econômico:
Isso não é mais verdade, e a maioria das organizações de engenharia ainda não se atualizou.
As ferramentas de codificação de IA reduziram drasticamente o custo de transformar ideias em software funcional. Tarefas que levavam semanas para serem implementadas agora podem ser exploradas em horas.
Espaço de coworking da cidade de TNW – onde o melhor trabalho acontece
Um espaço de trabalho projetado para crescimento, colaboração e oportunidades infinitas de networking no centro da tecnologia.
Você pode pedir ao seu agente para criar um protótipo de três abordagens concorrentes durante a noite e descartar as duas que não funcionam quando você acorda pela manhã.
Você pode desafiar suas suposições usando uma demonstração ao vivo em vez de uma apresentação de slides. A economia mudou. O planeamento e os processos costumavam ser mais baratos do que construir um edifício, e agora construir um edifício é mais barato do que as reuniões que se realizam para decidir o que construir e como construir.
Isso muda tudo sobre como as equipes de engenharia operam. Não existe mais um plano perfeito. Mesmo que o tempo necessário para elaborar um plano perfeito signifique que você já perdeu para alguém que está apenas começando a criá-lo.
para sínteseDecidimos testar esta ideia da forma mais direta possível. Todos os trimestres, as nossas equipas de produto, engenharia e I&D reúnem-se em Londres para planear os próximos três meses de trabalho.
Historicamente, passamos a maior parte do tempo em salas de reuniões analisando, debatendo e priorizando. O objetivo era ter um plano suficiente para justificar o custo de implementação.
Na nossa reunião mais recente, mudamos a ordem. Substituímos os primeiros dois dias do plano por um hackathon. 200 pessoas de engenharia, produto, design, jurídico, pesquisa e talento formaram 70 equipes que foram construídas continuamente ao longo de 28 horas.
O esboço era simples. Trata-se de pegar uma ideia, desenvolvê-la e transformar os resultados em um vídeo de demonstração de dois minutos. Sem especificações detalhadas, sem planejamento excessivo. Basta construí-lo.
Ficamos surpresos com o que aconteceu.
Uma das equipes vencedoras, um grupo de cinco engenheiros, reconstruiu completamente o editor de vídeo do zero. O editor de vídeo oferece uma interface semelhante ao PowerPoint por meio da qual os usuários da plataforma podem criar vídeos. Avatar de IA.
Os engenheiros reconstruíram completamente o produto de cima a baixo, concentrando-se na interatividade, nas narrativas ramificadas e na narrativa com vários avatares.
Este não foi um caso atípico. O mesmo padrão surgiu em todas as 70 equipes. O que isso significa é que, se você der foco às pessoas e remover o atrito, poderá se mover muito mais rápido do que imagina.
A lição que tiramos desta experiência é que a execução não é mais uma restrição, mas um julgamento.
Isso pode contradizer as suposições operacionais que a maioria dos líderes de engenharia trabalhou durante toda a sua carreira. Passamos anos construindo organizações otimizadas para o rendimento de execução: número de recursos lançados, número de pontos de história concluídos e velocidade de redução do backlog.
Mas à medida que os edifícios se tornam mais baratos, o estrangulamento move-se a montante. A parte difícil é não escrever mais código. Em vez disso, é importante saber qual código vale a pena escrever em primeiro lugar.
Quando digo julgamento, quero dizer quatro coisas específicas: primeiro, a capacidade de ajudar os gerentes de produto a resolver os problemas certos dos clientes com mais rapidez. Isso requer distinguir entre o que é intelectualmente interessante e o que é realmente importante para seus usuários e negócios.
Em segundo lugar, antes de começar, defina o que significa “bom”. Porque se você não conseguir expressar claramente esse padrão, não será capaz de reconhecê-lo quando o vir.
Terceiro, trata-se de saber quando algo é bom o suficiente para ser apresentado aos usuários e quando não é perfeito ou sofisticado, mas apenas bom o suficiente para ser aprendido. E, finalmente, pode matar uma ideia rapidamente.
Quando você pode tentar muitas coisas ao mesmo tempo, a técnica mais valiosa é jogar fora o que não funciona, em vez de ir contra na primeira tentativa, porque é muito caro para produzir.
Nos próximos anos, as melhores equipes de engenharia vencerão com base no gosto, e não na produção do código.
Isto tem implicações reais na forma como pensamos sobre o próprio papel da engenharia. Estamos passando de construtores a orquestradores. Os agentes de IA agora podem executar muitas partes do processo de desenvolvimento do início ao fim.
O trabalho do engenheiro é selecionar cada vez mais o problema certo, revisar a saída e iterar em ritmo rápido. Gaste menos tempo escrevendo cada linha e mais tempo direcionando o sistema que as escreve.
Algumas pessoas acham isso ameaçador. Acho que o oposto é verdadeiro. As partes chatas da engenharia, clichês, fiação repetitiva, tarefas que nunca são realmente interessantes, etc. são automatizadas primeiro.
O que resta é um trabalho que os engenheiros sempre desejaram ter mais tempo para realizar. Isso significa compreender profundamente o problema, conceber soluções elegantes e tomar decisões difíceis sobre o que construir e o que descartar. O artesanato é destilado até a sua essência.
Somos responsáveis por esta mudança na Synthesia. Estamos monitorando o uso semanal de ferramentas de codificação de IA, como Claude Code e Codex, e medindo a rapidez com que as equipes podem passar da ideia ao protótipo e ao feedback do usuário. Agora, a métrica importante não é a quantidade de código gerado, mas a velocidade do ciclo de aprendizagem.
A direção que estamos tomando é o que chamo de desenvolvimento em modo automático. Há um ciclo estreito desde o protótipo até o teste do usuário, entrega e melhoria. O Agile está sendo substituído por algo mais rápido, com pouca lacuna entre ter insights e testá-los em relação à realidade.
Portanto, para cada líder de engenharia que lê isto, a questão importante não é mais “Podemos construir isto?” Essa pergunta foi respondida. Com uma equipe pequena e as ferramentas certas, você pode construir quase tudo muito rapidamente.
Agora a questão é o que construir? E você tem julgamento para saber?
