Como é a excelência em engenharia na era da IA?

Ler a transcrição:

Estamos a experimentar transcrever os nossos podcasts através de um programa de software. Perdoem quaisquer erros de digitação, pois o bot não está correto 100% das vezes.

Hannah Clark: Tornou-se uma piada a forma como a era da IA conduziu ao desaparecimento de todos os empregos na área tecnológica. Na verdade, morreram tantos empregos este ano que fico surpreendida por ainda não ter sido convidada para mais funerais. A gestão de produto morreu, a investigação de utilizadores morreu e, o mais grave de tudo, a engenharia de software morreu. Provavelmente estou a pregar aos convertidos, mas qualquer pessoa que acredite realmente que a engenharia de software morreu porque o seu LLM simpático do bairro consegue escrever código, definitivamente não é engenheiro.

O meu convidado de hoje, Anish Dhar, fundador da Cortex.io, diria até que a engenharia definitivamente não morreu. Está apenas a crescer. Antigo engenheiro da Uber, Anish fundou a Cortex para facilitar a compreensão de bases de código complexas pelos engenheiros. Enquanto engenheiro e alguém cujos utilizadores são engenheiros, o que está a observar neste espaço é, na realidade, uma evolução da excelência em engenharia e uma desconexão entre as formas antigas e novas de a medir. Partilhámos ideias de próxima geração sobre como medir e avaliar a excelência em engenharia, bem como uma opinião controversa sobre a forma como a febre da programação por intuição se enquadra nesta conversa. Vamos começar.

Ah, já agora, temos conversas como esta todas as semanas. Por isso, se isto lhe parece interessante, porque não subscreve? Está bem, vamos começar.

Bem-vindos novamente ao podcast The CPO Club. Estou hoje aqui com Anish Dhar. É o fundador da Cortex.io.

Anish, obrigado por ter reservado tempo para falar comigo hoje.

Anish Dhar: Muito obrigado pelo convite.

Hannah Clark: Sim. Pode falar-nos um pouco sobre o seu percurso e sobre como chegou à função que desempenha atualmente?

Anish Dhar: Sim, claro. Sou cofundador e diretor executivo da Cortex.io. Criámos a empresa há cerca de seis anos, mas antes disso trabalhava como engenheiro na Uber. Comecei realmente a minha carreira lá e muitos dos problemas que enfrentei enquanto engenheiro na Uber inspiraram todas as razões pelas quais criámos a Cortex.

Tinha dois amigos muito próximos. A Uber tem uma arquitetura interna de serviços enorme. Enquanto engenheiro, era muito difícil compreender diferentes partes da base de código, sobretudo quando entrei. Havia tantos serviços diferentes a ser construídos. Isto acrescentava uma complexidade intensa e eu estava a falar com um amigo muito próximo que era engenheiro numa startup muito pequena chamada Lend.

Eles tinham apenas cem engenheiros, enquanto a Uber tinha mais de mil. Mas ambos enfrentávamos desafios semelhantes relacionados com a organização e a compreensão da nossa arquitetura de serviços. E isso fez soar os alarmes: se a Uber está numa extremidade da escala e esta outra empresa, que estava apenas a iniciar o seu percurso com microsserviços, tinha os mesmos problemas, era evidente que este era um grande problema na indústria.

Por isso, acabámos por criar a empresa. Passámos pela turma Winter 20 da Y Combinator. E, avançando até ao presente, acabámos de concluir a nossa Série C e trabalho com algumas centenas de empresas diferentes que utilizam a Cortex para gerir a sua complexidade.

Hannah Clark: Ótimo. É uma jornada incrível e é sempre maravilhoso ouvir falar de uma empresa que nasce das cinzas de um problema que se conhece intimamente.

E, por falar nisso, neste episódio vamos falar sobre excelência em engenharia e sobre aquilo que isso significa no panorama tecnológico atual. É claro que este é um tema que lhe tem sido muito próximo ao longo da carreira. Para começar, como define a excelência em engenharia em 2025 e por que razão se está a tornar uma prioridade tão importante para CTOs e vice-presidentes de engenharia?

