Responsável global pela arquitetura de IA afirma que a IA é uma mudança no modelo operacional, não uma implementação de ferramentas

Manish Jain é VP e Diretor Global de Arquitetura de IA na Firstsource, onde lidera uma equipa de 50 pessoas. Atualmente, o seu foco está na criação de sistemas agênticos capazes de lidar com trabalho composto por várias etapas.

Sentámo-nos com Manish para perceber como a IA está a alterar o seu modelo operacional. Eis o que nos disse.

Do potencial a uma capacidade pronta para produção

Sou Manish Jain, um líder de IA e tecnologia focado em ajudar as organizações a transformar o potencial da IA numa capacidade fiável e pronta para produção. Baseio o meu trabalho na realidade prática da transformação. Nos últimos anos, liderei muitas iniciativas de IA e ML, colaborei estreitamente com equipas de negócio e trabalhei em engenharia e implementações nas quais o sucesso depende de muito mais do que selecionar o modelo certo. A arquitetura, a qualidade dos dados, a segurança, a integração, a adoção pelos utilizadores e um valor empresarial claro têm de estar alinhados.

Atualmente, lidero iniciativas de IA numa organização multifuncional com cerca de 50 pessoas, incluindo engenheiros de software e de plataformas, profissionais de IA e dados, líderes de produto, parceiros de segurança e especialistas dos domínios de negócio. O trabalho abrange a implementação de IA empresarial e a prestação de serviços diretamente no terreno. As equipas trabalham em estreita colaboração com clientes e partes interessadas internas para levar casos de utilização de elevado valor desde a descoberta até à implementação segura e escalável em produção.

A nossa abordagem é intencionalmente independente da nuvem e do modelo. Implementamos principalmente no Azure e na AWS e utilizamos seletivamente o Google Cloud com base no ambiente do cliente, no ecossistema de dados e nas necessidades operacionais. Em vez de conceber arquiteturas em torno de um único fornecedor de serviços na nuvem ou modelo de base, criamos arquiteturas modulares que nos permitem escolher e evoluir os componentes subjacentes à medida que os requisitos mudam. Isto inclui a camada do modelo, os serviços de recuperação e dados, a estrutura de orquestração, as ferramentas de avaliação, a observabilidade e os controlos de segurança.

A verdadeira complexidade não está simplesmente em selecionar um LLM. Está em integrar a IA nos fluxos de trabalho empresariais, abrangendo fontes de dados fragmentadas, aplicações legadas, diferentes permissões de utilizador e requisitos rigorosos em matéria de segurança, fiabilidade, custos e conformidade. Normalmente, começamos com um caso de utilização específico e uma avaliação rigorosa e, depois, colocamos em produção aquilo que funciona através de barreiras de proteção, supervisão humana quando apropriado, monitorização e iteração contínua. O objetivo é criar capacidades de IA que permaneçam adaptáveis à medida que a tecnologia evolui e sejam suficientemente fiáveis para que as equipas possam contar com elas todos os dias.

Interessa-me especialmente a transição de copilotos individuais para sistemas agênticos capazes de lidar com trabalho composto por várias etapas dentro de limites definidos. Para os líderes tecnológicos, a oportunidade é significativa, mas concretizá-la exige uma engenharia disciplinada, uma governação ponderada e um forte foco nos resultados.

Por que razão a implementação de IA com avaliação desde o início melhora os resultados

No último ano, passei de uma mentalidade de implementação de IA baseada em protótipos para uma disciplina de engenharia baseada na avaliação desde o início. Há um ano, as equipas criavam frequentemente provas de conceito impressionantes com rapidez, ligando fluxos de trabalho a modelos individuais. No entanto, muitas vezes abordavam demasiado tarde os fatores que determinam a fiabilidade da IA em produção — qualidade, fundamentação, controlo de acesso, gestão de falhas, custos e responsabilização dos utilizadores.

Introduzimos um padrão de implementação partilhado no qual cada caso de utilização de IA começa com uma definição clara de sucesso, dados de avaliação representativos, uma análise da segurança e do acesso aos dados, rastreabilidade e monitorização contínua. Também criámos a arquitetura subjacente de forma independente da nuvem e do modelo. Isto permite às equipas avaliar a combinação certa de modelos, abordagens de recuperação e padrões de orquestração para cada fluxo de trabalho, sem limitar o produto a um único fornecedor ou geração de modelos.

