CTO Circle: lições de líderes de engenharia na construção de organizações nativas em IA

Todos os líderes de engenharia estão tentando responder às mesmas perguntas à medida que a IA muda as regras do jogo: Como as equipes de engenharia devem ser organizadas? Onde as organizações devem investir à medida que os modelos de base continuam a melhorar? Como aumentar a velocidade de engenharia sem introduzir riscos operacionais inaceitáveis? Qual é a diferença entre organizações AI-augumented e organizações nativas em IA? 

Não existe um padrão estabelecido para construir uma organização de engenharia nativa em IA, e há poucas oportunidades para que líderes de engenharia comparem abertamente o que estão aprendendo. Essas conversas, em geral, ficam restritas a empresas individuais, sendo influenciadas por pressões competitivas e pela tecnologia em rápida evolução. 

Como a plataforma em que milhares de organizações constroem suas estratégias de dados e IA, a Snowflake está em uma posição única para promover essas conversas. O CTO Circle é um evento que foi criado para oferecer aos líderes de engenharia um fórum confiável para aprender com colegas que enfrentam a mesma transformação e debater hipóteses. Realizado durante o Snowflake Summit 2026, em San Francisco, o evento inaugural reuniu mais de 350 CTOs de diversos setores, incluindo serviços financeiros, telecomunicações, varejo e tecnologia, para trocar lições práticas. 

A discussão foi muito além dos assistentes de código e da seleção de modelos. Em vez disso, o foco foi em como as organizações de engenharia estão se reestruturando, o que está dando certo em produção e onde os líderes estão investindo para criar uma vantagem competitiva de longo prazo. A discussão convergiu em torno de três temas que definem o que significa construir uma organização de engenharia nativa em IA: o uso da IA em produção, o equilíbrio entre velocidade e risco, e o design de equipes de engenharia para a IA.

Muitas organizações começam sua jornada de IA integrando assistentes de código aos fluxos de trabalho de engenharia já existentes. Os desenvolvedores escrevem código um pouco mais rápido, e a documentação se torna mais fácil de produzir. Essas melhorias são boas, mas não mudam muito o sistema de engenharia subjacente.

Vivek Raghunathan, SVP de engenharia da Snowflake, desafiou os líderes a pensar de forma muito mais ampla sobre a adoção de IA. O argumento que Vivek apresentou foi que a construção de uma organização de engenharia nativa em IA começa com uma mudança na filosofia de gestão. Em vez de considerar a produtividade dos desenvolvedores um problema de engenharia ou de cultura, a Snowflake começou a tratá-la como um produto.

"E se você tratasse seus desenvolvedores como clientes?" Essa pergunta tornou-se a base de como a Snowflake abordou sua própria transformação de engenharia. Em vez de supor que a liderança sabia o que os engenheiros precisavam, a equipe aplicou os mesmos princípios de gestão de produtos usados para criar produtos voltados para clientes. 

A equipe entrevistou desenvolvedores para entender onde o trabalho perdia velocidade e mapeou pontos de atrito em todo o ciclo de vida de desenvolvimento de software. Em seguida, a equipe estabeleceu métricas de padrão de referência e realizou experimentos para avaliar o impacto de cada mudança. O método combinou patrocínio executivo claro com adoção de baixo para cima. Isso garantiu que as melhorias refletissem como os engenheiros realmente trabalhavam, e não como os líderes esperavam que eles trabalhassem.

Os resultados obtidos foram mensuráveis. Em 18 meses, a Snowflake aumentou seu Net Promoter Score interno de desenvolvedores em mais de 30 pontos. Isso resultou em uma proporção de 4:1 entre desenvolvedores satisfeitos e insatisfeitos nesse período. Mais importante ainda, essa melhoria se traduziu em uma organização de engenharia capaz de produzir software com mais eficiência e se adaptar, com mais rapidez, à medida que as capacidades de IA continuavam aumentando.

Vivek também explicou que a adoção, por si só, não é suficiente para gerar ganhos de produtividade. O alto impacto vem da profundidade de uso e do verdadeiro domínio das ferramentas ao ajustar a escala. Na Snowflake, essa jornada passou por três estágios:

• Adoção: tem início quando os desenvolvedores aprendem a usar ferramentas de IA em seu trabalho diário. 
• Domínio: desenvolve-se conforme os engenheiros descobrem fluxos de trabalho repetíveis que produzem resultados consistentemente melhores. 
• Otimização: ocorre quando esses fluxos de trabalho se tornam conhecimento organizacional do qual todo engenheiro pode se beneficiar.