Anish Dhar: Sim, é uma excelente pergunta. Na Cortex, descobrimos que, durante muito tempo, a conversa se centrou sobretudo na experiência do programador. E a experiência do programador é uma parte essencial de qualquer organização de engenharia, certo? Inclui coisas simples, como garantir que, quando os programadores entram numa empresa, é muito fácil configurar os sistemas internos e ligá-los ao GitHub e às várias ferramentas que utilizam; ou, quando implementam um serviço, garantir que a infraestrutura está configurada corretamente, para que não haja muita resolução de problemas nem demasiados passos até chegar ao resultado.

Mas o que descobrimos nos últimos anos, sobretudo, é que a conversa mudou muito: deixou de se centrar apenas na experiência do programador e passou a centrar-se no que chamamos excelência em engenharia. Diria que a grande diferença entre ambas é que a excelência em engenharia se concentra realmente no trabalho das diferentes equipas da sua organização.

Pode pensar em SRE, segurança, produtividade dos programadores e até experiência do programador, mas o objetivo é alinhar tudo isso com resultados empresariais concretos. E penso que essa é a principal diferença: a excelência em engenharia consiste em pensar de que forma o trabalho que estou a realizar tem impacto real na empresa e em como a faz avançar.

Os objetivos que temos vão desde a organização do CEO até ao SRE específico que, por exemplo, está a trabalhar no assunto. Um bom exemplo seria: enquanto organização, estamos muito concentrados em melhorar a experiência do cliente e queremos que, quando os clientes utilizam o nosso produto, este seja fiável. Uma melhor experiência do cliente conduz a mais receitas, porque as pessoas utilizam mais o nosso produto.

Assim, no âmbito de uma iniciativa de excelência em engenharia, a sua equipa de SRE poderá ter uma lista de verificação de preparação para produção que está a tentar implementar. Antes de os serviços serem implementados, querem garantir que todos cumprem os padrões da organização. E é possível ver como uma iniciativa que começa na equipa de SRE conduz a um resultado empresarial real com o qual a organização se preocupa.

Penso que é fundamental que as equipas pensem nas suas iniciativas desta forma, porque reafirma o valor e alinha as iniciativas técnicas com algo que a empresa valoriza. É disso que trata, na minha opinião, a excelência em engenharia.

Hannah Clark: Interessante. E isto, tenho a certeza, é algo que já descreveu muitas vezes: uma espécie de jornada interminável, que envolve muitas disciplinas a trabalhar em conjunto.

Fale-me da estrutura que desenvolveu. Quais são os principais pilares? Como aborda esta questão na sua própria organização?

Anish Dhar: Tem toda a razão. É realmente uma jornada interminável. Muitas das empresas com que trabalhamos, sobretudo as maiores ou as grandes empresas, têm muita infraestrutura antiga, ao contrário de uma empresa nova construída com tecnologias mais recentes e talvez orientada para a IA desde a origem.

Continuam a existir diferentes iniciativas relacionadas com a excelência em engenharia e é necessário adotar uma abordagem muito ponderada entre todas estas equipas para perceber qual é o trabalho e de que forma tem impacto, em última análise, nos objetivos de excelência empresarial. Do ponto de vista da estrutura, uma das coisas em que temos trabalhado bastante é: como definir a excelência em engenharia para a sua organização?

A forma como pensamos nisso começa pela excelência empresarial. Existem diferentes objetivos que uma equipa de liderança pode ter, relacionados, por exemplo, com desbloquear a inovação e reduzir o tempo de chegada ao mercado. Podem passar por reduzir custos e aumentar a eficiência. E, normalmente, o terceiro objetivo que vemos, que já mencionei, é melhorar a qualidade e a experiência do cliente.

