5 Padrões Comuns que Causam Falhas na IA

Adam Horner construiu equipas de engenharia nos setores das tecnologias financeiras e do software empresarial. É agora o fundador da The CTO Playbook, onde dá formação e trabalha como CTO fracionário.

Falámos com ele para perceber que padrões tem observado por detrás dos sucessos e fracassos na integração da IA. Foi isto que nos contou.

Alguma versão do mesmo desafio

Sou Adam Horner, mentor de CTOs e CTO fracionário na The CTO Playbook. Passei a primeira fase da minha carreira como engenheiro e CTO cofundador, construindo e liderando equipas de engenharia nos setores das tecnologias financeiras e do software empresarial, incluindo vários anos na Palantir como um dos seus primeiros colaboradores no Reino Unido.

A transição para o coaching surgiu de uma observação simples: Tornar-se um executivo de tecnologia eficaz é genuinamente difícil, e a maioria das pessoas percorre esse caminho sem um roteiro ou sem alguém do seu lado que já tenha passado por isso. É esse o trabalho que faço agora, ajudando os CTOs a atravessar aquilo a que chamo o abismo do CTO.

Para mim, a vertente da IA não é um tema separado. Está presente em praticamente todas as conversas de coaching que tenho, porque todos os CTOs com quem trabalho estão a navegar por alguma versão do mesmo desafio: Como liderar uma organização durante uma transformação desta dimensão, na sua fase específica, com a sua equipa específica, e sair dela com uma empresa mais forte?

A fase intermédia e complexa da curva de crescimento

A minha própria organização é pequena e deliberadamente enxuta, uma equipa fundadora de quatro pessoas que trabalha inteiramente com uma abordagem de IA desde a base, utilizando essa experiência para se manter próxima das realidades do desenvolvimento de produtos em fases iniciais. Também trabalho como CTO fracionário com uma empresa emergente de tecnologias financeiras em fase de pré-acreditação, lidando com as pressões específicas de colocar no mercado um produto regulamentado com uma equipa externa de desenvolvimento.

Mas o panorama mais amplo, e de onde vem a verdadeira profundidade da exposição organizacional, são os CTOs que acompanho. Isso inclui desde equipas fundadoras e empresas emergentes autofinanciadas em fases iniciais, passando por empresas em expansão de elevado crescimento apoiadas por capital de risco e capital privado, até empresas de média dimensão que gerem uma complexidade organizacional real, e ainda empresas com vários departamentos a operar em grande escala.

Passo a maior parte do meu tempo na fase intermédia e complexa da curva de crescimento, que é também onde os desafios de liderança tendem a ser mais intensos.

Como a IA permite aos engenheiros ter uma visão mais abrangente

Para mim, a mudança mais significativa não foi uma ferramenta ou um processo; foi uma expectativa. Enquanto líder, quando damos à equipa autorização — e, mais importante ainda, a obrigação — de reavaliar todo o ciclo de entrega desde a base, o alcance dessa reavaliação é importante. Não se trata apenas de como o código é escrito ou implementado, mas de tudo aquilo em que o processo de entrega toca: apoio ao cliente, valor para o utilizador e a intenção empresarial subjacente a qualquer trabalho específico.

Quando o custo de escrever e manter código era elevado, fazia algum sentido manter os engenheiros estritamente concentrados no problema técnico. Mas esse custo caiu drasticamente. O fator limitador já não é a rapidez com que se consegue construir; é a clareza com que todas as pessoas envolvidas compreendem o que realmente vale a pena construir e porquê.

Os engenheiros que compreendem o produto, o cliente e os objetivos empresariais subjacentes a uma alteração podem tomar decisões e avançar de formas que simplesmente não eram possíveis anteriormente. O que melhorou não foi uma métrica. Foi a qualidade das perguntas que a equipa começou a fazer antes de escrever uma única linha.

Pensamentos de Adam

\u003cstrong\u003eO fator limitador já não é a rapidez com que se consegue construir; é a clareza com que todas as pessoas envolvidas compreendem o que realmente vale a pena construir e porquê.\u003c/strong\u003e

Como os ciclos de triagem e correção podem ser reduzidos com a IA

Um exemplo envolveu repensar a forma como o apoio ao cliente e a engenharia interagiam relativamente a erros confirmados. Anteriormente, os ciclos de triagem e correção eram medidos em dias ou semanas, com as equipas de apoio a gerir clientes frustrados durante todo o processo e os engenheiros a absorver o custo da distração causado pelos problemas em produção, em simultâneo com o restante trabalho. Quando o ciclo de entrega foi reavaliado tendo em conta o desenvolvimento assistido por IA, os ciclos de correção foram significativamente reduzidos e grande parte do processo tornou-se automatizada.