Um exemplo é o conjunto de padrões de design de engenharia desenvolvido internamente na Snowflake. Os primeiros adotantes de IA experimentaram técnicas de prompting, métodos de planejamento e abordagens de depuração. Com o tempo, a organização documentou os padrões que consistentemente geravam melhores resultados e os disponibilizou para toda a engenharia. 

Todos os desenvolvedores tinham acesso às mesmas ferramentas de IA, mas, de modo consistente, os engenheiros que usavam fluxos de trabalho comprovados superavam aqueles que ficavam presos nos estágios iniciais de adoção de ferramentas. A vantagem competitiva veio da institucionalização de formas de trabalho bem-sucedidas, e não simplesmente da implementação de mais um assistente de IA.

Essa ênfase nos fluxos de trabalho também muda a forma como as organizações pensam sobre o processo de desenvolvimento de software. À medida que a IA reduz o esforço necessário para transformar ideias em software funcional, todos se tornam criadores de soluções. Gerentes de produto podem gerar protótipos de novas experiências, designers podem validar conceitos diretamente no código, e especialistas de domínio podem adicionar barreiras de proteção para outras personas. Em vez de debater ideias por meio de apresentações ou documentos, as equipes podem validá-las construindo software funcional. O código torna-se cada vez mais a forma mais rápida de testar hipóteses.

Jon McNeill, autor de The Algorithm, expandiu esse tema ao incentivar os líderes a reconsiderar hipóteses que moldaram as organizações de engenharia por décadas. Com muita frequência, as empresas começam pela tecnologia e depois buscam lugares para aplicá-la. Jon argumentou que as organizações bem-sucedidas invertem essa equação. Elas começam identificando poucos empecilhos de negócios que realmente importam e reestruturam seus sistemas de engenharia em torno da solução desses problemas. À medida que as organizações levam a IA para produção, o sucesso será medido menos por quem gera mais código ou consome mais tokens e mais por quem constrói o sistema de engenharia mais simples, mais rápido e mais eficaz. Talvez o ranking mais interessante não seja composto pelos engenheiros que geram mais código de IA ou consomem mais tokens, mas sim pelos engenheiros que eliminaram o maior número de etapas desnecessárias entre uma ideia e a produção.

À medida que a IA integra-se a todo o ciclo de vida de desenvolvimento de software, os líderes de engenharia enfrentam um segundo desafio. Toda melhoria na velocidade de desenvolvimento também aumenta a necessidade de sistemas confiáveis e disciplina operacional. As organizações que avançam mais rápido estão investindo em arquiteturas que tornam ambos possíveis.

Jeremy Burton, gerente-geral da unidade de negócios de Observabilidade da Snowflake, argumentou que a IA entrou em uma nova fase. A experimentação inicial está dando lugar à implementação em produção, e espera-se cada vez mais que as organizações demonstrem valor comercial mensurável, em vez de sucessos técnicos isolados. Ao mesmo tempo, a IA traz desafios operacionais totalmente novos. Os agentes de IA geram mais telemetria, interagem com mais sistemas e tomam decisões usando informações distribuídas em ambientes cada vez mais complexos. Isso muda o papel da observabilidade, que deixa de ser apenas o monitoramento de infraestrutura e passa a fornecer o contexto de que os sistemas de IA precisam para operar de forma confiável.

Jeremy questionou uma das hipóteses mais comuns na IA para empresas, que diz que modelos melhores simplesmente precisam de dados melhores. Na realidade, a IA é tão eficaz quanto o contexto que ela consegue acessar. Esse contexto vai muito além da telemetria bruta. Ele inclui a semântica que descreve o significado dos dados, os relacionamentos capturados por meio de ontologias e gráficos de conhecimento, além do contexto de negócio que conecta os sistemas. Igualmente importante é a forma como esse contexto é acessado. Os agentes de IA precisam de interfaces padronizadas, como APIs, CLIs e Model Context Protocol (MCP), para recuperar e agir com base em informações, de forma confiável, enquanto os engenheiros precisam de formas intuitivas de explorar os dados em detalhes e validar insights gerados por IA. 

