Redesenhando a forma de construir software com agentes de IA — painel da Sonar e da McKinsey

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Redesigning How Software Gets Built With AI Agents — Sonar & McKinsey Panel · Canal: AI Engineer · 18:49 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA, Engenharia de software com IA

Resumo

O painel discute por que muitas empresas implementam IA, mas poucas conseguem escalar seu uso e obter impacto nos negócios. Os participantes destacam três fatores para avançar: redesenhar os workflows de ponta a ponta, escolher as ferramentas adequadas e adaptar as pessoas e o modelo operacional. Também abordam métricas de produtividade, equipes menores e generalistas, pensamento crítico e a importância de tornar explícitas as especificações e regras que costumam ficar implícitas. Por fim, descrevem como a confiança na precisão dos agentes pode crescer gradualmente até permitir automatizar etapas de revisão, correção e aprovação de PRs.

Pontos-chave

Embora muitas empresas afirmem ter implementado IA ou agentes, menos de um terço relata ter escalado essas iniciativas ou obtido impacto nos negócios.
A progressão para workflows mais automatizados exige repensar o processo de desenvolvimento de software de ponta a ponta, não apenas inserir ferramentas em etapas isoladas.
O modelo operacional e as funções das equipes também precisam mudar, pois as fronteiras tradicionais entre engenharia, produto e design estão se tornando menos definidas.
Equipes de plataforma podem apoiar a adoção em larga escala com padrões e métricas de produtividade, qualidade, velocidade de entrega e satisfação dos desenvolvedores.
Agentes podem assumir tarefas repetitivas e liberar tempo dos desenvolvedores, ajudando-os a permanecer concentrados no trabalho.
À medida que mais decisões são delegadas a agentes, especificações, regras e critérios de sucesso precisam ser expressos com clareza.
Pensamento crítico é essencial para questionar resultados de IA que parecem convincentes, mas podem estar incorretos.
A confiança na automação se constrói por etapas: começar com revisões, bloquear problemas identificados, testar correções automáticas e, por fim, permitir aprovações e merges em casos definidos.

Capítulos

Início	Capítulo	Resumo
00:01	A adoção de IA e os níveis de maturidade	O moderador apresenta a diferença entre implementar IA em pilotos e escalar seu uso com impacto, além de introduzir os estágios Horizon 2 e Horizon 3.
03:12	Lições da Sonar para adotar agentes	Tariq fala sobre objetivos mensuráveis, workflows deliberados, confiança nos agentes e equipes pioneiras que ajudam a demonstrar boas práticas.
06:30	Como levar práticas de equipes pequenas a empresas grandes	Ali explica como métricas, automação de workflows completos e atenção ao tempo dos desenvolvedores podem orientar a adoção em organizações maiores.
10:48	Habilidades e organização na era dos agentes	Os painelistas discutem orquestração, especificações explícitas, pensamento crítico e a importância de equipes menores e de profissionais generalistas.
14:59	Construindo confiança para automatizar PRs	Ali descreve uma progressão de revisões assistidas a correções, bloqueios, aprovações e merges automatizados, guiada pela precisão dos agentes.

Citações

O objetivo nunca foi maximizar tokens. A ideia é gerar valor real. — 04:19

Não acho que haverá um mundo em que possamos ficar completamente alheios ao processo. — 11:49

A IA sempre apresenta resultados plausíveis com muita convicção. — 12:51

É a precisão que gera confiança e permite desbloquear níveis cada vez maiores de automação. — 15:31

Conceitos e entidades

Sonar (empresa): Empresa mencionada como participante do trabalho sobre adoção de IA e agentes no desenvolvimento de software.
McKinsey (empresa): Empresa que colaborou na análise de práticas para escalar o uso de IA no desenvolvimento de software.
Tariq (pessoa): CEO da Sonar, participante do painel que descreve a experiência de adoção de IA na empresa.
Ali (pessoa): Participante do painel que compartilha experiências em startups e em organizações de plataforma de engenharia.
Prakhar (pessoa): Moderador do painel, responsável por contextualizar a discussão e fazer perguntas aos participantes.
Gitar (empresa): Empresa descrita por Ali como uma startup que desenvolvia uma solução com agentes para validar PRs e que passou a fazer parte da Sonar.
Uber (empresa): Empresa onde Ali liderou a organização de plataforma para desenvolvedores.
Horizon 2 (conceito): Estágio de maturidade em que agentes executam tarefas ao longo do ciclo de vida de desenvolvimento de software com orientação e validação humanas.
Horizon 3 (conceito): Estágio de maturidade caracterizado por workflows automatizados de ponta a ponta, com supervisão humana.
SDLC (conceito): Ciclo de vida de desenvolvimento de software, cujos processos e workflows são discutidos como alvos de redesenho e automação.
PDLC (conceito): Ciclo de vida de desenvolvimento de produto, mencionado em relação à integração de IA e agentes nos workflows.

