A indústria de desenvolvimento de software está a mudar — permanentemente

Em 2003, fundei a DCSL Software, que mais tarde se tornou One Beyond. Saí em 2023 depois de internacionalizar a empresa e fazê-la crescer para mais de 300 pessoas. Desde então, fundei uma start-up de robótica e angariei mais de £4M em financiamento inicial.  

Nunca esperei voltar a escrever software de produção. Parei de programar diariamente em 2014, não porque não pudesse fazê-lo, mas porque é o que acontece quando uma empresa cresce. Contrata-se pessoas que são melhores do que você na execução, foca-se na liderança e, gradualmente, o teclado fica cada vez mais distante. Durante quase uma década, isso pareceu inteiramente natural.  

O que não esperava era que, quase dez anos depois, me encontrasse de volta ao lugar de programador — não nostalgicamente, mas de forma prática. Não a experimentar, mas a construir uma plataforma de robótica genuinamente complexa. E não reaprendendo cada framework ou linguagem que me passou ao lado, mas trabalhando de uma forma fundamentalmente diferente.  

Essa mudança pessoal é o sinal mais claro que vi de que algo estrutural mudou no desenvolvimento de software.  

Como costumávamos conceber software — e porquê  

Quando comecei, estávamos firmemente na era waterfall. Isso não era ideologia, era economia. O software era lento e caro de construir, portanto, a única abordagem sensata era pensar muito cuidadosamente desde o início.  

Escrevíamos especificações detalhadas porque tínhamos de o fazer. Os contratos dependiam delas. A entrega dependia delas. Escrever uma boa especificação era uma competência especializada, e uma em que eu era razoavelmente bom. Conseguia visualizar como o produto final poderia ser antes de existir, prever áreas de complexidade e descrever comportamentos com precisão suficiente para que uma equipa pudesse construir com base nisso.  

Essa capacidade era rara e difícil de ensinar. Muitas pessoas tinham dificuldades com isso porque imaginar um sistema complexo que ainda não existe é genuinamente difícil. Mas era importante, porque errar tarde no processo era doloroso e caro.  

Com o tempo, a indústria moveu-se em direção ao Agile. Publicamente, isto foi apresentado como uma melhor forma de responder à mudança. Discretamente, foi também um reconhecimento de que, para sistemas grandes e de longa duração, nenhuma especificação sobrevive intacta. Os negócios mudam, os utilizadores mudam, a tecnologia muda e fingir o contrário frequentemente causava mais mal do que bem.  

O Agile era pragmático, mas tinha um custo. Abandonámos em grande parte o design profundo inicial e substituímo-lo por descoberta incremental. Isso funcionou, mas também normalizou uma mentalidade em que pensar demasiado à frente era visto como desnecessário ou até arriscado.  

O que mudou — e por que voltei a construir  

A razão pela qual consegui voltar ao desenvolvimento prático não é que subitamente encontrei tempo ou desejo de reaprender uma década de ferramentas. É porque a IA mudou fundamentalmente o custo da experimentação.  

Esta é a parte que é frequentemente mal compreendida. A verdadeira mudança não é que o código é mais rápido de escrever. É que tentar coisas é agora barato, rápido e em grande parte reversível.  

Coisas que antes teriam levado semanas de programador podem agora ser tentadas em minutos. Pode-se explorar uma abordagem, ver como funciona, descartá-la completamente e tentar uma direção diferente com muito pouca penalização. Isso simplesmente não era possível antes.  

No passado, havia um forte apego emocional e financeiro ao código. Se algo levou dois programadores três semanas a construir, era compreensível a relutância em descartá-lo. As decisões endureciam cedo, nem sempre porque estavam certas, mas porque revertê-las era demasiado caro.  

Essa restrição desapareceu e foi isso que me trouxe de volta. Agora posso operar ao nível em que sou mais forte — compreender o problema, moldar o sistema, detetar quando a complexidade está a aumentar — enquanto a IA trata da mecânica. Não estou a escrever código da forma como fazia nos meus vinte anos. Estou a dirigi-lo, refiná-lo, corrigi-lo e, ocasionalmente, a impedi-lo de seguir numa direção completamente errada. Na prática, isto parece-se muito mais com liderar uma equipa do que escrever código. É-se efetivamente o chefe — definindo a direção, revendo o resultado, detetando atalhos preguiçosos e resistindo quando algo não parece certo. 

Por que o design ainda importa — mais do que nunca   

Seria fácil assumir que esta nova liberdade torna o design menos importante. Na realidade, torna-o mais importante.   

Ter uma ideia clara e detalhada do que se está a tentar construir continua a ser extremamente valioso. Na verdade, melhora ativamente o resultado da IA. Quanto mais clara a intenção, melhores os resultados. Pensamento vago simplesmente produz sistemas vagos mais rapidamente.  O que é importante compreender é que a IA comporta-se muito como uma pessoa. Quer ser útil. Quer dar-lhe uma resposta. Se for vago, preencherá as lacunas. Se for descuidado, fará suposições. Se não a desafiar, continuará confiante pelo caminho errado.  

A diferença é que o design já não é um artefacto frágil e único que deve sobreviver inalterado durante anos. Tornou-se um guia para experimentação em vez de uma restrição. Pode-se manter uma visão forte de para onde se está a ir, mantendo-se disposto a tentar, descartar e evoluir o caminho que lá nos leva.   

A nova competência é saber quando a exploração é produtiva e quando é apenas ruído. A IA continuará alegremente a gerar estrutura muito depois de deveria ter sido simplificada. Não sabe quando um ficheiro cresceu demasiado, quando uma abstração está a falhar ou quando algo que "funciona" hoje causará problemas mais tarde. Esses instintos ainda vêm da experiência.  

O que isto quebra na indústria  

Assim que a experimentação se torna barata, muitas suposições antigas deixam de se sustentar. O planeamento já não é sobre trancar tudo com antecedência. É sobre definir intenção, restrições e limites.  

A estimativa torna-se menos sobre prever esforço e mais sobre compreender o espaço que se está a explorar.  

E a nossa relação com o código muda completamente. Há muito menos apego a implementações específicas e muito mais foco no comportamento, estrutura e resultados.  

É por isso que a indústria de desenvolvimento de software se sente instável. Muitas pessoas estão a tentar aplicar modelos mentais antigos a novas ferramentas. Isso funciona por algum tempo, mas perde o sentido.  

A verdadeira mudança  

A razão pela qual estou confiante de que esta mudança é permanente é simples: caso contrário, não estaria a construir novamente.  

A única razão pela qual posso credívelmente regressar ao desenvolvimento prático após uma década afastado é que as restrições que me afastaram em primeiro lugar já não se aplicam. O software pode agora evoluir através de experimentação guiada de uma forma que simplesmente não era possível antes.  

Isto não significa que a experiência importa menos. Significa que importa de forma diferente. O valor já não está em memorizar sintaxe ou frameworks. Está no julgamento, estrutura e em saber quando parar.  

Isto não é o fim do desenvolvimento de software. Mas é o fim do modelo antigo. E assim que se trabalha desta forma, não há como voltar atrás.