Na prática, isto resultou em menos retrabalho e numa maior confiança nas implementações em produção. As equipas conseguem identificar regressões de qualidade ou de custos antes de estas afetarem os utilizadores, tomar decisões explícitas sobre os pontos em que deve existir revisão humana e melhorar os sistemas com base em evidências, em vez de opiniões anedóticas.

Olhando para o futuro, acredito que isto constitui a base para uma IA agêntica responsável. À medida que os sistemas deixam de se limitar a responder a perguntas e começam a executar ações compostas por várias etapas em fluxos de trabalho empresariais, não podemos acrescentar a avaliação, a observabilidade, as permissões e a governação posteriormente. Estes elementos têm de fazer parte da estrutura de engenharia desde o primeiro dia.

Como os seres humanos se tornam mais importantes com a engenharia agêntica

Utilizamos IA em todo o ciclo de vida do produto. Na descoberta, converte os contributos das partes interessadas, o feedback dos clientes e a documentação existente em requisitos iniciais, histórias de utilizador, critérios de aceitação e questões técnicas. Na engenharia, apoia a descoberta da base de código, a documentação, a implementação, a refatoração, a preparação de pedidos de incorporação e a geração de testes. Nas operações, resume registos, estabelece correlações entre alertas e versões recentes, recupera o contexto de incidentes anteriores e reduz o espaço de pesquisa durante a triagem. As equipas passam menos tempo a reunir contexto entre ferramentas e mais tempo a validar decisões, resolver problemas complexos e fazer avançar a implementação.

Mantemos a cargo dos seres humanos a responsabilidade pela arquitetura, a aprovação de segurança, as decisões relativas ao acesso aos dados, a aprovação de lançamentos e as decisões de compromisso em matéria de prioridades. Estas decisões exigem contexto empresarial, responsabilização e uma compreensão das consequências que vai além do que um ticket, um prompt ou um repositório de código contém. A IA pode analisar alternativas, identificar dependências, sinalizar preocupações de segurança e reunir evidências, mas é um engenheiro ou líder responsável que toma a decisão.

Fazemos deliberadamente esta distinção à medida que avançamos para uma engenharia mais orientada por agentes. Espero que a IA assuma mais tarefas de execução delimitadas, como implementar alterações bem definidas, gerar e executar testes, validar critérios de implementação ou propor medidas de remediação de incidentes. À medida que isto acontece, o papel humano torna-se mais importante, não menos. Os engenheiros definem a intenção, as permissões, os limiares de qualidade e os limites de reversão, validando depois se o sistema alcançou o resultado pretendido.

Como a IA impulsiona eficazmente os fluxos de trabalho de engenharia de ponta a ponta

Eis o nosso fluxo de trabalho de ponta a ponta, que leva um pedido de produto bem definido desde o design, passando pela implementação e validação, até ao lançamento em produção. Começa quando um gestor de produto e um líder de engenharia definem o resultado para o cliente, as restrições e os critérios de aceitação. A IA sintetiza então o contexto empresarial relevante, a documentação existente, os padrões arquiteturais e as dependências, integrando-os num rascunho de design técnico, num plano de implementação e numa estratégia de testes. Um engenheiro revê esse plano, toma as decisões de arquitetura e divide o trabalho em pequenas alterações que podem ser verificadas de forma independente.

Durante a implementação, os engenheiros utilizam a IA no código-fonte para compreender os serviços relevantes, gerar o código inicial e as alterações de configuração, atualizar a documentação e criar testes unitários e de integração. Todas as alterações continuam a passar pelo controlo de versões, por verificações automatizadas de CI, pela revisão por pares, pela análise de segurança e pelo processo de lançamento estabelecido. Se um teste falhar, a IA interpreta a falha, identifica a provável dependência ou regressão e propõe uma correção, mas o engenheiro verifica a correção antes de esta avançar.

Após a implementação, o fluxo de trabalho continua. A IA resume os registos da aplicação, correlaciona anomalias com lançamentos recentes e apresenta ao engenheiro de serviço os incidentes anteriores ou os manuais de procedimentos relevantes. Medimos o ciclo completo através do tempo de execução, da cobertura de testes, da taxa de falhas de alterações, da frequência de reversões e do tempo até à resolução.