Tradução completa (pt-BR)

00:01 [música] >> Vamos começar. Apresentarei meus colegas de painel daqui a pouco, mas, antes, quero contextualizar o assunto sobre o qual vamos conversar. Nos últimos seis meses ou um ano, praticamente todas as empresas têm tentado implementar IA ou agents em seus workflows. Fizemos uma pesquisa sobre isso, e tenho certeza de que o mesmo acontece em muitas organizações ao redor do mundo: elas

00:31 viram isso. Basicamente, de 80% a 90% das empresas que você consulta dizem que implementaram IA ou agents de alguma forma. Mas, quando você pergunta quantas realmente conseguiram ampliar a implementação ou estão percebendo um impacto nos negócios, o número é inferior a um terço. Certo? E há muitos motivos para isso. Vimos muitas empresas fazendo isso em POCs e ambientes pequenos, mas não de ponta a ponta em toda a organização. Então, o que está acontecendo? Qual é o motivo para isso não acontecer? Trabalhamos com a Sonar e o Tariq para descobrir quais

01:03 são os principais fatores que realmente ajudam as organizações a ampliar o uso da IA quando ela é implementada no ciclo de vida do desenvolvimento de software. E vimos resultados muito bons. Nada surpreendente, certo? Quem faz isso em grande escala está tendo resultados muito bons em termos de volume de PRs, tempo de ciclo dos PRs e ganhos de produtividade autorrelatados em tarefas do SDLC. E colocamos essas organizações em uma escala de maturidade. Então, se pensarmos em onde as empresas estão hoje, a maioria delas está no que chamamos de Horizonte 2, em que há

01:35 agents guiados e validados por humanos executando tarefas ao longo do SDLC. Mas pouquíssimas empresas estão no Horizonte 3, à direita, em que o workflow é totalmente automatizado de ponta a ponta, certo? Com supervisão humana. E o que descobrimos ao fazer esse trabalho com eles foi que há três fatores que realmente ajudam nisso, sem surpresa. O primeiro é redesenhar o workflow dos processos: em vez de pensar em um SDLC tradicional, pensar em redesenhar todo o workflow, de ponta a ponta. Pensar em como os agents estão mudando essas

02:06 coisas. O segundo é o ferramental, obviamente: se você tem bons agents, bons harness, boas camadas de contexto etc. Mas o aspecto mais importante, que muitas vezes é ignorado, são as pessoas. Certo? Ao realizar esse trabalho, reconhecemos isso em muitos, muitos, muitos projetos-piloto e iniciativas de expansão: os limites das funções definidas tradicionalmente — o que era um engenheiro de software, um gerente de produto, um designer — começaram a se confundir. E as organizações que reconheceram que esses limites estão mudando e realmente remodelaram

02:38 todo o seu modelo operacional em torno disso são as que estão vendo a terra prometida de um aumento de produtividade de 10x com IA e agents. E, enquanto fazíamos esse trabalho com ele, vamos falar um pouco mais sobre isso. Vimos que as pessoas céticas em relação a isso, que diziam: “É, os agents vão executar as tarefas, mas não precisamos mudar mais nada”, aos poucos passaram a acreditar: “Certo, faz sentido. Precisamos repensar e reformular a organização das nossas empresas.” Dito isso, convido ao palco nosso painelista Tariq, CEO da Sonar, e Ali, CEO da Gitai. Faremos uma sessão de perguntas e respostas. Vamos deixar

03:12 um tempo no final para perguntas, se possível, então vocês também podem perguntar. Mas, por favor… Ótimo. Para começar, Tariq, vou fazer esta pergunta primeiro a você. Para as empresas que estão passando por essa transição e avançando para o Horizonte 2 e além, que orientações ou aprendizados você pode compartilhar sobre o que devem observar ao avançar para um pipeline agentic orquestrado, de ponta a ponta e em grande escala? >> Oi, pessoal. Obrigado, Prakhar, por nos receber aqui hoje também. Imagino que todos consigam me ouvir.

03:44 Dá para ouvir bem? Sim, certo. Precisa mais alto? Um pouco mais alto? Tudo bem, perfeito. Então, como disse Prakhar, estamos passando por essa jornada de como usar IA de forma responsável na organização. Como realmente transformar uma organização? Para quem não nos conhece, começamos como um projeto open source há 18 anos. Embora tenhamos muito orgulho de tudo o que estamos fazendo no mundo da IA, nossa equipe de engenharia precisou passar por uma certa transformação para se acostumar com as novas ferramentas e descobrir como adotá-las de forma nativa. E uma

04:19 parte disso foi deixar muito claro qual era o objetivo. O objetivo nunca foi maximizar tokens nem nada do tipo. Não gostamos muito desse tipo de ideia. A questão é: como gerar valor real? Por isso, foi muito importante deixar bem claro o que estávamos medindo. Acho que o segundo ponto é sermos muito intencionais quanto ao processo que estamos implementando, certo? E, se vocês ouviram a palestra que acabei de dar, orquestramos tudo em torno de como implementar o modelo orientar, verificar e resolver dentro da nossa empresa, assim como

