- A prática mais contraintuitiva na era da IA é saber quando desacelerar, e quanto mais barata a execução fica, mais importante se torna a tomada de decisão na etapa anterior
- Aplica-se à engenharia de software na era da IA o framework de Daniel Kahneman de System 1 (correspondência rápida de padrões) e System 2 (pensamento analítico lento)
- Requisitos errados ou premissas de design equivocadas são propagados ainda mais rápido pela IA, então o custo-benefício das etapas lentas antes da execução é maximizado
- A IA pode ser usada não só para executar, mas também para acelerar etapas de reflexão como revisão prévia, pre-mortem e exploração de edge cases
- Para responder à nova cultura de pressão por velocidade do "é só usar IA, não é?", é preciso uma estratégia de explicitar e colocar em timebox as etapas lentas
Duas velocidades de pensamento
- Os dois modos de pensamento apresentados por Daniel Kahneman em Thinking, Fast and Slow são aplicados ao desenvolvimento na era da IA
- System 1: pensamento rápido, automático e baseado em correspondência de padrões
- System 2: pensamento lento, deliberado e analítico
- Em uma conversa com Dwarkesh Patel, Andrej Karpathy comparou os LLMs a fantasmas ou gênios, destilações estatísticas de texto humano: entram palavras, padrões são correspondidos e saem palavras — uma entidade essencialmente do tipo System 1
- A IA é excelente em correspondência rápida de padrões em grande escala, mas decidir o que construir, por que isso importa e se estamos resolvendo o problema certo ainda pertence ao campo do julgamento humano
- O ponto central contraintuitivo: a IA não tornou as etapas lentas menos importantes; ela as tornou mais importantes
- Quando a execução fica barata e rápida, a alavancagem se desloca para a tomada de decisão anterior à execução
- Requisitos errados, problemas mal compreendidos e premissas de design defeituosas se propagam por tudo o que a IA constrói — e agora se propagam mais rápido
- Quanto mais poderoso o System 1 se torna, maior é o custo de executar mal o System 2
A ilusão da velocidade
- Uma velha piada da academia: "algo que levaria algumas horas na biblioteca leva semanas no laboratório"; a versão do software é: "algumas semanas de programação economizam algumas horas de planejamento"
- O ponto principal é que, na prática, é o contrário — começar com pressa leva à descoberta de erros fundamentais e a retrabalho doloroso
- Em engenharia de software, existe uma intuição clara de que erros devem ser detectados o mais cedo possível, de preferência na fase de requisitos ou design
- Diagramas em caixas são fáceis de mudar, requisitos mal entendidos são mais difíceis, e uma arquitetura de deployment fundamentalmente defeituosa pode exigir reescrita
- O problema da IA: ela pode gerar dívida técnica mais rápido do que nunca
- Se as decisões anteriores à execução forem falhas, a IA implementará essas falhas fielmente em uma forma que parece código funcional completo
- Ela pode gerar milhares de linhas de código com base em requisitos mal compreendidos e construir de bom grado uma solução elegante para o problema errado
- A ilusão da velocidade: parece que há progresso, quando na verdade o time só está cavando um buraco mais fundo
- A resposta não é abrir mão da velocidade, mas alocá-la de forma deliberada — a velocidade da IA só deve entrar em ação depois que a direção correta tiver sido confirmada
Quando a lentidão faz diferença
- Os pontos em que a lentidão deliberada faz diferença não mudaram muito
- Alterar requisitos é barato quando eles ainda são palavras em um documento, e caro quando já são código em produção servindo usuários reais
- Decisões de design são fáceis de ajustar em diagramas e difíceis em sistemas de produção
- A IA não mudou essa física fundamental; ela aumentou a alavancagem quando isso é feito corretamente
- O protocolo Thinking First: antes de delegar uma tarefa à IA, investir tempo para esclarecer o que realmente se quer é o ponto mais barato para detectar erros
- Há um paradoxo interessante: a IA pode ser usada não apenas para acelerar a execução, mas também para acelerar a própria reflexão
- Esclarecer requisitos antes de codar: passar 10 minutos escrevendo qual problema será resolvido, quais são os critérios de sucesso e quais são as restrições, depois pedir para a IA revisar o que foi escrito antes de gerar algo
- Executar um pre-mortem: antes de fechar o design, perguntar à IA "o que pode dar errado nesta abordagem?" para levantar riscos que não haviam sido considerados
- Inverter o problema (Invert): perguntar à IA "o que faria este projeto fracassar?" para expor premissas ocultas
- Construir um protótipo descartável: criar algo em poucas horas com IA, mostrar a stakeholders e validar o entendimento antes de investir — usar velocidade a serviço da lentidão
- Criar uma ferramenta interna simples: antes de investir no produto real, fazer primeiro uma versão rústica com IA para entender o que de fato é necessário e o que não é
- Levantar edge cases cedo: antes de começar a implementação, pedir à IA que gere edge cases e modos de falha do design para tratá-los ainda na etapa de diagrama
Um novo vento cultural contrário
- "É só usar IA, não é?" é uma nova forma de pressão por velocidade, especialmente perigosa porque confunde aparência de produtividade com throughput real
- A IA pode gerar código em segundos, mas gerar código e resolver o problema certo não são a mesma coisa
- Estratégias de resposta:
- Compartilhar explicitamente em que etapa se está: se estiver em uma etapa lenta, explicar que o foco está em esclarecer requisitos, pensar edge cases ou verificar se o problema certo está sendo resolvido
- Trazer stakeholders para participar: incorporar a contribuição deles agora é barato; mais tarde será caro
- Compartilhar o processo de trabalho: documentos de requisitos, esboços de design, resultados de pre-mortem — tornar visíveis os artefatos da etapa lenta para provar que há progresso
- Definir timeboxes para a etapa lenta: criar limites claros como "2 dias de esclarecimento de requisitos antes de escrever código", para que a lentidão deliberada pareça planejada, não aberta indefinidamente
- Compartilhar o que foi aprendido: atualizar brevemente edge cases descobertos, premissas que se mostraram erradas etc., transformando a etapa lenta em um fluxo visível de valor
- Demonstrar quick wins: criar cedo um protótipo descartável ou mockup para mostrar que é possível se mover rápido e conquistar confiança para o trabalho lento e cuidadoso
- Isso se parece com o conceito de Hill Chart da metodologia Shape Up da Basecamp
- Subida: a etapa lenta em que há muita incerteza e se descobre a substância real do trabalho
- Descida: a etapa rápida em que o caminho está claro e resta apenas executar
- Não é uma desculpa para atraso, mas uma explicação de como o bom trabalho realmente acontece — no longo prazo, as equipes que lançam mais rápido muitas vezes são justamente as que sabem desacelerar no momento certo
Como colocar em prática
- Antes da próxima tarefa com apoio de IA, tente o seguinte:
- Passe 10 minutos escrevendo qual problema você realmente quer resolver, como será o sucesso e o que está fora de escopo
- Antes de começar a construir, peça à IA para executar um pre-mortem sobre a abordagem
- Se o trabalho for significativo, construa primeiro um protótipo descartável para validar a direção
Conclusão
- Velocidade e lentidão não são opostos, mas ferramentas para etapas diferentes
- A IA é eficaz em ambos os lados: execução rápida quando a direção está clara e reflexão acelerada quando ela ainda não está
- A competência central é entender em que etapa você está e aplicar o ritmo adequado
4 comentários
Existe um ditado: devagar e rápido.
Era algo que eu ouvia com frequência do meu orientador na pós-graduação,
trazendo PTSD de volta depois de muito tempo.
Eu ouvi isso no exército.
Eu li isso na partitura
allegro non troppo (rápido, mas sem pressa)