Um contexto rico combinado com acesso aberto transforma a telemetria desconectada em um ambiente onde pessoas e IA podem pensar de forma eficaz, investigar problemas mais rapidamente e tomar melhores decisões. As organizações que continuam armazenando logs, métricas, rastreamentos, dados operacionais e contexto de negócio em sistemas desconectados dificultam que a IA raciocine com precisão sobre os ambientes de produção. Em vez disso, a telemetria de engenharia deve ser tratada como dados que existem em uma base comum, na qual os relacionamentos entre sistemas podem ser compreendidos e consultados.

Aditya Gaur, gerente de engenharia na Netflix, demonstrou como isso funciona na prática por meio do trabalho da empresa em análise automatizada de causa raiz. Embora o projeto seja frequentemente descrito como uma iniciativa de IA, Aditya explicou que o sucesso dele dependeu muito mais da arquitetura de dados do que da própria IA. 

Anos antes de integrar agentes de IA, a Netflix investiu em conectar telemetria fragmentada entre sistemas, modelar relacionamentos operacionais por meio de uma ontologia e um gráfico de conhecimento, e criar uma camada de contexto compartilhada. Quando a IA entrou em cena, a base já existia. Em vez de buscar em logs e dashboards desconectados, os agentes de IA conseguiam raciocinar sobre conhecimento operacional estruturado e gerar hipóteses muito mais significativas durante as investigações de incidentes.

Caitlin Colgrove, CTO da Hex, falou sobre velocidade a partir de uma perspectiva diferente. Ela pediu aos líderes que repensassem o que significa se mover rápido na era da IA. As organizações não podem se dar o luxo de serem parcialmente nativas em IA. Eventualmente, elas chegam a um ponto em que precisam se comprometer totalmente, reestruturando a forma como as equipes constroem produtos, tomam decisões e incorporam a IA ao trabalho diário. Ela descreveu isso como "burning the boats". A IA precisa se tornar fundamental para a forma como o negócio opera. 

Inicialmente, a Hex respondeu à chegada da IA generativa criando uma equipe de produtos dedicada à IA. Embora a estratégia tenha produzido recursos úteis, ela também criou um gargalo organizacional. No fim, a Hex dissolveu a organização centralizada de IA e distribuiu a responsabilidade entre todas as equipes de produto. Hoje, a Hex produz produtos, com rapidez, e incorpora recursos de IA em todos os produtos, porque a responsabilidade está com os engenheiros mais próximos dos problemas do cliente.

Chris Kozlowski, Managing Director no Barclays, trouxe uma perspectiva empresarial para a discussão e destacou que a velocidade só gera valor quando é acompanhada de governança e confiança. Em ambientes altamente regulados, as equipes de engenharia não podem se dar ao luxo de escolher entre inovação e controle.

Corey Burke, SVP de engenharia na Dialpad, e Arun Rajamanickam, VP de engenharia na project44, descreveram como a IA está mudando o ritmo do desenvolvimento de software. À medida que os agentes de IA se tornam capazes de implementar grandes partes de uma funcionalidade de forma independente, os engenheiros dedicam menos tempo escrevendo código e mais tempo definindo intenções, orquestrando vários agentes e validando resultados. 

Eles destacaram que maximizar a velocidade exige a criação de plataformas de engenharia que permitam às equipes experimentar rapidamente sem comprometer a confiabilidade. A IA reduz o caminho entre identificar um problema do cliente e validar uma solução, mas apenas se as equipes tiverem a infraestrutura, o contexto compartilhado e a disciplina operacional para iterar com confiança.

Se a IA muda a forma como o software é criado, ela inevitavelmente muda a forma como as organizações de engenharia são projetadas. Isso exige novas estruturas de equipe, novos modelos de liderança e uma compreensão diferente de onde os engenheiros geram mais valor.

Qi Jin, EVP na Cerebras Systems, sugeriu que as organizações otimizadas para gerações anteriores de desenvolvimento de software costumam ser a maior barreira para a adoção da IA. Processos estabelecidos e limites organizacionais foram criados para ajustar a escala de formas de trabalho comprovadas, não para se adaptar continuamente a tecnologias revolucionárias. Adotar a IA com sucesso, portanto, exige mais do que integrar novas ferramentas. Líderes precisam repensar os modelos operacionais para que as equipes possam incorporar rapidamente novas funções à medida que a tecnologia evolui. 

Qi descreveu essa transformação por meio do conceito de "Code Yellow", uma estrutura para promover a mudança organizacional com urgência e foco nos problemas dos clientes. Sua perspectiva reflete uma filosofia de liderança mais ampla sobre a qual ele já escreveu em seu ensaio que fala do "gestor em tempos de guerra", no qual defende que períodos de mudanças intensas e rápidas exigem líderes que simplifiquem as decisões, ajam com determinação e estejam dispostos a desafiar normas estabelecidas em vez de otimizar processos existentes.