04:55 recomendamos que seja feito em qualquer outra empresa. Por isso, é muito importante pensar em como criar o ferramental. Também é fundamental pensar em como criar os sistemas de que estamos falando. Fazer a equipe confiar nos agents, certo? Trabalhando com a equipe da McKinsey, analisamos o que estamos fazendo, e nossa equipe havia criado vários agents. Mas coisas como agents de PRD e como capturar o conteúdo do PRD para usá-lo na geração das

05:26 evals que usamos para gerar a verificação da saída da IA não eram naturais para a equipe. Parte do que precisávamos fazer era criar equipes de referência para destacar as melhores práticas de como fazer isso. Francamente, o que mais me surpreendeu foi que achei que, assim que tivéssemos essas equipes de referência trabalhando dessa forma, as outras equipes conseguiriam acompanhá-las muito rapidamente. >> Sim.

05:57 >> Quase só por observarem o exemplo. Mas descobrimos que não é bem assim. Esse exemplo ajuda a avançar parte do caminho, e você pode implementar o ferramental e fazer tudo isso, mas o próximo passo — fazer com que elas realmente pensem de outra forma e entendam por que estão usando esses agents, etc. — é um dos elos fundamentais que faltam. >> Desde a última vez. Ali, talvez uma pergunta para você. Vimos que equipes menores têm muito mais chances de ampliar o uso de agents porque têm menos dependências e menos desafios a superar. O que

06:30 as organizações de maior porte podem aprender com essas equipes? >> Sim. Antes de tudo, é ótimo estar aqui. Sou Ali. Antes, eu era CEO da Gitarr, e agora fazemos parte da Sonar. Antes de entrar na Sonar, eu era CEO da Gitarr. Na Gitarr, éramos uma startup pequena. >> Sim. >> Éramos só umas cinco ou seis pessoas. >> Sim. >> E estávamos criando uma solução agentic para validar PRs. Todo o workflow de validação de PRs. Antes disso, trabalhei na Uber, onde era responsável por toda a organização da plataforma para desenvolvedores. Criei uma organização responsável por garantir que todos os desenvolvedores fossem produtivos e estivessem satisfeitos, e que a empresa avançasse em ritmo acelerado, com alta qualidade.

07:00 Então, tive experiência tanto em uma grande empresa, liderando organizações de desenvolvimento em uma grande empresa, quanto no mundo das startups. Quando começamos a Gitarr,

07:32 na verdade, não éramos uma empresa com a IA como prioridade, mas rapidamente fizemos a transição para nos tornarmos uma empresa com a IA como prioridade. Depois dessa transição, tanto na adoção interna da IA quanto na criação de produtos de IA, vimos uma aceleração na demanda, mas também conseguimos realizar muito mais com uma equipe bem menor. Então, conheço os dois lados. E acho que, ao pensar em como levar os aprendizados de uma empresa pequena e ampliá-los para uma grande empresa, é importante lembrar que, na verdade, as grandes empresas têm uma vantagem estrutural porque, normalmente,

08:06 À medida que sua organização de engenharia cresce e chega a um tamanho grande o suficiente, você tem uma equipe de plataforma, que era exatamente minha responsabilidade quando eu estava na Uber. E, sabe, as funções que tive no passado, no Google e no Facebook, eram todas em organizações de plataforma. Então, já existe uma organização responsável por estabelecer padrões e garantir que os desenvolvedores sejam produtivos e felizes. E acho que há alguns princípios importantes que uma equipe de plataforma deve seguir ao avaliar como adotar essas ferramentas.

08:37 Um deles é ter métricas muito boas. Acho que você mencionou isso, mas nem sempre é algo óbvio para grandes organizações, porque é muito difícil estabelecer padrões suficientes em toda a organização para, então, ter telemetria que permita entender: com que rapidez consigo colocar código em produção? Qual é a produtividade dos engenheiros em termos de volume de trabalho? Como está a qualidade? Com que frequência erro e volto ao início do meu workflow?

09:11 E qual é a percepção dos engenheiros? À medida que aceleramos as coisas e aumentamos a produtividade, os engenheiros estão realmente percebendo isso? Então, acho muito, muito importante ter uma base de métricas de produtividade dos desenvolvedores para que, ao adicionar IA e agents à sua cadeia de ferramentas e ao seu PDLC, você consiga medir, iterar, melhorar rapidamente e fazer ajustes. Então, esse é o primeiro ponto. O segundo, que você também mencionou, é muito importante: olhar para o ciclo de vida inteiro, e não apenas para a introdução de ferramentas em uma