Abaixo disso estão os pilares da excelência em engenharia. São as diferentes equipas e profissionais que compõem as iniciativas que conduzem a esses objetivos finais. Incluem velocidade, eficiência, segurança e fiabilidade. Mesmo dentro dessas subcategorias, haverá iniciativas como uma migração de segurança ou uma lista de verificação de preparação.

Pode existir um processo de gestão de incidentes que esteja a tentar implementar. Ou algo tão simples como querer acompanhar as métricas DORA para compreender, do ponto de vista da produtividade, qual é o desempenho real da equipa de engenharia. E a base de qualquer iniciativa de excelência em engenharia vem daquilo a que chamamos os quatro C.

São, essencialmente, visibilidade completa, melhoria contínua, experiência consistente do programador e, claro, responsabilidade clara. Sem responsabilidade e sem compreender as diferentes partes da base de código e todos os serviços, é muito difícil fazer avançar estas iniciativas. Normalmente, concluímos que, sem essa base, é muito difícil promover qualquer iniciativa.

Também verificamos habitualmente que as plataformas internas para programadores, ou portais internos, são uma forma muito eficaz de construir essa base. Também podem ser criadas através de ferramentas internas, mas é necessário algum tipo de sistema que permita compreender o que as pessoas estão a construir, para que seja possível impulsionar estas iniciativas de engenharia.

Hannah Clark: Está bem. Quero aprofundar algo que mencionou sobre a medição do desempenho, porque sei que existe alguma tensão em torno da medição da produtividade dos programadores e de métricas como o número de linhas de código.

Pode ser algo controverso entre engenheiros. Como devem os líderes de engenharia pensar na medição da produtividade de uma forma mais holística, que tenha em conta todos estes C e aspetos semelhantes?

Anish Dhar: Sim, claro. O interessante é que, nos últimos anos, muita da produtividade dos programadores tem sido associada ao número de linhas de código ou às métricas DORA. Existem muitas estruturas diferentes que, penso eu, foram criadas para simplificar a forma de pensar sobre a produtividade, e há alguma verdade na forma como essas métricas são calculadas.

O número de linhas de código não é um bom indicador para saber se alguém está ou não a ser produtivo. Mas, se alguém produzir consistentemente zero linhas de código, trimestre após trimestre, há claramente algo errado com o resultado. O mesmo se aplica à comparação entre equipas. Por vezes, é interessante observar esses dados, mas penso que a conversa mudou de “tenho estes dados” para “como faço para que os engenheiros pensem nesses dados ou os melhorem?”.

Se analisarmos a questão, trata-se de um problema completamente diferente e muito mais difícil, porque qualquer pessoa pode aceder à API do GitHub, obter estas métricas e ter uma fotografia do desempenho da equipa. Mas mostrar um conjunto de métricas a um engenheiro e dizer-lhe “temos de melhorar esta métrica” não significa realmente nada para ele, certo?

Estou concentrado em criar software para a empresa e em fazê-lo, normalmente, da forma mais eficiente possível. Penso que a conversa mudou bastante, sobretudo com os CTOs com quem trabalhamos: “Agora tenho estas métricas; como as transformo em algo que seja importante para um engenheiro?”.

E penso que é precisamente aí que a excelência em engenharia desempenha um papel tão importante. Os engenheiros, sobretudo os que trabalham em empresas de crescimento rápido, querem que a empresa cresça. Estão a construir produtos porque querem ver o impacto do seu trabalho nos clientes.

A produtividade do desenvolvimento mudou de “aqui está um conjunto de métricas” para “enquanto empresa, estas são as coisas que valorizamos, e estas métricas contam uma história como parte disso”. Mas, para um engenheiro, a questão é: como traduzir isso em algo que dê significado ao trabalho que estou efetivamente a realizar?

Diria que essa é a grande mudança que temos observado.

Hannah Clark: Tem notado a existência de métodos de avaliação ou KPIs desatualizados dos quais as pessoas estão a começar a afastar-se? O que diria ser a nova escola de avaliação? Tem exemplos específicos que possa partilhar?

