Most companies have deployed AI agents, but fewer than a third report business impact because pilots rarely extend across the full organization.
2
Teams scale agents when they change their workflows, tooling, and roles together.
3
Trust in agent automation grows through stages, from code reviews and blocking to autofix, auto-approve, and auto-merge.
Summary
The panel argues that deploying agents is easier than changing the way a software organization works around them. Research discussed at the start found that 80 to 90 percent of companies report some AI or agent deployment, while fewer than a third see business impact. Tariq Shaukat describes Sonar's shift toward an explicit guide, verify, solve process and says lighthouse teams alone did not spread new habits. Ali-Reza Adl-Tabatabai says large companies can use platform teams to set standards, measure developer productivity, and automate complete workflows rather than isolated tasks. The panel also discusses changing roles. Engineers need to make implicit organizational knowledge explicit, question confident AI output, and work as broader software generalists. Ali describes a gradual trust ladder for autonomous pull requests: review, blocking, automated fixes, automatic approval, and finally merging. The panel's view is that human oversight remains necessary, although the amount and location of that oversight can change.
Agent adoption is common, while scaled business impact remains rare
The moderator says 80 to 90 percent of companies report deploying AI or agents in some form, but fewer than a third say they have scaled them or seen business impact. Many efforts remain in proofs of concept or small environments instead of covering an end-to-end organization. The companies that do scale report gains such as higher pull request throughput, shorter pull request cycle time, and self-reported productivity improvements in software development work. The panel frames the problem as organizational, rather than simply a question of whether a company has access to an agent.
Scaling agents requires changes to process, tooling, and roles
The research groups the changes into three areas. Companies need to redesign the whole software development workflow around what agents can do, rather than add agents to a traditional lifecycle. They also need capable agents, harnesses, and context layers. The most overlooked area is people. Tariq says the old boundaries between software engineers, product managers, and designers are becoming less clear. Organizations that remodel their operating model around those changing boundaries are the ones seeing the strongest gains from agents.
Lighthouse teams do not spread new working habits by themselves
Sonar created lighthouse teams to demonstrate practices such as capturing product requirements and using them to generate evaluations for output verification. Tariq expected other teams to follow once they could see these examples. That did not happen quickly. Role modeling helped only part of the way. Teams also needed to understand why they were using agents and learn to think differently about their work. The lesson is that an example team and new tooling do not automatically change the rest of an organization.
Platform teams give large companies a way to copy small-team advantages
Ali contrasts a small startup, where a five- or six-person team adopted an AI-first approach, with his experience running developer platforms at Uber and elsewhere. He says large companies have a structural advantage when they have a platform organization responsible for standards and developer productivity. Such teams can measure code delivery speed, engineering throughput, quality, rework, and developer sentiment. They can then add agents to the existing workflow and see whether the changes improve results. Ali also argues for automating whole workflows and removing repetitive work so developers stay in the flow.
People need to make hidden engineering knowledge explicit
Tariq says engineers carry many decisions in their heads that are not written in a product requirements document. These include preferred patterns, dependencies, and ways the company likes to build software. Agents need more of this knowledge in explicit form. He presents that as a skill engineers must develop as software work becomes more orchestrated. People still need to specify what matters, define success, and decide what the machine or agent should control.
Critical thinking matters because AI sounds certain even when it is wrong
Tariq says AI produces plausible output with high conviction and does not naturally express doubt. The human role therefore includes knowing where to question the result, which assumptions to test, and what questions to ask. He compares this with reviewing work from a new team member: an experienced engineer knows where to probe and what evidence to seek. The panel treats judgment as a continuing human responsibility, even as agents take on more execution.
Tariq connects agent-driven workflows with a move away from tightly siloed roles. He says resistance to smaller teams often comes from people identifying as front-end or back-end specialists and worrying about work outside their area. He expects software engineering generalists to become more important. That does not mean knowing nothing deeply. It means being able to work across enough of the software lifecycle to operate in smaller, more self-contained units.
Trust in autonomous changes grows through a sequence of controls
Ali describes a progression based on observed precision. Teams first use agents for reviews and CI failure analysis. When the findings prove reliable, they add rules that block changes when the agent finds an issue. Next they try automated fixes and check that the fixes build successfully without creating new problems. Teams then allow the system to produce green pull requests, automatically approve certain low-risk changes, and eventually merge them. The final step depends on rules, context, and guardrails that make a team comfortable with the agent's precision.
"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 actually getting them to think differently is one of the critical missing links here."Tariq Shaukat06:00
Who should watch
You are moving from AI pilots toward agents that operate across a software delivery workflow and need a way to measure whether the change is real.
You run a platform or developer productivity organization at a large company and want to apply lessons from smaller AI-first teams.
Your team is deciding how much authority to give agents over code reviews, fixes, approvals, and merges.