09:45 parte específica do ciclo de vida. Então, pense no ciclo de vida inteiro e em workflows completos. Como automatizar workflows inteiros e tornar os desenvolvedores mais eficientes, transferindo cargas de trabalho completas para agents que possam agir de forma autônoma e entregar os resultados desses workflows? E acho que a terceira coisa, pela minha experiência em uma equipe de plataforma e por já ter liderado equipes de plataforma no passado, é garantir que você esteja realmente prestando atenção ao tempo dos desenvolvedores.

10:18 E otimizar para manter os desenvolvedores no fluxo. >> Sim. >> E automatizar o máximo possível do trabalho braçal. >> Fazer trabalho braçal. >> Não, mas agents são perfeitos para isso, certo? Então, se você realmente conseguir implantar agents para assumir workflows inteiros de trabalho braçal, tirando isso das mãos das pessoas, é aí que, acho, você obtém grandes ganhos não só de produtividade e velocidade, mas os desenvolvedores também percebem isso e a percepção deles melhora, o que é

10:48 igualmente importante, se não a coisa mais importante, eu diria. Então, é assim que eu abordaria o problema. >> Sim, faz sentido. Acho que talvez uma pergunta para você. À medida que os agents se integram mais aos workflows e os LLMs ficam melhores no que fazem, presumimos que chegará um momento em que teremos um SDLC ou PDLC totalmente automatizado e orquestrado de ponta a ponta. Que implicações isso terá para as pessoas, para as organizações e para o modelo operacional do futuro de qualquer organização de software?

11:19 >> Sim, acho que os modelos estão claramente melhorando. Recomendo que a Anthropic falou sobre os modelos Fable e, sabe, estou ansioso para poder usá-los, certo? Acho que dá para imaginar um mundo em que essa ideia de fábrica de software realmente começa a se concretizar. Acho que você usou uma palavra-chave, na minha opinião: orquestrado, certo? Porque não acho que haverá um mundo em que você possa ficar

11:49 completamente sem se envolver. Acho que a questão é quanto você deixa a cargo da máquina, quanto deixa a cargo do agent e quanto você controla desde o início. Então, a especificação, o que é importante para você e como é o sucesso são elementos muito importantes. Acho que é preciso continuar tendo pessoas envolvidas nisso. Em termos de conjunto de habilidades, fala-se muito sobre como os desenvolvedores de software precisam se tornar arquitetos, orquestradores e gestores de agents, coisas assim. E acho que há muita verdade nisso. Uma

12:20 coisa que considero uma habilidade extremamente importante é que guardamos muita coisa na cabeça. Se você pensar em como projeta e desenvolve software hoje, há certas coisas no seu PRD e há várias coisas que você simplesmente sabe, certo? Minha empresa gosta de fazer as coisas desse jeito, gosta desse tipo de código, gosta desta dependência, gosta de seja lá o que for. E muito mais coisas precisarão ser explicitadas, em vez de ficarem implícitas, certo? E, na verdade, isso exige um conjunto de habilidades. Então, acho que, além de ser arquiteto e tudo

12:51 mais, você precisa começar a pensar de uma forma muito mais explícita. Esse é o primeiro ponto. Acho que o segundo ponto: meu filho mais velho está prestes a entrar na faculdade e está tentando decidir o que estudar e tudo mais. E o conselho que sempre dou a ele é que o mais importante é ser excepcional em pensamento crítico, certo? Porque, como li no Twitter — e estou roubando a ideia descaradamente —, a IA sempre dá respostas plausíveis e com muita convicção, certo? Ela sempre parece correta e nunca admite qualquer

13:25 dúvida. Nunca diz: “Acho que a resposta é esta”. Ela sempre diz: “A resposta é esta”. E acho que o papel das pessoas no sistema será dizer: “Em que pontos preciso questionar isso? Onde preciso, bem, investigar? Quais são as coisas…”, mais ou menos como você faz com sua equipe, certo? Se alguém entrar na sua equipe, se um estagiário entrar na sua equipe, você vai saber onde investigar. Vai saber onde olhar, que perguntas fazer, o que procurar. Acho que essa habilidade também é superimportante. Quanto ao último ponto da pergunta, que você e Ali estavam discutindo,

13:56 sabe, vejo muita resistência nas organizações com que trabalhamos a essa ideia de equipes menores, certo? E a essa ideia de trabalhar em uma unidade atômica menor. Acho que, quando você vai ao fundo da questão, a objeção quase sempre é: “Mas eu sou uma pessoa de frontend, não de backend, ou sou isso, sabe, eu sou…” E, historicamente, chegamos a um mundo em que segregamos bastante as funções. Nós

14:28 criamos silos entre as pessoas. E acho que esta é a era do generalista, certo? Não estou dizendo que alguém que não sabe nada sobre software seja um generalista, mas acho que um engenheiro de software generalista será muito mais importante do que saber se você é especialista em frontend, no lado do servidor ou seja lá no que for. >> Sim. >> Dando sequência a isso, Ali, sei que você já falou sobre o assunto em outros fóruns também. Grande parte da etapa de programação do SDLC está, entre aspas, resolvida. Por isso, o foco está mudando, com razão,