Anish Dhar: Sim, sem dúvida. Eu pensaria na produtividade como métricas de entrada e métricas de saída. As métricas de saída são todas as estruturas clássicas que vemos atualmente para acompanhar a produtividade do desenvolvimento. Uma das mais famosas e populares é o conjunto de métricas DORA, que pretende oferecer uma visão holística do desempenho da equipa de engenharia.

Diria que a maioria das organizações de engenharia atuais quer ver estas métricas de saída e tenta captá-las. Mas isso remete para o que referi anteriormente: como influencio efetivamente essas métricas e faço com que evoluam? O que temos observado, sobretudo na nossa base de clientes, e penso que explica parte do crescimento interessante da Cortex nos últimos anos, é o conceito de métricas de entrada que influenciam as métricas de saída.

Por exemplo, consideremos a frequência de implementações. É uma excelente métrica, porque a velocidade a que os engenheiros implementam software é provavelmente um bom indicador da rapidez com que se lança um produto. Em última análise, isso determina a capacidade de superar a concorrência no mercado e de avançar mais rapidamente enquanto empresa.

Talvez a organização tenha decidido que a frequência de implementações é a principal métrica a acompanhar. Se tenho um painel com essa informação e apresento à equipa de engenharia que estamos a implementar duas vezes por semana, mas queremos chegar às quatro, como deve um engenheiro pensar nisso em relação ao seu trabalho, à sua área da empresa ou aos serviços pelos quais é responsável?

Implementar mais rapidamente pode significar que é necessário entregar mais, mas isso conduz a um aumento dos erros? Se estou a entregar mais, a fiabilidade vai diminuir?

Há muitas variáveis envolvidas e é aí que as métricas de entrada se tornam fundamentais, porque influenciam, em última análise, as métricas de saída. No caso da frequência de implementações, pode existir um processo criado especificamente para aumentar essa velocidade.

Posso dar-lhe um exemplo. Um dos nossos clientes, a Riley, tinha uma iniciativa muito semelhante e acompanhava a frequência de implementações através de um dos nossos painéis de inteligência de engenharia. Descobriram que queriam que os engenheiros implementassem mais rapidamente, mas que a forma de o fazer seria estabelecer salvaguardas importantes no processo de implementação e fornecer orientações muito claras sobre o que seria uma boa implementação em relação às suas diretrizes de fiabilidade.

O que acontecia era que os engenheiros tentavam implementar mais rapidamente, mas isso provocava erros ou falhas. Por isso, havia hesitação em avançar tão depressa quanto possível, devido ao impacto nos clientes. Regressando às métricas de entrada, criaram uma lista de verificação de preparação para produção, composta por oito ou nove métricas de entrada diferentes que, em conjunto, permitiam compreender muito bem se o processo de implementação era saudável.

Essas métricas incluíam: o sistema de disponibilidade está corretamente configurado? O processo de compilação está a ser concluído com sucesso? Existem testes a ser aprovados nos serviços? Ao implementar estas métricas de entrada, deram aos engenheiros uma orientação muito clara: “Sou responsável por estes dez serviços. Este é o processo e estas são métricas de entrada que significam algo para mim, porque representam os serviços e o seu funcionamento”.

Observaram um aumento gradual da frequência de implementações, de duas vezes por semana para três e depois quatro, sobretudo nos serviços críticos, bem como uma redução de incidentes e problemas semelhantes.

Por isso, voltando à sua pergunta inicial, penso que muitas empresas estão a pensar: “Temos estas métricas de saída, mas como as traduzimos em algo que seja importante para os engenheiros?”. É necessário pensar na produtividade dos programadores e nas métricas em geral como uma história completa que liga os dois tipos.

Hannah Clark: Sim. Isso torna tudo muito mais, sim. Penso que “holístico” é uma excelente forma de abordar a questão. Mudando ligeiramente de assunto, mas permanecendo no mesmo tema de implementar mais e mais rapidamente, não podemos falar sobre engenharia em 2025 sem falar sobre programação por intuição.