Parvez Naqvi, Managing Vice President of Cloud Platforms, Resilience Engineering and Enterprise Architecture na Capital One, detalhou como essas mudanças organizacionais estão remodelando o papel dos próprios engenheiros. À medida que a IA torna a implementação muito mais rápida, o valor da engenharia se desloca para as decisões que a IA não consegue tomar de forma independente. As principais restrições à produção de software agora incluem planejamento, design arquitetônico e julgamento de engenharia. 

Os processos tradicionais de revisão, que evoluíram em torno de código escrito manualmente, começam a falhar à medida que a IA aumenta drasticamente a velocidade de desenvolvimento. Os engenheiros seniores geram cada vez mais impacto ao definir a direção técnica e estabelecer padrões arquitetônicos. Eles também estão cada vez mais envolvidos no design de sistemas e no fornecimento do contexto capaz de permitir que engenheiros e agentes de IA tomem melhores decisões.

Essa evolução também eleva a importância das plataformas para desenvolvedores e da infraestrutura de engenharia. Ferramentas internas e sistemas de implantação se tornam ativos estratégicos, pois reduzem a carga operacional e permitem que as equipes se concentrem em desenvolver sistemas resilientes em vez de gerenciar tarefas repetitivas. À medida que mais gerentes de produto, designers e especialistas de domínio contribuem diretamente para a criação de software, as organizações de engenharia se tornam cada vez mais responsáveis pela qualidade, arquitetura e excelência operacional, em vez de serem os únicos produtores de código.

Harjot Gill, CEO na CodeRabbit, compartilhou como a IA está transformando por completo a experiência do desenvolvedor. À medida que a IA assume mais parte do trabalho de implementação, os engenheiros dedicam menos tempo traduzindo ideias em código e mais tempo definindo intenções, avaliando trade-offs e moldando o design de sistemas. Revisões assistidas por IA podem ajudar as equipes de engenharia a manterem o ritmo sem comprometer a correção, a segurança ou a capacidade de manutenção.

Jordan Topoleski, COO na Cursor, concentrou-se no que acontece depois que o código é gerado. À medida que a IA aumenta drasticamente a velocidade de desenvolvimento, a revisão de código, a validação e a manutenção da qualidade de engenharia se tornam os novos gargalos. A perspectiva de Jordan reforçou a ideia de que as organizações que ajustam a escala com sucesso criam ciclos de feedback e sistemas de engenharia mais fortes, garantindo que o software gerado por IA esteja pronto para produção.

Vistas em conjunto, essas discussões apontam para uma transformação mais ampla. A engenharia nativa em IA é definida pela rapidez com que uma organização consegue aprender e institucionalizar formas melhores de produzir software. As empresas mais rápidas serão aquelas que repensarem continuamente suas organizações de engenharia para aproveitar cada novo avanço da IA.

As conversas ao longo do dia refletiram um mercado que já avançou muito além da experimentação. Embora cada organização esteja em um estágio diferente de sua jornada de transformação, os desafios são notavelmente consistentes. O feedback dos participantes reforçou nossa visão para o CTO Circle. Os líderes de engenharia destacaram consistentemente a oportunidade de participar de conversas francas com colegas que enfrentam decisões semelhantes. O que tornou o evento valioso foi a oportunidade de os líderes de engenharia terem conversas abertas, uma oportunidade que raramente conseguem ter em outros lugares.

A posição única da Snowflake em diversos setores possibilitou reunir organizações que enfrentam desafios semelhantes. Isso ajudou a criar um fórum de confiança para compartilhar lições práticas, em vez de histórias de sucesso encenadas.

O padrão da engenharia nativa em IA ainda está sendo escrito. À medida que os modelos continuam a melhorar e as práticas de engenharia evoluem junto com eles, esses aprendizados se tornarão ainda mais relevantes. Continuaremos compartilhando lições práticas de líderes de engenharia que estão construindo organizações nativas em IA, incluindo um olhar mais aprofundado sobre a própria transformação da Snowflake. Se essas conversas refletem os desafios que sua organização está enfrentando, convidamos você a conferir nosso podcast mais recente, enquanto continuamos explorando o que ainda mais é preciso para construir a próxima geração de organizações de engenharia.