14:59 agora para outras partes: geração de requisitos, validação, testes etc. Você acha que já chegamos a um ponto, ou que chegaremos nos próximos 3 ou 6 meses, em que a confiança nos agents para automatizar tudo isso vai aumentar? Porque, neste momento, acho que todos estão céticos quanto à possibilidade de automatizar a validação, os testes, os testes de integração etc. Como você vê isso? Essa mudança já aconteceu ou está em curso? >> Acho que confiança é a palavra-chave aqui. E acho que a confiança virá com o tempo.

15:31 E então, sabe, o que estamos vendo é que, com o tempo, à medida que nossos usuários trabalham com as ferramentas e percebem a precisão da IA, é essa precisão que gera confiança e permite que eles liberem cada vez mais níveis de automação. >> Sim. >> A ponto de as mudanças poderem passar completamente de forma autônoma pelo seu repositório de código até chegar à produção. >> Sim. >> Por exemplo, com nossos usuários no Guitar e a automação que temos

16:02 no Guitar, o padrão típico que vemos é que, no início, eles só usam as revisões. E analisam a análise de falhas de CI que produzimos. >> Sim. >> E, com o tempo, quando percebem: “Tudo bem, na verdade, são bugs reais e muito precisos no código que estão sendo encontrados”, dizem: “Tudo bem, vou dar mais poder de ação ao agent. Agora vou configurar algumas regras para bloquear o processo se o agent encontrar algum problema.” Então, agora você deu mais um passo na automação. Você não só tem

16:35 revisões em que confia; agora, na verdade, confia nelas o suficiente porque o sinal é suficientemente alto para bloquear. Depois, normalmente, o que acontece é que começam a experimentar os recursos de correção automática. Tudo bem, deixe-me pedir ao agent para corrigir alguns desses problemas. >> Criar um PR para ver como >> Sim, corrigir as falhas de CI, corrigir todos os problemas que você está encontrando. E, quando você vê a precisão dessas correções e percebe que, na verdade, elas também funcionam — produzem correções que não introduzem novos problemas e passam na compilação —, o agent pode iterar até a compilação passar e ficar

17:09 verde. Então, eles liberam a correção automática. Agora deram mais um passo: “Ei, quando um PR é criado, ocorre uma revisão. Se houver problemas críticos, ele é bloqueado. Depois, o sistema começa a iterar e deixa tudo verde, corrige todas as falhas de CI e todos os problemas relevantes apontados nas revisões. E agora você entregou PRs verdes, prontos para alguém aprovar.” E é aí que começa a acontecer uma grande mudança: há partes do repositório de código e certos tipos de PRs que me sinto confortável em deixar o sistema aprovar.

17:44 Certo? E agora estamos começando a ver usuários criarem regras como: “Sabe de uma coisa? Se você mexer nesta parte do repositório de código, ela não é crítica. Ou, se o PR fizer esse tipo de alteração, pode aprová-lo automaticamente.” Então, você foi da criação do PR até a aprovação. Agora só falta alguém entrar e fazer o merge. E esse também é o próximo passo que estamos vendo acontecer: pode fazer o merge e corrigir qualquer conflito de merge. E agora você tem a criação de PRs totalmente autônoma, de ponta a ponta, até o merge, tudo automatizado. Mas isso não acontece de imediato.

18:17 Certo? Isso acontece conforme você usa o sistema e constrói confiança de que o agent com quem está trabalhando é realmente preciso. Há contexto suficiente sendo fornecido. Sabe, configurei regras e proteções suficientes para me sentir confortável em deixar o sistema atuar de forma totalmente autônoma. Certo? Então, acho que, para responder à sua pergunta, estamos chegando rapidamente a esse ponto. Acho que, no próximo ano, veremos cada vez mais equipes avançando nessa jornada. E algumas dessas equipes que estou vendo estão, na verdade, em grandes empresas. O que é bem interessante. >> Acho que nosso tempo acabou. Muito obrigado por estar aqui e responder às perguntas. Obrigado a todos. >> [aplausos]

18:49 [aplausos]

Transcrição original

[00:01] [music] >> Um we’ll get started. I’ll introduce my fellow panelists in a second, but just to set the context of what we are going to talk about. Um you know, in the last 6 months or a year or so, almost every company has been trying to deploy AI or agents in their workflow. Um we did some research on this, and I’m sure it’s the same for a lot of organizations around the world that they

[00:31] have seen this. Basically, 80-90% of the companies that you ask, they say we have deployed AI or agents in some shape or format. But when you ask them how many of them have actually scaled, or how many of them are seeing business impact from it, it’s less than a third. Um right, and there are a lot of reasons behind that. We have seen a lot of companies doing it in POCs and small environments, but not actually across end-to-end um organizations. So, what gives, right? Like, what was the reason why that doesn’t happen? Um we worked with Sonar um Tariq to figure out what