Vamos falar sobre estas ferramentas de IA que estão a transformar os fluxos de trabalho de programação. Já o ouvi dizer que não é possível programar por intuição até chegar a um milhão de utilizadores por dia. Talvez seja uma opinião controversa, talvez não. Qual diria ser a realidade, em oposição à publicidade exagerada, quando se trata de utilizar IA em ambientes de produção à escala?

Anish Dhar: É certamente um tema muito atual e penso que todas as organizações de engenharia estão a pensar em IA ou já adotaram algum tipo de assistente de programação com IA. Existem vários muito populares no mercado, incluindo o Cursor. Até a equipa de engenharia da Cortex utiliza quase toda algum tipo de assistente de programação com IA para ajudar no trabalho diário.

Mas o que descobrimos ao falar com os engenheiros da nossa equipa e ao trabalhar com a maioria dos nossos clientes, que têm considerado iniciativas semelhantes, é que os assistentes de programação com IA são ótimos quando se tem uma ideia inicial e se pretende validá-la rapidamente. Também são úteis para um engenheiro de front-end que queira criar rapidamente um protótipo visual, passando de uma ideia para uma representação do seu aspeto e funcionamento.

Do ponto de vista do processo de desenvolvimento, é perfeito para esse tipo de situação. Pretende-se algo rápido e rudimentar, apenas para mostrar às pessoas como algo pode funcionar. Ou, se um empreendedor tiver uma ideia, pode validá-la rapidamente. É por isso que se observa um crescimento tão impressionante destas ferramentas.

Mas a realidade atual dos assistentes de programação e da programação por intuição é que nunca se pode confiar no código produzido desta forma para alimentar um sistema de produção utilizado por milhões de utilizadores. Essa é simplesmente a experiência que temos observado.

No fim de contas, penso que a programação por intuição é, na melhor das hipóteses, equivalente a um engenheiro júnior que acabou de aprender a programar. É muito diferente de engenheiros seniores e principais que compreendem o desenho de sistemas e sabem como a infraestrutura é realmente implementada à escala. Ainda estamos muito longe desse ponto, embora não esteja a dizer que não possamos lá chegar.

A velocidade a que a IA está a evoluir é inacreditável. Seria insensato afirmar que nunca poderá existir um mundo em que os sistemas de IA compreendam instâncias reais de produção. Mas, atualmente, posso afirmar com segurança que não existe nenhuma empresa que dependa da programação por intuição para alimentar um sistema de produção que lide com milhões ou milhares de milhões de utilizadores.

O nível de competência técnica necessário para configurar esses sistemas, diagnosticar problemas e garantir a sua capacidade de expansão ainda está muito longe de ser alcançado. Porém, de um modo geral, diria que a produtividade melhorou com os assistentes de programação. Simplesmente melhorou em áreas diferentes daquelas sobre as quais o mercado gosta de falar, ou daquelas em que é mais apelativo falar de programação por intuição.

A realidade é que ainda não está preparada para sistemas empresariais de produção.

Hannah Clark: Penso que isto é muito compreensível para muitos profissionais que sentem que pessoas externas à sua profissão estão entusiasmadas com a acessibilidade que as ferramentas de IA oferecem, mas isso não significa necessariamente que essas ferramentas estejam prestes a substituir os profissionais.

É um tema importante. Temos líderes a ouvir o programa. Para os líderes de engenharia que tentam equilibrar o investimento em ferramentas de IA com o número de colaboradores, o que devem considerar? Na sua perspetiva, como se avalia o impacto real da IA na produtividade de uma equipa e como se incorpora isso no orçamento?

Anish Dhar: É uma excelente pergunta. Existem vários aspetos diferentes. Em última análise, olhando para a engenharia de uma perspetiva muito abrangente, penso que as equipas ou líderes de engenharia que impedem as suas equipas de analisar estas ferramentas ou de lhes aceder — por exemplo, ferramentas como o Cursor ou o GitHub Copilot — estão a prestar um mau serviço à saúde e à qualidade geral da sua equipa a longo prazo.