Isso colocou mais trabalho sobre a função de apoio logo à partida, exigindo que os problemas fossem registados e categorizados de forma clara, mas a compensação foi a resolução em horas em vez de dias. Os engenheiros mantiveram-se concentrados. Os clientes obtiveram respostas mais rapidamente. A interface entre duas funções que sempre tinham sido simplesmente aceites como lentas revelou-se totalmente renegociável.

Porque não devem as organizações aplicar IA a tudo

Quanto ao que deve ser uma tarefa humana ou uma tarefa de IA, isso varia de organização para organização. O ponto de partida certo não é uma lista de atividades, mas uma compreensão clara de onde reside o seu valor e onde se concentra o seu risco.

As partes do processo que são essenciais para aquilo que a empresa faz — a lógica, a diferenciação, as áreas onde uma falha é visível ou dispendiosa — justificam criação humana e supervisão humana. Tudo o resto situa-se num espectro.

Uma empresa de cibersegurança dedicará uma atenção humana significativa às propriedades de segurança do seu código, porque esse é o seu negócio. Uma empresa de automatização de fluxos de trabalho poderá concentrar o mesmo nível de escrutínio na lógica de tomada de decisões dentro de um fluxo de trabalho crítico, tratando simultaneamente as ferramentas de segurança como algo que a IA consegue gerir de forma adequada.

O que está errado é aplicar uma política geral num ou noutro sentido. A pergunta a fazer não é «A IA consegue fazer isto?». É «Qual é o custo se isto correr mal?»

E há outra coisa: Uma quantidade surpreendente da complexidade que as pessoas querem automatizar é, na realidade, dívida de processos ainda não resolvida. Resolva isso primeiro. Tornará a adoção da IA mais simples e mais barata posteriormente.

Adam Partilha

\u003cstrong\u003eO ponto de partida certo não é uma lista de atividades, mas uma compreensão clara de onde reside o seu valor e onde se concentra o seu risco.\u003c/strong\u003e

Porque devem os CTOs começar por automatizar a entrega, não o código

É genuinamente difícil comparar os resultados da IA entre organizações, porque a maioria dos líderes, tanto na área tecnológica como no resto da empresa, ainda tem dificuldades em medir claramente o impacto e o retorno do investimento dos seus investimentos em IA. Sem isso, é difícil saber como é realmente um bom resultado e ainda mais difícil justificar a necessidade de fazer mais.

Mas, no geral, a variedade de resultados da IA é ampla. Num extremo, trabalhei com organizações que eliminaram efetivamente o seu trabalho acumulado e que agora trabalham diretamente com base no valor para o cliente e nos objetivos da empresa, o que representa uma mudança fundamental na forma como a engenharia se relaciona com o resto da empresa.

Reparei num padrão comum nas organizações que conseguiram isto: nenhuma começou pelo lado esquerdo do ciclo de vida do desenvolvimento de software. Não começaram pela geração de código. Começaram à direita: cadeias de CI/CD, confiança nas implementações e revisão automatizada do código. Tornar primeiro a parte final do processo, a entrega, robusta e fiável foi o que criou as condições para todo o resto. A partir daí, o foco passou para os testes, as restrições e as verificações antes da geração, e para a estrutura em detrimento da velocidade.

As equipas que fizeram mais progressos foram as que operavam de forma mais autónoma, não porque tivessem eliminado o discernimento humano, mas porque tinham codificado uma parte suficiente desse discernimento no seu processo para poderem assumir, com confiança, blocos de trabalho significativamente maiores. O trabalho acumulado não desapareceu porque escreveram código mais depressa. Desapareceu porque toda a relação entre a intenção e a entrega se tornou inequívoca.

No outro extremo, assisti a uma verdadeira perda de pessoal impulsionada pelo fosso crescente entre aqueles que avançam rapidamente com a IA e os que não o fazem. Quando começa a adoção da IA, há quase sempre um pequeno grupo que avança rapidamente e um grupo maior que não o faz, e o instinto natural é deixar os que avançam depressa seguir em frente. O que isso cria, silenciosa e rapidamente, é fricção, desconfiança e suspeita entre equipas, corroendo os ganhos mais depressa do que o progresso inicial consegue acumulá-los. O conselho que agora dou no início de cada colaboração é sempre o mesmo: não deixe ninguém para trás. O ritmo da adoção deve ser definido pela rapidez com que consegue levar toda a organização consigo, não pela rapidez com que os seus engenheiros mais entusiastas conseguem avançar individualmente.