[01:03] are the key factors that actually helps organizations scale if you’re deploying AI in your software development life cycle. Um and we saw some really good results. Not surprising, right? Like, anybody who’s doing this at scale is actually seeing pretty good results in terms of PR throughput, PR cycle time, um self-reported productivity gains in tasks in the SDLC. Um and we put these organizations on a scale of maturity, essentially. So, if you think about where companies are today, most of them are in what we call Horizon 2, where you have

[01:35] human-guided and validated agents that are executing tasks across SDLC. But very few companies are on the Horizon 3 on the right-hand side, where it’s fully end-to-end automated workflow, right? With human oversight. Um and the things that we found when we were doing this work with them was there are three factors that actually help this, not surprisingly. One is redesigning your process workflow, which is you are not thinking about a traditional SDLC, you are thinking about redesigning the entire workflow end-to-end. You are thinking about how agents are changing that

[02:06] stuff. Second is tooling, obviously. Whether you have good agents, whether you have good harnesses, whether you have good context layers, etc. But the more critical thing that people have often overlooked is the people part. Right? So, when we were doing this work, we have recognized this across many, many, many pilots or scaling that we’ve done is that boundaries of how you traditionally define your roles, what a software engineer was, what a product manager was, what a designer was, they have started to blur. And organizations that have recognized that those boundaries are changing and have actually remodeled

[02:38] their entire operating model around that are the ones that are seeing the promised land of 10x productivity from AI and agents. And And as we were doing this work with him, we’ll talk about it a little bit more. We saw that, you know, people who were skeptical about this, like, “Hey, agents will do the task, but we don’t need to touch anything else.” They gradually then were converts into, “Okay, this makes sense. We need to rethink and reshape how our orgs are going to be organized.” So, with that, I will invite our panelist, Tariq, CEO of Sonar, and Ali, CEO of Gitai, to the stage. We’ll have a Q&A. We’ll leave

[03:12] some time at the end for questions if we can, so you guys should also ask, but please Awesome. Um I think to start with Tariq, I’ll probably ask this question to you first, you know, for companies that are going through this transition, going to Horizon 2 and beyond, um what are some guidelines or learnings that you have that you can share with them on what things they should watch out for as they’re transitioning toward a full-scale, end-to-end, orchestrated, agentic pipeline? >> Hi, everyone. Um thank you, Prakhar, for having us here today as well. You can all hear me, I

[03:44] assume. You can hear okay? Yeah, okay. You need it higher? Okay. Little bit higher? All right, perfect. Um So, you know, we we as Prakhar said been going through this journey of how do you use AI responsibly in the organization? How do you actually uh transform an organization? If you don’t know us, we started off as an open-source project 18 years ago. Uh so, while we’re very proud of everything we’re doing in the AI world, it has been a bit of a transformation for our engineering team to get used to the new tools, to really figure out how to adopt it in a native way. And um a

[04:19] part of this has really been about being super clear about what the objective is. And the objective was never for us token maxing or anything like this. We don’t really like that uh type of idea. The idea is how do you really generate real value. Um and so, see being super clear about what you’re measuring was really important for us. I think the second piece is um being very deliberate about what the process is that we’re putting in place, right? And if you heard my talk I just gave a little bit ago, we’ve orchestrated everything around how do you actually do this guide verify solve model inside of our company as just like

[04:55] we recommend doing it inside of everyone else’s company. And so, this notion of how do you construct the tooling is really important. How do you construct the systems that we’re talking about is really quite critical uh as well. Um getting the team to trust the agents, right? As working with the McKinsey team, we actually looked at what we’re doing and our team had built a bunch of agents themselves. But, there are things like PRD agents and how do we really capture what’s in the PRD and use that to generate the

[05:26] e-vals that we’re using to generate the the the um uh I output verification, these things um were not natural to the team. And part of what we needed to do was set up these lighthouse teams to really try and highlight the best practice ways of doing this. Frankly, the part that has been most surprising to me is that I thought that once you have these lighthouse teams who were operating in this way, the other teams would be able to follow super quickly. >> Yeah.

[05:57] >> Almost through the role modeling. And what we found is that’s not actually the case. That that role modeling gives you part of the way there, and you can set up the tooling, and you can do all of this stuff, but the next piece of of actually getting them to think differently, to understand why they’re using these agents, etc., is one of the critical missing links here. >> Since the last time. Ali, maybe a question for you. We have seen that smaller teams actually have a much better chance of scaling agents because there are less dependencies, less um challenges to overcome. What can