Na próxima década, muitos dos sistemas, ou pelo menos o código inicial que as pessoas escreverão, terão assistência de IA. Se alguém estiver a iniciar uma empresa ou uma ideia, ou quiser iterar e testar algo rapidamente, a realidade é que fazê-lo com uma ferramenta como o Cursor é dez vezes mais rápido. É possível iterar rapidamente sobre as ideias sem ter de pensar muito na escala ou no funcionamento de tudo.

Mesmo adotando uma perspetiva de longo prazo, é por isso que as equipas de engenharia que adotam estas ferramentas de IA e aprendem a utilizá-las em diferentes partes do ciclo de vida da programação — incluindo as maiores empresas, onde são necessários sistemas de produção à escala — estarão em vantagem relativamente às pessoas que dizem que tudo não passa de publicidade exagerada.

Penso que é muito importante que os líderes de engenharia permitam às suas equipas explorar estas ferramentas e até deem acesso a utilizadores não técnicos. Essa é provavelmente a inovação mais interessante que tenho observado, sobretudo na nossa base de clientes: gestores de produto, gestores técnicos de programas e cientistas de dados que compreendem conceitos técnicos, mas talvez não tenham experiência suficiente para programar, conseguem pegar em ideias e partilhá-las com a equipa de engenharia de uma forma muito mais poderosa, porque podem efetivamente criar código e soluções semelhantes.

A partir dessa perspetiva, seria muito imprudente não criar um orçamento para dar aos engenheiros acesso a estas ferramentas.

Agora, a pergunta de um milhão de dólares é: quanto aumentámos realmente a produtividade? E, sinceramente, penso que todas as empresas estão a tentar responder a isso neste momento. Vemo-lo constantemente. Muitas vezes, os clientes compram o nosso produto em conjunto com algo como o GitHub Copilot.

A primeira pergunta que nos fazem é: “Temos esta ferramenta que supostamente multiplica por três ou quatro a produção da nossa equipa de engenharia. Queremos perceber se isso está realmente a acontecer”. E penso que a resposta remete para o sistema anterior de métricas de entrada e de saída.

Não basta apresentar a frequência de implementações e dizer que o GitHub Copilot teve impacto nessa métrica. Talvez o Copilot esteja a fazer com que a equipa implemente mais rapidamente, mas o código pode ser muito mau e conduzir a problemas de fiabilidade. É necessário adotar uma visão quase de 360 graus e analisar métricas diferentes.

Em última análise, isto remete para a excelência em engenharia. Como empresa, esquecendo a programação por intuição e tudo o resto, em que estamos concentrados agora? O que nos impede de alcançar o próximo nível de crescimento? Qualquer que seja o objetivo empresarial, é preciso perguntar se a introdução do assistente de programação ou da ferramenta de IA está realmente a fazer a diferença ou a ter impacto nesse objetivo.

Durante algum tempo, talvez não se veja qualquer impacto ou diferença, porque é necessário tempo para compreender onde estas ferramentas terão impacto na empresa. O erro que vejo muitas empresas cometerem é aderirem imediatamente à publicidade exagerada: compram 5 000 licenças de qualquer ferramenta interessante que encontram e, seis meses depois, perguntam-se se houve realmente algum impacto.

Sem uma estratégia ponderada sobre a razão pela qual estão a introduzir estas ferramentas, podem ter uma reação muito negativa. Talvez a estratégia seja não querer ficar para trás e querer que os engenheiros continuem a sentir que estão num local de trabalho de vanguarda. Pode simplesmente considerar-se vantajoso ter ferramentas com assistência de IA na equipa de engenharia.

Mesmo que seja algo tão simples como isso, pelo menos conhece-se a intenção por detrás da compra. Talvez esse seja o erro: compreender as intenções e, ao longo do processo, verificar se as ferramentas estão realmente a fazer aquilo que se esperava.