Uma organização a duas velocidades parece estar a progredir para quem está na frente. Para quem está atrás, parece que está a ser deixado para trás, e esse sentimento tem consequências.

Porque deve a base de conhecimento de uma organização ser reformulada para a IA

A lacuna mais clara que tenho observado nas capacidades da IA encontra-se na tomada de decisões em situações de incerteza.

A IA é fundamentalmente um motor de previsão, e a previsão não é o mesmo que discernimento. Não tem nada a perder, não tem noção das consequências nem assume a responsabilidade pelo resultado. Esperar que tome decisões em seu nome nunca será melhor do que a sua capacidade de prever, que é limitada em situações genuinamente incertas ou novas. As organizações que ficaram mais desiludidas com a IA são, geralmente, as que confiaram nela precisamente nesses momentos.

A outra área em que o impacto fica aquém, de forma mais discreta mas igualmente significativa, é aquela em que as implicações das janelas de contexto são mal compreendidas. Forneça a uma IA um contexto incompleto ou mal estruturado e ela continuará a dar-lhe uma resposta confiante. Saber distinguir entre um resultado bem fundamentado e um resultado que apenas parece plausível exige um discernimento humano que ainda não foi desenvolvido por equipas suficientes.

Por este motivo, a base de conhecimento de uma organização é fundamental. Refiro-me a todo o contexto que atualmente vive na cabeça das pessoas: a forma como as coisas sempre foram feitas, as abordagens predefinidas e as regras não escritas sobre o modo como a organização funciona realmente. A IA não consegue trabalhar com conhecimento institucional que nunca foi externalizado, e a maioria das organizações acumula uma quantidade enorme desse conhecimento.

A boa notícia é que extraí-lo não exige que esteja perfeitamente estruturado. A IA multimodal significa que um vídeo explicativo, um diagrama rudimentar e um documento não editado são todos dados de entrada relevantes. A prioridade é primeiro externalizar e só depois estruturar.

O que constato consistentemente é que o próprio ato de retirar este contexto da cabeça das pessoas e colocá-lo sob qualquer forma de documentação é valioso por si só, antes de a IA lhe tocar. Traz à superfície discrepâncias, expõe pressupostos deficientes e revela fluxos de trabalho inadequados que ninguém tinha detetado, por estarem demasiado envolvidos neles.

Essa base multiplica depois tudo o que a IA consegue fazer. É uma das coisas em que um CTO pode investir tempo com maior impacto neste momento e uma das mais frequentemente ignoradas, apesar de os vendedores de Automação de Processos Empresariais nos dizerem isto há anos!

Como impedir que os programadores céticos atrasem uma organização

Um problema comum que observo não é realmente uma falha da IA. É uma falha de adoção e tende a seguir um padrão reconhecível.

Um programador cético — e há um número surpreendentemente elevado deles — faz uma tentativa pouco empenhada, com um contexto mínimo, obtém um resultado fraco e apresenta esse resultado como prova de que a IA não consegue realizar o trabalho. A conclusão é apresentada com confiança. A metodologia raramente é analisada. O que faz com que isto seja mais do que uma simples frustração individual é o efeito subsequente.

A integração da IA numa equipa ou num ciclo de vida de desenvolvimento é um trabalho de equipa, e alguns engenheiros motivados a demonstrar que ela não funciona podem atrasar toda a organização, e não apenas a sua própria produtividade.

A conclusão que retiro daqui não diz respeito às limitações da IA. É que a adoção constitui tanto um desafio de liderança como um desafio técnico. A qualidade do que a IA produz é indissociável da qualidade do contexto e da intenção que lhe transmitimos, e criar esse entendimento numa equipa exige o mesmo esforço deliberado que qualquer outra mudança significativa na forma como as pessoas trabalham. É assim que mudamos a perceção de uma «magia» imperfeita para uma «tecnologia avançada» utilizável.

Adam Partilha

Um programador cético faz uma tentativa pouco empenhada e com contexto mínimo, obtém um resultado fraco e apresenta esse resultado como prova de que a IA não consegue fazer o trabalho. A conclusão é apresentada com confiança. A metodologia raramente é analisada.

Porque é que as equipas pequenas são uma vantagem com a IA

A ideia de que uma equipa de engenharia funcional e produtiva precisava de ter um determinado número de pessoas para reunir contexto suficiente e avançar a um ritmo significativo não resistiu ao contacto com a forma como o desenvolvimento assistido por IA funciona na realidade.