[06:30] organizations that are at much larger scale learn from those um teams, right? >> Yes, so first of all, uh it’s great to be here. Uh I’m Ali. I was previously the CEO of Gitarr, and now we’re actually part of Sonar. Um and uh before joining Sonar, I was the CEO of Gitarr. In Gitarr, we were a small startup. >> Yeah. >> Um only about five, six people. >> Yeah. >> And uh we were building an agentic solution for validating PRs. Uh so, the entire

[07:00] workflow for PR validation. And then before that, I was at Uber, where I was responsible for the entire developer platform organization. So, it’s an organization I built responsible for you know, making sure that all developers are productive and happy, and that the company is moving at a very fast pace in terms of velocity with high quality. So, I’ve kind of seen both um large company and running developer organizations in a large company, and then operating in a startup world. And uh when we started Gitarr, uh we

[07:32] actually weren’t AI-first, and then we quickly transitioned to become AI-first. And once we made that transition in terms of adopting AI internally, as well as building AI products, we saw both an acceleration in demand, but also we were able to get a tremendous amount done with a much fewer, smaller sized team. So, I’ve kind of seen both sides of things. And I think as you think about how do you take the learnings from a small company and scale it up into a large company, actually large companies have a structural advantage because typically

[08:06] as you scale your engineering org and you get to a large enough size, you have a platform team, which was exactly my responsibility when I was at at Uber and you know, the roles I had in the past like at Google and Facebook were all about platform organizations. So, there’s already an organization there that’s responsible for driving standards and making sure that developers are productive and and happy. And I think there’s a couple of principles that are important to follow as a platform team when you’re looking at how do we

[08:37] adopt these tools? One is to have really good metrics in place. I think you you mentioned it, but this is not always an obvious thing for large organizations because it’s actually very hard to drive enough standards across the organization so that then you have telemetry that you can actually get to understand how fast am I able to ship code into production? What is the productivity of engineers in terms of throughput? What does the quality look like? How often am I erring and going back to the beginning of my workflow?

[09:11] And what’s the sentiment of engineers? As we are speeding things up, making things more productive, are engineers actually feeling it? So, I think it’s very, very important to have that kind of developer productivity and metrics in place as a baseline so that as you add AI and agents into your tool chain and into your PDLC, you can actually measure and and iterate and quickly improve and adjust. So, I I that’s number one. Number two, I think again you mentioned is very important also to look at it in terms of the entire life cycle and not in terms of introducing tools into one

[09:45] specific part of the life cycle. So, think in terms of the entire life cycle and in terms of entire workflows. So, how can you automate entire workflows and take make developers more efficient by offloading entire workloads to agents that can autonomously act and deliver outcomes that are the outcomes of those workflows. And I think the third thing um I you know, in my experience as part of a platform having run platform teams in the past is to make sure you’re actually paying attention to developers’ time.

[10:18] And optimizing for keeping developers in the flow >> Yeah. >> and automating away as much grunt work as possible. Um and >> to do grunt work. >> No, but agents are perfect for that, right? So, if you can really deploy agents to taking entire workflows that are grunt work off the plate of uh folks, then that’s where you get I think big not only productivity gains and velocity increases, but also developers feel it and you get the high sentiment, which is

[10:48] equally important if not the most important thing I would say. So, that’s how I would kind of approach the problem. >> Yeah, makes sense. Um I think maybe a question for you. So, as agents get more embedded into the workflows, the LLMs get better at their job. We assume that there will be a point when you have a fully automated end-to-end orchestrated SDLC or PDLC. What implications does that have on people, on org, on operating model of the future for any software organization?

[11:19] >> Yeah, I think um there’s there’s a you know, the models are clearly getting better. Uh I recommend Tropic talked about the fable models and you know, I’m looking forward to getting my hands on it to start start using it, right? Um I I think you can you can see a world in which this this software factory idea really starts to come to life. Um I think you used the keyword, in my opinion, which is orchestrated, right? Um because I don’t think that there’s going to be a world in which you can be

[11:49] completely hands-off. I think the question is how much do you leave to the machine, how much you leave to the agent, and how much do you um how much do you control on the outset. So, what is the specification, what is important to you, what does success look like are all really important elements. You have to, I think, continue to have people who are involved with this. So, from a skill set standpoint, there’s a lot of talk about how software developers need to become architects and and orchestrators and managers of agents, things like that. And I think there’s a lot of truth to this. One

[12:20] thing that I think is an incredibly important skill set is there’s a lot that we keep in our head. If you think about how you design software, how you build software today, there’s certain things that are in your PRD, and there’s a bunch of things that you just know, right? My company likes to do things this way, my company likes this sort of code, we like this dependency, we like the whatever it is. And there’s going to be a lot more that needs to be made explicit as opposed to implicit, right? And that’s actually there’s a skill set associated with this. So, I think in addition to being an architect and all

[12:51] of that, you have to start thinking in a much more explicit way. This is thing number one. I think thing number two, you know, my kid my my oldest son is about to go to college and he’s like trying to figure out what to study and all of this. And the piece of advice that I keep giving him is the most important piece is to be critical amazing at critical thinking, right? Because the the point that I read on Twitter and I’m I’m shamelessly stealing it is that AI always gives you very high conviction plausible output, right? Um it always sounds correct, it never admits to any

