A DavaFlow da Endava coloca a OpenAI em todas as etapas da entrega de software

O que a DavaFlow mudou de facto

O relato da Endava, contado pelo CTO Matthew Cloke, descreve uma sequência específica. A codificação assistida por AI (keep the English acronym) acelerou primeiro o output de engenharia. Isso expôs um novo estrangulamento: a recolha de requisitos, a análise de negócio, o planeamento e a coordenação com stakeholders já não conseguiam acompanhar o ritmo a que o código estava a ser produzido.

A resposta foi a DavaFlow, uma metodologia de entrega que aplica tecnologia da OpenAI ao longo de todo o ciclo de vida—preparação de reuniões, planeamento de negócio, descoberta de produto, engenharia e implementação. A afirmação de Cloke é incomummente absoluta.

Não há nenhuma parte da DavaFlow que não utilize tecnologia da OpenAI.Montana Labs

Esse enquadramento é importante porque trata a AI (keep the English acronym) como uma mudança na sequência do trabalho de entrega, e não como uma ferramenta acessória. Cloke descreve ser "AI-native" como recorrer primeiro à AI (keep the English acronym) para resolver um problema, e não como último recurso.

A aplicação de preços é o dado interessante

A maior parte do anúncio elenca categorias de adoção já familiares: a área jurídica a agilizar investigação, gestores de projeto a usar o Codex para relatórios de governação, lideranças a usar agentes para resumir projetos e gerir caixas de entrada. São reais, mas genéricas.

O momento concreto é a discussão interna sobre preços. Em vez de trabalharem com folhas de cálculo, os funcionários construíram uma aplicação de preços de uma só página com a qual as equipas podiam interagir de imediato. Cloke afirma que isso "mudou completamente a conversa".

A mudança aqui é passar de dados estáticos em células para uma pequena interface interativa gerada na hora. Quando uma folha de cálculo se transforma numa aplicação, o artefacto deixa de ser um ficheiro que se lê e passa a ser uma superfície que se manipula em conjunto. Equipas comerciais sem formação técnica conseguirem produzir um frontend funcional sem apoio dedicado de engenharia é a capacidade mais relevante escondida nesta história.

Quem constrói o frontend quando a engenharia não é o estrangulamento

A Endava enquadra isto como uma adoção que se estende além dos desenvolvedores, chegando à área jurídica, financeira e operações. É a vertente do frontend que torna essa expansão possível: interfaces leves e descartáveis que uma equipa comercial pode gerar para substituir um exercício pesado em folhas de cálculo.

Isto inverte uma restrição de longa data. As ferramentas internas normalmente esperam numa fila de engenharia porque construir mesmo uma UI simples exigia alguém que a soubesse programar. Os resultados da Endava listam "permitir que as equipas construam ferramentas e aplicações internas sem apoio dedicado de engenharia" como um resultado distinto, separado da engenharia mais rápida.

A questão em aberto que a fonte não responde: o que acontece a estas aplicações depois da reunião. Uma aplicação de preços de uma só página que muda uma conversa é útil; uma centena de aplicações de uma só página sem qualquer governação numa empresa com 11 mil pessoas é um problema de manutenção e correção. O anúncio celebra a criação, mas nada diz sobre o ciclo de vida daquilo que é criado.

A implicação: as interfaces interativas tornam-se um meio de pensamento descartável

O princípio declarado pela Endava é tratar a adoção de AI (keep the English acronym) como uma mudança de comportamento, e não como um lançamento de software, e envolver desde cedo as equipas sem formação técnica. O episódio da aplicação de preços mostra o que essa mudança de comportamento parece à superfície: as pessoas recorrem a uma pequena interface personalizada da forma como antes recorriam a uma folha de cálculo.

Para equipas aplicadas, a lição é restrita e prática. Quando gerar um frontend utilizável custa minutos, a interface deixa de ser um entregável e passa a ser uma forma de conduzir uma conversa—construída para tomar uma decisão e depois descartada. Isso baixa a barreira de quem pode desenhar interações de software e levanta uma nova questão de governação: quais destas aplicações descartáveis se tornam, silenciosamente, estruturais.