Hannah Clark: Concordo. Penso que existe atualmente muita pressão para dominar estas ferramentas e compreender onde se enquadram no fluxo de trabalho. É útil, mas também concordo que, neste momento, em muitos departamentos, estamos a deparar-nos com uma diferença enorme entre a quantidade de resultados produzidos e a qualidade dos resultados.

Estamos a ter de ser muito intencionais, não apenas nos departamentos de engenharia, mas também na aplicação destas ferramentas no contexto certo, para facilitar e potenciar o melhor dos nossos colaboradores, em vez de tentarmos cegamente contabilizá-las como se o número de colaboradores do próximo ano fosse inferior porque as ferramentas de IA os poderão substituir.

É interessante ver toda a gente a tentar perceber isto de formas diferentes ao mesmo tempo. É uma época muito desorientadora para trabalhar na área tecnológica. Falando das ferramentas de IA e da sua crescente presença nos fluxos de trabalho de desenvolvimento, e falando também de qualidade, como pensamos em encontrar o equilíbrio entre manter a qualidade do código, os padrões de segurança e a fiabilidade, ao mesmo tempo que queremos garantir que somos locais de trabalho de vanguarda e aproveitamos ao máximo a funcionalidade destas ferramentas?

Por exemplo, como abordaram essa questão na sua organização?

Anish Dhar: É uma pergunta muito pertinente. E, muito brevemente, direi que a ideia de a IA estar a substituir engenheiros é absurda e está muito longe da realidade. O que é verdade é que, quando se está a começar, talvez seja possível contratar menos alguns engenheiros do que os quinze que se contratariam anteriormente, porque, nos primeiros tempos de iteração e de procura de adequação entre produto e mercado, é possível fazer muito mais com uma ferramenta como o Cursor.

Pode experimentar rapidamente dez ideias diferentes. A velocidade de iteração é muito poderosa. Mas, quando se começam efetivamente a implementar sistemas de produção, as empresas que dizem que não precisam de contratar tantos engenheiros por causa da IA estão apenas a tentar obter atenção mediática.

Não há forma de isso ser verdade. Sei-o com certeza.

Hannah Clark: Sem mencionar nomes.

Anish Dhar: Sim. Todos eles continuarão a contratar. Os engenheiros nunca deixarão de ser procurados. Mas, voltando à sua pergunta sobre o impacto das ferramentas de IA e dos sistemas de programação com IA em pilares fundamentais como a fiabilidade e a segurança, penso que essa é, honestamente, a grande questão em aberto neste momento.

É provavelmente o que mais assusta estas equipas e equipas como as de SRE, segurança ou excelência operacional, porque a introdução destas ferramentas acaba por criar uma maior superfície de ataque: as pessoas estão simplesmente a entregar mais código.

Quanto maior for a parte do sistema construída com IA, maior é a probabilidade de não se compreender verdadeiramente como tudo funciona internamente. E isso significa que, quando inevitavelmente surgir um problema de fiabilidade — porque esses problemas existirão sempre, por muito que se prepare tudo — será muito mais difícil lidar com ele.

Pode tratar-se de uma afluência inesperada de utilizadores ou de uma parte da base de código que não foi totalmente compreendida e que falha. Quanto mais o sistema depender de assistência de IA, mais difícil será a situação, porque, enquanto engenheiro, como se pode percorrer todas as diferentes partes da base de código se não se compreende totalmente o seu funcionamento?

Penso que essa é talvez a maior desvantagem que vejo atualmente. É por isso que a camada fundamental da excelência em engenharia se torna mais importante do que nunca. Falei anteriormente de visibilidade completa e responsabilidade clara como pilares essenciais de qualquer iniciativa de excelência em engenharia.

Quanto maior for a parte dos sistemas criada através de IA, menor será a cobertura desses aspetos, porque quem é efetivamente responsável por essa parte e quem compreende a sua visibilidade? Penso que são precisamente estas as coisas que assustam muitas equipas de segurança e de fiabilidade.