[13:25] doubt whatsoever, it never says I think the answer is this.” It always just says, “The answer is this.” And I think the job of the people in the system is going to be to say, “Where do I need to question it? Where do I need to um well, where do I need to poke? What are the things” kind of the same way that you do this with your team, right? If you have somebody joining your team, you have an intern joining your team, you’re going to kind of know where to poke. You’re going to know where to look. What questions to ask, what to look for. I think that skill set is also super important. Last point to the question you and Ali were

[13:56] talking about, you know, um there’s a lot of resistance that I see in the organizations we work with to this idea of smaller teams, right? Um and this idea of of working in a smaller atomic unit. I think the the the the pushback when you get underneath it, in my experience, is almost always, “But I’m a front-end person and I’m not a back-end person or I’m a this you know what I I’m and we have historically gotten to a world where we segregate roles quite a bit. We

[14:28] silo people. And I think this is the era of the generalist, right? And I’m not saying that somebody who knows nothing about software generalist, but like your software engineering generalist is, I think, going to be a much more important uh thing than do you know, you know, are you super deep in front-end or server-side or whatever it happens to be. >> Yeah. >> Um I think following up on that, Ali, I know you’ve talked about this at other forums as well. A lot of the coding part of the SDLC is, quote unquote, solved. And so, focus, rightfully, is shifting

[14:59] now towards other parts, um the requirement generation, the validation, the testing, etc. Do you think we are at a point or we will get to a point in the next 3 months, 6 months where the trust in the agents to automate all of this will go high? Because right now, I think everyone is skeptical of whether you can automate your validation, your testing, your integration testing, etc. How do you see that? Has it shifted already or is it on a curve to shift? >> I think uh trust is the the keyword here. And uh trust I think is going to come time.

[15:31] And so uh you know, what we’re seeing is our users uh over time as they work with the tools uh and they see the precision of the AI, it’s that precision that gives them the trust that then uh allows them to unlock more and more levels of automation. >> Yeah. >> Uh to the point where, you know, changes can completely autonomously kind of flow through into your code base into production. >> Yeah. >> Um for example, um in with our users in Guitar and the automation that we have

[16:02] in Guitar, the typical pattern we see is at first they just use reviews. And look at the CI failure analysis that we produce. >> Yeah. >> Uh and over time when they see, “Okay, actually these are very precise actual bugs in the code that are being uncovered.” They say, “Okay, uh I’m actually not going to give the agent some teeth. I’m going to now set up some rules to block if there are any issues that are uncovered by the agent.” So, now you’ve kind of moved one step in the automation to Not only do you have

[16:35] reviews that you trust, now you’re actually trust them enough that they’re high the signal enough that you’re blocking. Then typically what happens is they start playing around with automated fix uh features. Okay, let me let me ask the agent to go ahead and fix some of these issues. >> Create a PR to see how >> Yeah, fix the CI failures, fix all the issues that you’re uh uncovering. And then when you see the precision of that, that okay, actually the fixes are working as well. Uh it’s producing fixes that don’t introduce new problems, they pass build, um and they can iterate to actually pass the build until it’s

[17:09] green, then they unlock auto fix. So, now they’ve taken one more step towards, “Hey, I’m going to When a PR is created, a review happens. If there are critical issues, it gets blocked. Then the system start iterating and makes everything green, fixes all the CI failures, all the um you know, good review issues. And now you’ve delivered green PRs that are ready for somebody to approve. And then here’s where the big shift is beginning to happen now, which is you know, uh there are some parts of the code base and some kind of PRs that I’m comfortable having the system approve.

[17:44] Right? And so now we’re beginning to see users put in rules to say, “You know what? If you’re touching this part of the code base, it’s not critical. Or if the PR is making this type of change, go ahead and automatically approve it.” So now you’ve gone from PR creation all the way through approval. And now only thing that’s left is somebody to come in and and merge. And that’s the next step as well that we’re seeing happen, too, which is go ahead and merge, fix any kind of merge conflicts. And now what you’ve got is fully autonomous end-to-end PR creation through merge is fully auto- automated. But it doesn’t come immediately.

[18:17] Right? It comes with using the system, building trust that the agent that you’re working with is actually uh precise. Um there’s enough context that’s flowing in. You know, I’ve set up enough rules and guardrails that I’m now comfortable with the system being fully autonomous. Right? So I think to answer your question, we’re rapidly approaching that. It’s I think within the next year uh we’ll see more and more teams, you know, along this journey. And some of these uh teams that I’m seeing are actually in large companies. Which is uh pretty interesting. >> Um I think that’s our time. Thank you so

[18:49] much for being here and answering questions. Thank you. Thank you all. >> [applause]