O fator limitativo em qualquer equipa sempre foi cognitivo: quanto contexto cada pessoa consegue manter, com que clareza o consegue comunicar às pessoas à sua volta e quanta energia essa comunicação consome. O que mudou é que a unidade que realiza o trabalho já não é apenas uma pessoa. Cada pessoa da equipa executa vários agentes, e esses agentes transportam e aplicam contexto de formas que alteram completamente os cálculos. A regra das duas pizzas da Amazon era uma heurística razoável num mundo anterior à IA.

Eis um exemplo.

Uma organização com a qual trabalho sempre quis ter uma interface de administração interna para a sua plataforma, mas nunca conseguiu justificar o investimento. Anteriormente, tinha calculado o custo como um esforço de toda a equipa durante vários meses. Em vez disso, colocou duas pessoas no projeto: ambas com um conhecimento profundo do negócio e da plataforma existente, elevada autonomia e um conjunto claro de restrições dentro das quais trabalhar. Seis semanas depois, tinham uma primeira versão funcional.

A familiaridade dessas duas pessoas com o negócio acabou por ser tão importante como as ferramentas de IA. Menos perguntas, menos trabalho indireto, decisões mais rápidas. Mas o resultado mais valioso não foi a ferramenta em si. Foi aquilo que a organização aprendeu sobre como trabalhar desta forma.

As equipas que vejo a trabalhar de forma mais eficaz atualmente têm entre duas e três pessoas, cada uma a executar vários agentes, e isso não é uma limitação. Para o tipo certo de trabalho, é uma vantagem.

Porque é que a comunicação frequente é fundamental nos fluxos de trabalho com IA

A colaboração pode tornar-se difícil com a IA.

É necessária uma comunicação muito mais frequente porque tudo se move mais depressa. É uma das razões pelas quais as equipas mais pequenas funcionam melhor neste momento.

Parece simplesmente demasiado exaustivo manter o estado e a consistência numa equipa grande e com vários processos paralelos de programação agêntica por pessoa. Algumas equipas com as quais trabalho passaram a fazer duas reuniões diárias de acompanhamento para manter a consistência.

Porque é que os CTOs têm de estar atentos à IA clandestina

A IA clandestina é o problema anteriormente observado da TI clandestina, agora com um novo orçamento e um novo nome.

A utilização descontrolada e sem restrições de ferramentas de IA em toda a empresa pode facilmente aumentar os riscos de perda de dados e de propriedade intelectual — "exfiltração", como lhe chama o CISO —, muitas vezes inteiramente sem intenção por parte dos utilizadores.

A maioria das organizações está a sair rapidamente da fase 1 do CMM (a fase de experimentação do "faroeste") para implementar políticas e restrições técnicas que reduzam os riscos.

Porque é que os CTOs têm de se concentrar no seu próprio desenvolvimento

Reflexões de Adam

Os líderes que sairão mais fortes deste período não são necessariamente aqueles que têm as melhores ferramentas ou as maiores equipas. São aqueles que estão a desenvolver o discernimento, a influência e a clareza de pensamento necessários para liderar bem quando ninguém tem um mapa claro.

Existe atualmente muita ansiedade no setor em relação ao significado da IA para as equipas de engenharia, para o número de pessoas e para a própria função.

Se essa ansiedade é justificada é quase irrelevante. O que importa é que estamos num período de mudança significativa e rápida, e geri-lo bem exige líderes que estejam a desenvolver ativamente as suas próprias capacidades, não apenas a gerir a mudança à sua volta.

O que ainda me surpreende, tendo em conta tudo o que está a acontecer, é a quantidade de CTOs e líderes tecnológicos seniores que trabalham sem qualquer investimento dedicado no seu próprio crescimento. Sem um coach, sem desenvolvimento estruturado, sem um parceiro de reflexão. Cometi esse erro uma vez, e os erros que cometi e o tempo que perdi não eram inevitáveis.

Os líderes que sairão mais fortes deste período não são necessariamente aqueles que têm as melhores ferramentas ou as maiores equipas. São aqueles que estão a desenvolver o discernimento, a influência e a clareza de pensamento necessários para liderar bem quando ninguém tem um mapa claro.

Acompanhe

Pode acompanhar o trabalho de Adam Horner no LinkedIn. Para coaching individual, cursos para grupos e o podcast, visite The CTO Playbook. E, para um curso gratuito por email de 5 dias destinado a CTOs em fase inicial, visite Early CTO Map.

Em breve, haverá mais entrevistas com especialistas no The CTO Club!