Vemo-lo com alguns dos nossos clientes e também na nossa própria equipa de engenharia. Quando publicamos código criado com IA, os engenheiros têm o cuidado de indicar que uma parte foi gerada a 100% através do Cursor ou de outra ferramenta e analisam esses sistemas com especial atenção.

Tenho observado uma grande tendência para os testes assistidos por IA. Existem muitas empresas a criar uma espécie de engenheiro de IA que analisa os testes. Por vezes, isso parece-me um pouco arriscado, porque, no fim de contas, os sistemas de IA são extremamente poderosos e atualmente fazem mais bem do que mal nas equipas de engenharia.

Mas é assustador imaginar um mundo em que 80% do sistema tenha sido criado com IA. Isso poderá conduzir a problemas de fiabilidade e fazer com que a resolução dos problemas do sistema demore mais tempo. Os incidentes de segurança poderão aumentar, porque haverá simplesmente menos visibilidade. É isso que é necessário vigiar.

Hannah Clark: Concordo, e penso que esse é o problema logístico menos abordado com que muitas equipas se deparam quando se trata de aumentar os resultados, o que também significa aumentar a necessidade de supervisão.

Na semana passada, conversámos com o vice-presidente sénior de gestão de produto da Mastercard Gateway, que falava sobre a forma como muitas ferramentas de IA estão a acelerar a capacidade de concluir tarefas como o preenchimento de formulários para entrar em novos mercados. A quantidade enorme de documentação necessária para entrar num novo mercado e cumprir todos os regulamentos pode ser tratada muito rapidamente com IA.

Mas também tem de existir um nível de supervisão que garanta a responsabilidade por essas submissões. Existe, portanto, uma espécie de equilíbrio: é possível concluir o trabalho mais rapidamente, mas também é necessário ser responsável ao mesmo ritmo.

Parece ser um grande estrangulamento logístico para muitas equipas de engenharia, bem como para outras pessoas que utilizam estas ferramentas para acelerar o trabalho. É uma camada que merece ser reforçada: podemos entregar rapidamente, mas conseguimos também afirmar, ao mesmo ritmo, que somos responsáveis por esse trabalho?

É muito interessante falar sobre isto. Já conversámos com líderes de todos os tipos de departamentos e disciplinas e é fascinante ver como muitas destas preocupações são tão semelhantes, apesar de a própria disciplina ser tão diferente.

Agradeço sinceramente todos os conhecimentos que partilhou hoje. Este episódio chega ao fim. Onde é que as pessoas podem acompanhá-lo online, Anish?

Anish Dhar: Podem seguir-me no LinkedIn ou no Twitter. Basta pesquisarem o meu nome. Também podem encontrar a Cortex no LinkedIn.

Estamos sempre a publicar conteúdos e estamos a organizar conferências Android Access em várias partes do mundo. Se houver uma na sua cidade, apareça. Gostamos de criar uma comunidade de pessoas que pensem sobre este tipo de questões. Todas as empresas estão a pensar nelas, por isso é muito interessante ver nascer uma comunidade tão forte em torno do tema.

Também começámos a organizar a nossa conferência, chamada IDPCON, que se centra na excelência em engenharia. Temos líderes de diferentes tipos de empresas e programadores que estão interessados em estabelecer contacto com outros programadores em torno da excelência em engenharia.

Haverá muitas conversas excelentes. Será em Nova Iorque, em outubro, por isso esperamos vê-los lá também.

Hannah Clark: Sim, parece fantástico. Obrigada pela informação. Vamos certamente incluir isso na caixa de descrição. E muito obrigada por ter reservado tempo para se juntar a nós.

Anish Dhar: Obrigado pelo convite. Foi ótimo.

Hannah Clark: Obrigada por nos ouvirem. Para obter mais informações, guias práticos e avaliações de ferramentas, subscreva a nossa newsletter em theproductmanager.com/subscribe. Pode ouvir mais conversas como esta subscrevendo o The CPO Club onde quer que ouça os seus podcasts.