Isto não é desenvolvimento de software autónomo. É um sistema de entrega liderado por seres humanos e aumentado por IA, no qual a IA acelera a recolha de contexto e a execução, enquanto os engenheiros mantêm a responsabilidade pelo design, pela qualidade, pela segurança e pelo resultado em produção.

O que Manish nos diz

A IA reduziu significativamente o tempo que os engenheiros gastam a recolher contexto e a produzir a primeira versão de trabalho rotineiro. Ajuda as equipas a passar mais rapidamente de um requisito inicial para uma abordagem técnica estruturada, implementação, cobertura de testes e documentação.

Como a IA cria um fluxo de trabalho melhor entre funções

Quanto aos resultados, a IA reduziu significativamente o tempo que os engenheiros gastam a recolher contexto e a produzir a primeira versão de trabalho rotineiro. Ajuda as equipas a passar mais rapidamente de um requisito inicial para uma abordagem técnica estruturada, implementação, cobertura de testes e documentação. Acelerou o desenvolvimento de novas funcionalidades e capacidades de produto, sobretudo quando os engenheiros precisam de analisar uma base de código desconhecida, rastrear dependências ou trabalhar em vários serviços.

A IA também contribui para as decisões de arquitetura. Pode sintetizar rapidamente a documentação existente do sistema, identificar dependências, comparar opções de implementação, revelar compromissos prováveis e ajudar as equipas a criar registos de decisões de arquitetura. Os seres humanos tomam as decisões finais de arquitetura, mas as equipas chegam a essas discussões com um contexto melhor. Podem dedicar mais tempo a debater as decisões que realmente importam, como a escalabilidade, a resiliência, a segurança, o custo e a facilidade de manutenção a longo prazo.

A melhoria não consiste simplesmente numa geração de código mais rápida. Observamos um fluxo melhor ao longo do ciclo de vida, porque as equipas de produto, engenharia, QA e operações começam com um contexto mais completo e consistente. Os engenheiros dedicam mais tempo ao design do sistema, aos casos-limite, à complexidade da integração e ao impacto no cliente, em vez de reunirem manualmente informações de repositórios, tickets, painéis, registos e incidentes anteriores.

Como deve ser medido o sucesso com IA

Também aprendemos lições importantes sobre as desvantagens. A IA pode criar uma falsa sensação de velocidade quando as equipas aceitam resultados plausíveis sem uma validação suficiente. Pode gerar código que parece correto, mas que não se adequa à arquitetura envolvente, não contempla regras de negócio subtis, introduz complexidade desnecessária ou cria problemas de segurança e manutenção. Os ganhos de produtividade também são desiguais. Os engenheiros que compreendem o sistema, definem o enquadramento com precisão e validam rigorosamente os resultados são os que mais beneficiam.

É por isso que medimos o sucesso através da qualidade da entrega, e não através de métricas de atividade da IA. Os resultados que nos interessam são uma entrega mais rápida de funcionalidades, um tempo de ciclo mais curto, lançamentos estáveis, uma cobertura de testes mais abrangente, menos retrabalho, uma resolução mais rápida de incidentes e uma fiabilidade sustentada. A oportunidade a longo prazo é significativa, mas apenas se a IA melhorar o discernimento e a execução de engenharia, em vez de se tornar um substituto de qualquer um deles.

Como as novas limitações alteram as estruturas das equipas

A geração de código já não é o fator limitador da velocidade de engenharia. As verdadeiras limitações são frequentemente requisitos pouco claros, contexto de negócio fragmentado, dependências arquiteturais, revisão de segurança, integração entre sistemas e o tempo necessário para validar se uma alteração funciona de forma segura em produção. Os dados do setor apontam na mesma direção: a programação representa uma parcela relativamente pequena do dia de um engenheiro, e a adoção da IA na programação não se traduz automaticamente em ganhos de produtividade proporcionais.

Isso alterou a forma como penso na estrutura das equipas. Em vez de tratarmos simplesmente a IA como uma forma de reduzir o esforço de entrega, estamos a avançar para equipas mais pequenas e multifuncionais, com uma maior responsabilidade desde a descoberta até à aprendizagem em produção. Os engenheiros precisam de passar menos tempo a criar primeiros rascunhos e mais tempo a definir a intenção, a estruturar a arquitetura, a validar os resultados e a melhorar o sistema após o lançamento.

