A panel discussion, recorded at the AI Engineer World's Fair 2026 in San Francisco, on how software teams redesign their work around AI agents. Speakers are Tariq Shaukat, CEO of Sonar, and Ali-Reza Adl-Tabatabai, former CEO of Gitar (now part of Sonar) and former head of Uber's developer platform; McKinsey moderates. The description says research with Sonar found that teams getting results from agents changed their process, tooling, and people and roles. Topics covered include why lighthouse teams alone don't spread new habits, making implicit knowledge explicit, critical thinking when AI sounds confident, how large companies can apply lessons from small teams through platform organizations, and how trust in AI code review can progress to autofix, auto-approval, and auto-merge. These are the speakers' stated topics as summarized in the description; the research findings are reported by the description and not independently verified. # Channel Identity Observations — Panel Video ## Explicit Self-Description Evidence - **Moderator affiliation (McKinsey)**: The moderator cites internal research — *"We did some research on this… 80-90% of the companies that you ask, they say we have deployed AI or agents"* — and describes joint work: *"We worked with Sonar um Tariq to figure out what are the key factors."* - **Guest self-descriptions**: - Tariq introduces himself as **CEO of Sonar**, describing it as starting *"as an open-source project 18 years ago."* - Ali introduces himself as former **CEO of Gitai/Gitarr** (*"now we're actually part of Sonar"*), previously *"responsible for the entire developer platform organization"* at Uber, with past roles at *"Google and Facebook."* - No explicit self-description of the channel/host itself appears beyond the moderator's framing; the channel's role is evidenced only as **panel convener and moderator**. ## Intended Audience - **Enterprise engineering and technology leaders**: Discussion centers on scaling AI agents *"across end-to-end organizations,"* maturity horizons, and operating-model redesign. - **Platform and developer-productivity teams**: Ali's advice targets *"a platform team when you're looking at how do we adopt these tools"* — metrics, telemetry, developer sentiment. - **Live event audience**: The moderator notes *"We'll leave some time at the end for questions if we can, so you guys should also ask,"* indicating an in-person/conference setting with closing applause. ## Claimed Scope of Content - **Topic scope**: AI agents in the software development lifecycle — adoption, scaling maturity (Horizon 2 vs. Horizon 3), workflow redesign, tooling, and organizational/role changes. - **Format**: Moderated **panel/Q&A with industry executives** (Sonar CEO, Gitai CEO, McKinsey moderator). - **Collegial, vendor-adjacent positioning**: Content references a McKinsey–Sonar collaboration and a Sonar-acquired product (Gitarr), blending research findings with product adoption narratives. ## Observable Presentation Patterns - **Research-grounded framing**: Opens with quantitative claims (*"less than a third"* seeing business impact) before Q&A. - **Named frameworks and maturity models**: Terms like *"Horizon 2," "Horizon 3,"* and Sonar's *"guide verify solve model"* are presented as established frameworks. - **Product-illustrative anecdotes**: Ali describes a user trust progression in Gitarr — from *"they just use reviews"* to *"fully autonomous end-to-end PR creation through merge."* - **Forward-looking claims**: Predictions such as *"within the next year we'll see more and more teams… along this journey."* ## Claims vs. Demonstrated Patterns — Distinction - **Creator claims**: Research statistics, the "three factors," maturity horizons, and the trust-progression model are asserted by speakers without underlying data shown in the transcript. - **Demonstrated**: The video demonstrates access to senior industry figures (CEOs of Sonar and Gitai), a McKinsey research partnership, and a conference-panel production format. - **No private motives inferred**: Speakers' personal anecdotes (e.g., Tariq's son choosing a college major) are treated only as presented rhetorical content, not as evidence of belief or motivation. # Delivery Observations: Redesigning How Software Gets Built With AI Agents ## Scope and Source Limits - **Speakers:** A moderator (Prakhar), Tariq (Sonar CEO), and Ali (former Gitar CEO, now part of Sonar). The transcript has no speaker labels. Attribution below is inferred from introductions, addressed names, and `>>` turn markers. - **Transcript quality:** The text appears machine-generated. The product name is spelled inconsistently ("Gitarr," "Guitar"), and some words may be misheard. - **Evidence strength:** One panel recording gives limited repetition. Patterns noted as "recurring" appear more than once. Anything based on a single instance is labeled as isolated. --- ## 1. Moderator (Prakhar) ### Framing and Transitions - **Context-setting openers:** The moderator restates the topic before introducing it. > "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." - **Confirmation-seeking tags:** The moderator frequently ends claims with "right?" > "So, what gives, right? Like, what was the reason why that doesn't happen?" > "Not surprising, right?" - **Enumerated framing:** The moderator previews structure with counts and ordinals. > "there are three factors that actually help this, not surprisingly. One is redesigning your process workflow... Second is tooling... But the more critical thing..." - **Short acknowledgments between answers:** Responses such as "Yeah, makes sense." and "Awesome." signal turn-taking. They are brief and neutral in tone. --- ## 2. Tariq (Sonar CEO) ### Vocabulary and Phrasing - **Process-oriented language:** Tariq repeatedly frames answers around "process," "system," and "how do you." > "how do you actually uh transform an organization?" > "being very deliberate about what the process is that we're putting in place" - **Coined or borrowed shorthand:** Tariq uses an industry term, "token maxing," then rejects it. He also refers to a "guide verify solve model." > "the objective was never for us token maxing or anything like this. We don't really like that uh type of idea." - **Explicit source attribution:** Tariq openly credits a borrowed idea. > "the point that I read on Twitter and I'm I'm shamelessly stealing it" (Note: This is attributed to Ali in the transcript's later section, not Tariq. See Section 3.) - **Surprise framing:** Tariq uses a "surprise" framing to introduce a lesson learned. > "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." ### Teaching Habits - **Problem-then-correction structure:** Tariq states an expectation, then contrasts it with what happened. > "And what we found is that's not actually the case." - **Organizational examples:** Answers draw on specific internal mechanisms such as PRD agents, eval generation, and lighthouse teams. - **Self-correction mid-sentence:** Tariq restarts or reframes in progress. > "So, the the the..." (Note: Disfluencies like "the the" and "uh" appear throughout. They are present in both speakers.) --- ## 3. Ali (Former Gitar CEO, Now Sonar) ### Vocabulary and Phrasing - **Trust as a recurring keyword:** Ali repeatedly foregrounds trust as the central concept. > "I think uh trust is the the keyword here." - **Vivid metaphors:** Ali uses figurative language for process and capability. > "give the agent some teeth" > "the software factory idea" > "the promised land of 10x productivity" (Note: this phrase appears in the moderator's framing, not Ali's answer.) - **Borrowed-idea attribution:** Ali credits a source with a casual admission. > "I'm I'm shamelessly stealing it" (Speaker attribution for this line is inferred. The line appears in Ali's answer about critical thinking.) ### Teaching Habits - **Numbered principles:** Ali organizes advice with explicit ordinals. > "So, I I that's number one. Number two, I think again you mentioned is very important..." > "And I think the third thing um I you know..." - **Concrete staged progression:** Ali describes a step-by-step ladder of automation, from reviews to blocking, auto-fix, auto-approve, and auto-merge. > "the typical pattern we see is at first they just use reviews." This is one of the most structured explanations in the transcript. It moves through discrete, named stages. - **Analogy to human onboarding:** Ali uses a familiar comparison to explain expected judgment. > "If you have somebody joining your team, you have an intern joining your team, you're going to kind of know where to poke." - **Caveat-then-qualify pattern:** Ali often states a conclusion, then adds conditions. > "But it doesn't come immediately. Right? It comes with using the system, building trust..." ### Hedging and Uncertainty - **Forward-looking estimates:** Ali frames timing as an approximation. > "I think within the next year uh we'll see more and more teams..." - **Personal-experience grounding:** Ali anchors claims in his own prior roles. > "I was responsible for the entire developer platform organization." --- ## 4. Cross-Speaker Patterns ### Recurring (observed in multiple turns) | Feature | Examples | |---|---| | Filler words ("um," "uh," "you know," "like") | Present in all three speakers, very frequent | | Tag questions ("right?") | Moderator, Tariq, and Ali all use them | | Hedging with "I think" | Ali most often; Tariq and the moderator use it too | | Enumerated structure ("number one," "one is...") | Moderator and Ali | | Disfluent restarts ("I I," "the the") | Tariq and Ali | ### Isolated (single occurrence or thin evidence) - The "generalist" argument, where Ali (or Tariq) says the era of the generalist has arrived. This appears once and is not clearly repeated. - The "software factory" metaphor. It appears once, in Ali's answer. - The "give the agent some teeth" phrase. It appears once, but is memorable. ### Uncertain Attributions - The "shamelessly stealing" line is in Ali's critical-thinking answer. Some uncertainty remains because the speaker boundary is not labeled. - The "promised land" phrase appears in the moderator's opening, not in a panelist's answer. --- ## 5. Summary of Observable Delivery - **Tone:** Conversational and informal throughout. Speakers use filler, self-restarts, and casual admissions. - **Structure:** Answers are often enumerated or staged. Ali's automation ladder is the most explicit example. - **Vocabulary:** Recurring key terms include "trust," "process," "workflow," "grunt work," "in the flow," and "generalist." - **Teaching habits:** Concrete examples, analogies to human onboarding, and step-by-step progressions appear regularly. - **Hedging:** Speakers qualify claims with "I think" and approximate timelines, which keeps predictions tentative. # Position Record: Redesigning How Software Gets Built With AI Agents — Sonar & McKinsey Panel ## Speakers - **Prakhar** (McKinsey) — moderator, presents research context - **Tariq** — CEO of Sonar - **Ali** — former CEO of Gitai/Gitarr (now part of Sonar); previously led developer platform org at Uber; prior platform roles at Google and Facebook --- ## Prakhar — Research Context and Framing ### Deployment vs. Impact Gap - **Claim:** 80–90% of companies say they have deployed AI or agents in some form, but fewer than a third have scaled it or seen business impact. - **Reason for the gap:** Many companies operate in POCs and small environments rather than end-to-end across the organization. ### Maturity Horizons - Most companies are at **Horizon 2**: human-guided and validated agents executing tasks across the SDLC. - Few are at **Horizon 3**: fully end-to-end automated workflow **with human oversight**. - Companies doing this at scale see gains in **PR throughput, PR cycle time, and self-reported productivity**. ### Three Scaling Factors 1. **Redesigning the process workflow** end-to-end, not thinking in terms of traditional SDLC. 2. **Tooling** — good agents, harnesses, context layers. 3. **People** — the most overlooked factor. ### Role Boundaries Blurring - Traditional boundaries between software engineer, product manager, and designer are blurring. - Organizations that remodel their operating model around this are the ones "seeing the promised land of 10x productivity." - Observed conversion pattern: skeptics who said "agents will do the task, but we don't need to touch anything else" gradually converted to "we need to rethink and reshape how our orgs are organized." --- ## Tariq — Guidelines for the Transition ### Sonar's Own Transformation - Sonar started as an open-source project 18 years ago; adopting AI natively has been "a bit of a transformation" for its engineering team. ### Guidelines 1. **Be clear about the objective.** - The objective was never "token maxing" — explicitly rejected as an idea ("we don't really like that type of idea"). - The goal is generating real value; being super clear about what you measure matters. 2. **Be deliberate about the process.** - Sonar orchestrated everything around the **guide–verify–solve model** internally, as it recommends to others. 3. **Build trust in agents via lighthouse teams.** - Working with McKinsey, they found team-built agents (e.g., **PRD agents** generating evals for output verification) were "not natural to the team"; lighthouse teams highlighted best practices. ### Surprising Finding (Tariq's Own Expectation Contradicted) - He expected lighthouse-team role modeling would let other teams follow quickly. - **Finding:** That is not the case — role modeling gets you only part of the way; tooling can be set up, but getting people to **think differently** and understand *why* they use agents is a critical missing link. ### Implications of Full Agentic PDLC - **No completely hands-off world:** "I don't think that there's going to be a world in which you can be completely hands-off." The question is how much to leave to the machine vs. control upfront (specification, definition of success). - **Explicitness as a skill:** Much design knowledge is implicit ("my company likes this dependency"); more will need to be made **explicit rather than implicit**, which is itself a skill set. - **Critical thinking:** Quotes (attributed to "a point I read on Twitter," shamelessly stolen): AI "always gives you very high conviction plausible output... it never admits to any doubt." People's job becomes knowing where to poke and question — analogous to supervising an intern. - **Era of the generalist:** Resistance to smaller/atomic teams usually boils down to role siloing ("I'm a front-end person, not back-end"). Tariq claims this is the era of the **software engineering generalist** — with the qualification that he doesn't mean someone who knows nothing about software, but rather generalists over deep specialists in front-end/server-side. --- ## Ali — Small-Team Lessons and the Trust Curve ### Background Stated - Gitarr was a five-to-six-person startup building an agentic PR-validation solution; originally not AI-first, then transitioned to AI-first, seeing accelerated demand and "a tremendous amount done with a much smaller team." ### Structural Advantage of Large Companies - **Claim:** Large companies have a structural advantage — they typically have **platform teams** (as at Uber) responsible for standards and developer productivity. ### Three Principles for Platform Teams 1. **Good metrics as a baseline** — velocity to production, throughput, quality, error/rework rates, and **engineer sentiment** ("are engineers actually feeling it?") — so AI adoption can be measured and iterated. 2. **Think in entire life cycles and workflows**, not point tools — offload entire workflows to autonomous agents. 3. **Optimize for developer flow** — automate away grunt work. Agents are "perfect for that"; this yields not just productivity but high sentiment, "equally important if not the most important thing." ### Trust and the Automation Staircase (in response to Prakhar's question on whether trust in automated validation/testing will rise) - **Claim:** Trust comes with time, built through observing **precision** of the AI. Observed adoption pattern at Gitarr users: 1. Use reviews / CI failure analysis only. 2. Seeing precision → set rules to **block** on agent-flagged issues. 3. Try **automated fixes** (agent creates PRs to fix issues). 4. If fixes pass build, iterate to green, don't introduce new problems → unlock **auto-fix**. 5. Add rules to **auto-approve** certain PRs / non-critical parts of the code base. 6. Final step emerging: **auto-merge** including merge-conflict fixes — fully autonomous PR creation through merge. - **Prediction:** "We're rapidly approaching" full autonomy; **within the next year** more teams will be along this journey — and notably, some leading teams are in **large companies**. --- ## Unresolved Tensions - **Hands-off vs. oversight:** Tariq insists a fully hands-off world won't happen even at Horizon 3 ("orchestrated" with human oversight), while Ali describes a trajectory toward fully autonomous PR-through-merge flows — the panel does not reconcile the endpoint. - **Role modeling shortfall:** Tariq's own expectation that lighthouse teams suffice was contradicted by experience — the people/mindset gap remains unsolved by tooling alone. - **Generalist vs. specialist roles:** Tariq asserts the generalist era; Prakhar's research notes role-boundary blurring — but no panelist addresses what happens to deep specialists. - **Timeline confidence:** Ali's "within the next year" prediction is stated as his view, not a settled fact. # Speaker Attribution & Provenance Record ## Video **Title:** Redesigning How Software Gets Built With AI Agents — Sonar & McKinsey Panel **Format:** Conference panel with moderator-led Q&A ## Speakers & Roles - **Prakhar (McKinsey)** — **Moderator / Panel host** - Opens the session, introduces panelists - Presents McKinsey research findings (80–90% AI deployment; fewer than a third scaled) - References joint McKinsey–Sonar work on AI in the SDLC - **Tariq — CEO of Sonar** — **Panelist (vendor executive)** - Describes Sonar's origin as an open-source project 18 years ago - Discusses internal transformation, lighthouse teams, guide-verify-solve model - Anecdotes about his son choosing a college major - **Ali — CEO of Gitai (now part of Sonar)** — **Panelist (vendor executive, acquired startup)** - Former head of developer platform at Uber; prior platform roles at Google and Facebook - Discusses small-team vs. large-org scaling, metrics, autonomous PR workflows ## Referenced Sources & Claims - **McKinsey research** (presented by Prakhar, unverified): deployment vs. scaling statistics; Horizon 2/3 maturity framework; "three factors" (process redesign, tooling, people) - **Joint McKinsey–Sonar study** with Tariq: claimed results on PR throughput, PR cycle time, self-reported productivity - **Third-party reference by Tariq:** "the point that I read on Twitter" — quote about AI giving "high conviction plausible output"; speaker explicitly notes he is "shamelessly stealing" it (unattributed source) - **Ali's user observations:** Gitai/Gitarr customer adoption pattern — reviews → blocking rules → auto-fix → auto-approve → auto-merge (vendor-reported, unverified) ## Promotional Segments - Ali's description of Gitai's automation adoption curve functions as a **product walkthrough/promotional segment** for Gitai (a Sonar company) - Tariq's references to Sonar's "guide verify solve" model and his prior talk carry **self-promotional** framing ## Uncertainty & Gaps - Panelists' full names beyond first names not given in transcript - No curated metadata supplied; no comment availability information - Transcript contains transcription inconsistencies ("Gitai"/"Gitarr/Guitar"; "Tropic"/"Anthropic" likely) — recorded as-is without correction \>\> 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 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 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 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 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 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 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 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 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 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 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. \>\> 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 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 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 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 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 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? 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 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. 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 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? \>\> 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 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 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 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 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 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 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 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. 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 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 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 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. 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. 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 much for being here and answering questions. Thank you. Thank you all. \>\> \[applause\]