Além disso, o nosso foco no recrutamento mudou da produção de código pura para o pensamento sistémico, o discernimento sobre o produto e a validação do trabalho apoiado por IA. Valorizamos engenheiros que consigam lidar com a ambiguidade, fazer escolhas ponderadas entre arquitetura e segurança e assumir a responsabilidade pelos resultados em produção.

Manish diz-nos

O futuro não consiste apenas numa implementação mais rápida. Consiste num alinhamento mais rápido e num ciclo mais curto entre uma ideia, um resultado em produção e a aprendizagem que orienta a decisão seguinte.

O futuro não consiste apenas numa implementação mais rápida. Consiste num alinhamento mais rápido e num ciclo mais curto entre uma ideia, um resultado em produção e a aprendizagem que orienta a decisão seguinte.

Porque é que os testes precisam de ser reformulados para um futuro potenciado pela IA

Os testes precisam de ser reformulados.

A IA está a tornar muito mais rápida a criação de código, o que significa que a garantia de qualidade tem de se tornar contínua, automatizada e integrada no fluxo de entrega, em vez de ser tratada como uma barreira final. As equipas precisam de geração de testes assistida por IA, conjuntos de dados de avaliação realistas, verificações de segurança e desempenho, monitorização em produção e uma responsabilidade humana clara pelas exceções.

Num ciclo de vida potenciado pela IA, a vantagem competitiva não será de quem gera código mais rapidamente, mas de quem consegue validar alterações em segurança e aprender com a produção mais depressa.

Como evitar precocemente os obstáculos relacionados com a IA

Subestimámos as realidades operacionais da IA. O consumo de tokens e os limites de utilização podem restringir significativamente a entrega, sobretudo nos fluxos de trabalho de programação baseados em agentes que necessitam de um contexto abrangente da base de código ou de iterações repetidas. Atualmente, tratamos as despesas com IA como uma decisão sobre a capacidade de engenharia, com visibilidade sobre a utilização, o encaminhamento de modelos, a gestão do contexto e o valor produzido — e não apenas como um custo de licença. A fiabilidade do serviço também é importante. Um modelo externo ou uma plataforma de programação pode sofrer problemas de latência, limitação de taxa ou disponibilidade, pelo que os fluxos de trabalho críticos precisam de modelos alternativos, degradação controlada e formas de os engenheiros continuarem a trabalhar sem o serviço de IA.

Podíamos ter evitado os obstáculos iniciais se tivéssemos definido desde o início ferramentas aprovadas, limites claros para os dados, expectativas de revisão, controlos de custos e padrões de contingência.

Também não imporia prematuramente uma única ferramenta ou um único fluxo de trabalho. A tecnologia está a mudar demasiado depressa. A melhor abordagem é disponibilizar acesso seguro, mecanismos de controlo reutilizáveis, oportunidades de aprendizagem entre pares e uma responsabilização clara. Um engenheiro continua a ser responsável pelo que concebe, revê, integra e opera em produção.

Porque é que a IA deve ser tratada como uma mudança do modelo operativo

O meu conselho aos CTO é que tratem a IA como uma mudança do modelo operativo, não como a implementação de uma ferramenta. Comecem com um pequeno número de fluxos de trabalho de elevado valor, nos quais possam estabelecer uma referência, medir o impacto e aprender rapidamente. Criem uma plataforma de IA partilhada e uma disciplina de entrega assentes em modelos aprovados, acesso seguro aos dados, avaliação, observabilidade e padrões de integração reutilizáveis, mantendo a arquitetura independente da cloud e do modelo. Isto evita que todas as equipas reinventem os mesmos controlos ou fiquem demasiado cedo dependentes de um fornecedor.

Igualmente importante é investir nas pessoas. As organizações que mais irão beneficiar não serão simplesmente aquelas que gerarem mais código. Serão as que ajudarem os engenheiros, as equipas de produto, os parceiros de segurança e os líderes empresariais a aprender a definir claramente o trabalho, validar os resultados da IA e operar sistemas agênticos dentro de limites definidos. Avancem com urgência, mas tornem a confiança, a qualidade, a segurança e os resultados mensuráveis inegociáveis.

A IA está a tornar-se uma camada central de execução para a empresa, pelo que o papel do CTO é criar a arquitetura, a governação e a cultura que lhe permitam crescer de forma responsável.

Acompanhe

Pode acompanhar o trabalho de Manish Jain no seu Substack e LinkedIn.

Haverá mais entrevistas com especialistas no The CTO Club!