The Future of Software Engineering, Part 5: Designing for the Builder Age - Leading the Change Management to an Agentic SDLC
In our last article, we followed an "Instant Return" feature through every phase of ShopFlow's agentic delivery pipeline. Autonomous agent squads parsed requirements, created rapid prototypes, generated code, ran chaos tests, and managed a feature release, while human professionals stepped in at the precise moments where judgment, accountability, and context were required. For many readers, the natural follow-up question was a practical one: how does an organization that runs on sprint ceremonies, manual review queues, and siloed handoffs actually become a company that can operate this way?
It is a question worth answering carefully, because the industry has already run a large and expensive experiment on the most common answer. Over the past two years, most enterprises began their AI journey by purchasing licenses, distributing coding assistants, and tracking usage dashboards. Individual builders responded with genuine enthusiasm, and in McKinsey's 2026 State of AI survey, eight in ten respondents said AI has improved their own productivity. Yet the share of respondents reporting any enterprise-level impact on cost reduction and margin improvement from AI has held essentially flat at 37%, and the group McKinsey identifies as AI high performers has remained at roughly 6% of organizations. Builders are clearly getting faster, and most organizations are still searching for a way to turn that individual speed into business results.
The gap between those numbers is where this article lives. An agentic SDLC is an operating model, and operating models are adopted by people, one team and one habit at a time. While the tools can be deployed in an afternoon, the workflows, decision rights, quality gates, and shared knowledge that allow those tools to create value have to be designed, tested, and spread with intention. That discipline already has a well known name: change management, and it deserves the same engineering rigor we apply to the software pipeline itself.
Throughout our article series, we have argued that organizations should keep Humans in the Lead by defining what people must remain responsible for, before deciding what machines should do. We use two mnemonics to make that distinction. AI excels at the iterative, data-driven capabilities captured by "INFER" (Identify, Navigate, Formulate, Evaluate, Recommend), while humans own the intent-driven responsibilities and systemic accountability captured by "VALUE" (Validate, Appreciate, Lead, Understand, Envision). In this article, we apply the same principle to the transition itself. Before an organization decides which agents to deploy, its leaders should decide how people will be brought into the new way of working, who owns each decision along the way, and how progress will be proven.
If you are joining us for the first time, you can catch up on the series here:
Article 2: Navigating Career Evolution in the Age of AI
Setting the Stage: Why Tool-First Rollouts Stall
Most stalled AI programs follow a recognizable arc. Leadership announces an AI mandate, licenses are distributed, and usage climbs quickly. Builders begin generating more code, opening more pull requests, and starting more projects than ever before. Within a few months, the extra volume arrives at the parts of the delivery system that were never redesigned: code review, testing, security validation, and release approval. Queues grow, senior engineers are pulled into longer and more arduous reviews, quality signals begin to drift, and executives start asking why a significant investment in AI has yet to appear in delivery metrics.
The data on this pattern is now substantial. Faros AI's 2025 AI Productivity Paradox research, drawn from telemetry across more than 10,000 developers, found that teams with high AI adoption completed 21% more tasks and merged 98% more pull requests, while PR review time increased by 91%. Their 2026 follow-up study, covering 22,000 developers across more than 4,000 teams, shows the downstream strain intensifying. Epics completed per developer rose 66%, a meaningful gain for any roadmap. Over the same period, the ratio of production incidents to merged pull requests rose 242.7%, bugs per developer rose 54%, median time in review rose 441.5%, and pull requests merged with no review at all rose 31.3%. Faros describes the effect on experienced reviewers as a "senior engineer tax," since the people with the deepest system knowledge now spend their most valuable hours untangling code that looks correct on the surface.
Two findings from this research should shape how leaders plan a transition. The first concerns engineering maturity, where Faros reports that organizations with mature DevOps practices and strong delivery metrics experienced the same downstream deterioration as everyone else. The reality is that AI acts as an amplifier of whatever system surrounds it, magnifying the strengths of high-performing organizations and the dysfunctions of struggling ones. Although strong foundations can help, the workflow itself still has to be redesigned deliberately around agentic output for those foundations to hold.
The second finding concerns motivation, which turns out to be rarely the obstacle. Prosci's 2026 State of AI Adoption research, drawn from more than 1,500 workers, found that motivation to use AI was nearly identical in organizations that were thriving and in those that were stalling. The signals that distinguished progress were the organization's overall AI posture and how well teams fit with their AI tools, both of which are conditions that leaders create.
When these adoption challenges go unaddressed, the consequences eventually show up in budgets. Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls. Each of those causes is an operating model problem, and each one can be addressed through a structured, people-first approach to change.
The Builder Age Operating Model: A Hub, Pathfinders, and a Network
Organizations typically reach for one of two structures when they begin organizing AI adoption. The first is a centralized team that owns every decision, tool selection, and approval. This approach creates consistency early and then becomes a bottleneck as dozens of teams wait on a single group for guidance. The second is a fully federated approach in which each team experiments independently. This approach moves quickly at first and tends to produce fragmented tooling, duplicated effort, unmanaged security exposure, and a steady rise in shadow AI as teams route around any central process.
The model we recommend combines the strengths of both in a hub-and-spoke structure with three connected components: an AI Transformation Center of Excellence (CoE) that serves as the hub, focused tiger teams that act as pathfinders, and a network of builders embedded throughout the organization who carry proven practices into every team. This framework is meant to enable teams whose goal is to boost the skills of other teams and then move on, so that capability grows across the organization without creating a permanent dependency on a central group.
The Hub: The AI Transformation Center of Excellence
The CoE is a small, cross-functional group with the authority to set enterprise standards and the responsibility to make those standards easy to adopt. Its members typically include an executive sponsor, an Enterprise Architect, an Application Security Architect, a DevOps or platform engineering lead, a Product leader, a Production Data Analyst, and a dedicated change lead who owns communication, project management, and enablement. An effective CoE separates policy authority from delivery authority. It maintains the shared “Common Builder Toolkit”, and the teams building products remain accountable for what they ship with it.
We recommend chartering the CoE around five responsibilities:
Direction and Decision Rights: The CoE publishes the organization's AI stance, including which tools and models are approved, which data agents may access, and which decisions must always be made by a human. DORA's AI Capabilities Model lists a clear and communicated AI stance as the first of seven capabilities that amplify the benefits of AI, noting that ambiguity creates risk and that a clear policy gives developers the psychological safety to experiment. In practice, this is where leaders write down the VALUE responsibilities from our first article and map each one to a specific gate in the pipeline.
The Common Builder Toolkit: The CoE curates the shared assets that make the agentic SDLC repeatable, including common libraries, approved architectural patterns, agent configurations, context and prompt standards, reusable test harnesses, and pipeline templates. When a tiger team proves that a particular agent workflow is effective, the CoE packages it so the next team can adopt it in days.
Security and Trust: Security belongs in the charter from the first day. Veracode's 2026 GenAI Code Security Report found that across more than 100 models, the average security pass rate for AI-generated code sits at 56%, essentially unchanged from the prior year, even as AI now writes roughly half of all committed code in organizations that have adopted it. The AppSec Architect uses the CoE to codify secure coding standards, dependency and license policies, and data-handling rules into deterministic pipeline guardrails. They also threat model the agentic pipeline itself, so that every agent receives a defined identity, scoped permissions, and a human owner who is accountable for its behavior.
Measurement and Economics: The CoE owns the scorecard that tells leadership whether the transition is working, including the cost of running agent squads at scale. We describe this measurement layer in detail later in this article.
The Feedback Loop: Improvements flow in both directions. Production telemetry, incident reviews, tiger team retrospectives, and questions raised by builders all return to the CoE, which updates common libraries, architectural patterns, and process guidance accordingly. This loop keeps the Common Builder Toolkit aligned with how teams actually work.
The CoE's posture matters as much as its charter. Its most effective members behave like an internal product team, treating builders as customers and measuring their own success by how easily teams can adopt the standards they publish. When a hub drifts toward acting as a review board, it quickly recreates the very bottleneck the agentic SDLC was designed to remove.
The Pathfinders: Tiger Teams
Tiger teams are small, cross-functional squads drawn from real product teams and given a clear, time-boxed mission: take one meaningful value stream through the agentic SDLC, remove the friction they encounter, and document everything they learn for the purposes of becoming the model for other teams to follow. A typical tiger team mirrors the roles from our previous article, bringing together a Product Manager, a Lead Software Engineer, a QA Engineer, and a DevOps Engineer, with direct access to the Enterprise Architect, AppSec Architect, and Production Data Analyst through the CoE. They work on production software with real deadlines, because the review queues, legacy dependencies, and compliance requirements that determine success only surface on real work.
Tiger team members serve as the builders who felt the friction firsthand, solved it alongside their peers, and earned credibility by shipping. When a tiger team completes its mission, its members return to their home teams or seed the next wave of squads, carrying the kind of hands-on experience that no training course can replicate.
The Network: Builders Carrying the Practice Forward
The third component allows the model to scale beyond a handful of pilots. As each tiger team finishes its mission, its members join a growing network of motivated builders embedded across product teams. These builders host office hours, run short demonstrations of agent workflows, maintain shared repositories of proven configurations, answer questions in open collaboration channels, and relay friction back to the CoE. Some organizations formalize this network as an “AI champion program”, while others prefer names like “builder guilds” or “communities of practice.” Whatever the name, its function is to move knowledge from the people who have learned it to the people who need it, quickly and through trusted relationships.
Security leaders will recognize this structure immediately. It is the champion model that application security teams have refined for more than a decade to scale scarce expertise across large engineering organizations, and the evidence behind it is strong. According to Black Duck's analysis of BSIMM16, 96% of the top-performing organizations in the study have active champion programs, and BSIMM16 also recorded a 29% increase in organizations delivering expertise through open collaboration channels. The agentic SDLC carries this proven approach into a new medium, where the knowledge being shared now includes agent configurations, verification practices, and guardrail design alongside secure coding.
Restructuring Team Dynamics for the Agentic SDLC
While The Hub, The Pathfinders, and The Network describe the groups who lead the overall change management components, the day-to-day dynamics of engineering teams also have to evolve for the agentic SDLC to function, and there are three shifts matter most:
Governance Moves Into the Pipeline
The Existing World: Governance happens through meetings and approvals. Architecture review boards, change advisory boards, and security sign-offs are scheduled around human calendars, and each one adds days to delivery. Standards live on wiki pages that teams read once during onboarding and seldom revisit. When AI multiplies the volume of changes flowing through these checkpoints, reviewers either become overwhelmed or begin approving work they have had little time to examine.
The Emerging World: Governance is expressed as code and embedded directly into the pipeline. The Enterprise Architect's service boundaries, the AppSec Architect's security policies, and the DevOps Engineer's cost and permission limits become deterministic checks that run on every change, much like the topology, dependency, and cost-cap guardrails in our ShopFlow scenario. Human review is reserved for the decisions that genuinely require judgment, like confirming that a change actually serves its intended purpose, weighing architectural trade-offs, and accepting risk. Review boards evolve into forums where leaders refine the guardrails themselves, allowing the organization to Validate its controls continuously and Lead its standards forward as systems evolve.
Knowledge Moves Through Networks
The Existing World: Expertise is concentrated in a few senior engineers and specialist teams. Builders learn new practices through tickets, formal training, or by waiting for time on an expert's calendar. Lessons from one team's incident rarely reach another team before the same mistake repeats. AI tools make this problem more acute, since individual builders develop private prompting habits and agent workflows that never become shared assets.
The Emerging World: Knowledge flows through a deliberate network. Builders publish working agent configurations to shared repositories, host regular demonstrations, and translate CoE standards into the context of their own teams. Incident learnings and chaos-test discoveries are captured once and redistributed widely. Senior engineers are freed from answering the same questions repeatedly and can invest that time in mentoring, which helps the organization Understand what is happening across hundreds of teams and respond before small problems spread.
Enablement Centers on Workflows
The Existing World: AI enablement means tool access and a training course. Builders are handed licenses, shown a demonstration, and left to discover effective practices on their own. BCG's research observes that the time individuals save with AI tends to leak out of the organization unless it is tracked and deliberately reinvested, and most organizations have yet to put that tracking in place.
The Emerging World: Enablement is organized around the redesigned workflow. Builders learn the agentic SDLC by practicing it on their own services with an experienced network member beside them, covering how to write machine-readable requirements, how to validate a machine pre-audit summary, how to design chaos scenarios, and when to stop the pipeline. Learning plans are role-specific, reflecting the distinct shifts each role undergoes as we outlined in our third article. Time saved is intentionally reinvested in architecture, resilience, and customer understanding, giving builders room to Envision what their products should become next.
The Roadmap: Six Stages for Adopting the Agentic SDLC
The stages below are sequential in intent and overlapping in practice. Most organizations will run later stages in parallel as the network grows, and many will revisit earlier stages when a new business unit joins the effort or a significant technology shift occurs. Throughout every stage, humans define the responsibilities, boundaries, and measures of success first, and agents are then introduced to accelerate the work within them.
Stage 1: Establish Intent and Visible Sponsorship
Every successful transition begins with a leader who can articulate why the organization is changing and what it expects to achieve. Prosci's AI adoption research found that 43% of respondents attributed AI adoption failure to insufficient executive sponsorship, and McKinsey found that AI high performers are twice as likely as their peers to report that senior leaders demonstrate commitment to AI initiatives. Sponsorship at this stage needs to be visible and specific. The executive sponsor explains the business outcomes the agentic SDLC is meant to serve, publishes the organization's AI stance, and commits to a realistic timeline.
This is also the moment for candor about roles. Builders reading headlines about AI replacing engineers will interpret silence from leadership as confirmation of their fears. To head this off, leaders should proactively explain how each role at the company is expected to evolve, drawing on the kind of role-by-role analysis we shared in our third article, and should be honest about the organization's intentions for its workforce. The research gives leaders good reason to invest in their people. DORA's ROI of AI-assisted Software Development report strongly discourages headcount reduction as a path to AI returns, and Faros cautions that the engineers most often considered for cuts are frequently the ones absorbing the quality gap that AI output creates.
Leaders should also set expectations for a temporary dip in productivity. The same DORA report describes a J-curve of value realization, in which an early period of lower performance is driven by the learning curve, the "verification tax" of reviewing AI-generated work, and the effort of adapting downstream processes like testing and change approval. The report warns that leaders who misread this dip as failure risk withdrawing funding and forfeiting the eventual return. Naming the J-curve at the outset protects the program when the dip appears.
Stage 2: Map the Value Stream and Establish Baselines
Before changing anything, the organization needs an honest picture of how work currently flows. Value stream mapping traces a change from idea to production and reveals where work waits, where handoffs fail, and where quality problems originate. In most organizations, the map exposes a constraint downstream of code generation, typically in review, testing, environment provisioning, or release approval.
This stage also establishes the baseline metrics that will later prove whether the transition is working, including delivery throughput, review time, change failure rate, incident rates, security findings, and developer experience. A baseline captured before tiger teams begin is what allows the organization to separate genuine improvement from optimism later.
Stage 3: Charter and Staff the Hub
With intent and a baseline in place, the organization stands up its CoE using the charter described earlier. The first version should be deliberately lean. It needs an approved set of tools and models, a first draft of human decision rights mapped to pipeline gates, an initial set of security and architecture guardrails, the measurement plumbing required to capture the scorecard, and a clear intake process for tiger team missions. The CoE will grow the Common Builder Toolkit from what the tiger teams learn and prove, so exhaustive standards written before anyone has tested them on real work tend to create more friction than value.
Stage 4: Launch Tiger Teams at the Verification Gates
The most important sequencing decision in the roadmap is where the first tiger teams begin. The instinct is to point them at code generation, because that is where AI's speed is most visible. We recommend starting at the verification gates. When code generation accelerates into an unchanged review and testing process, the bottleneck moves downstream and more risk escapes into production. Tiger teams should begin where that pressure lands.
A tiger team's first mission focuses on four areas:
Rebuild the Pull Request Gate: The team implements the Machine Pre-Audit and Human Intent Review model from our previous article. A code-review agent checks each change against coding standards and architecture contracts and produces a clear summary, and the Lead Software Engineer validates intent and spot-checks the critical logic paths the agent highlights.
Codify Guardrails as Deterministic Checks: Working with the CoE, the Enterprise Architect and AppSec Architect translate the most important architectural boundaries, dependency and license policies, and data-handling rules into automated checks that block non-compliant changes before a human reviewer ever sees them.
Strengthen the Test Harness: The QA Engineer expands automated functional and regression coverage and introduces the first chaos scenarios, building enough confidence in automated quality signals that the team can rely on them as volume grows.
Instrument the Flow: The Production Data Analyst and DevOps Engineer confirm that scorecard metrics are captured for the tiger team's value stream, including review time, merges without meaningful review, and incident rates.
Once these gates can absorb higher volume, the tiger team scales up agentic code generation and extends the workflow upstream into planning and design. In the ShopFlow scenario, this is the work that made the pipeline from our last article possible. The guardrails that caught an unapproved open-source license and a runaway cloud deployment were built by an early tiger team focused on verification, well before coding agent squads were scaled across the platform.
Each tiger team mission should be time-boxed, typically to one or two quarters, and should conclude with a retrospective that captures what worked, what failed, and what the CoE should standardize.
Stage 5: Evolve the Common Builder Toolkit and Scale Through the Network
At the end of each mission, the CoE harvests the tiger team's artifacts into the Common Builder Toolkit: agent configurations, guardrail policies, test harness templates, review checklists, and onboarding guides. Tiger team members then become the first members of the builder network and help launch the next wave of teams, often joining new squads for a short period to transfer their experience directly.
Scaling in waves allows the organization to absorb change at a sustainable pace. Each wave should include teams that volunteered alongside teams selected for strategic reasons, since enthusiastic teams build early momentum and skeptical teams, once they see results, build credibility with their peers. Throughout this stage, builders should have a genuine voice in how the workflow evolves. Gartner research found that organizations using an open-source change strategy, which invites employees to shape the change throughout the process, are 14 times more likely to achieve change success and see the risk of change fatigue fall by 29 percentage points.
Stage 6: Measure, Reinforce, and Evolve
The final stage continues for as long as the organization builds software. The CoE reviews the scorecard on a regular cadence, shares results openly with builders, and adjusts the roadmap based on what the data shows. Reinforcement is easy to neglect once early momentum builds, yet it is where lasting adoption is secured. Organizations should recognize network members publicly, account for their contributions in performance reviews, and connect the new responsibilities to the career paths we described in our second article, where builders grow into Stewards, Visionaries, and Leaders (as defined here).
This stage also includes pruning, because as guardrails mature, some legacy approvals and ceremonies become redundant, and retiring them is one of the clearest signals to builders that leadership is committed to the new model. The feedback loop from production monitoring through the CoE and back into planning keeps the entire system improving, turning the transition into the same kind of flywheel that powers the agentic SDLC itself.
The Measurement Layer: Proving the Transition Works
Measurement serves two purposes in an agentic transition. It tells leaders whether the investment is producing value, and it gives the CoE the signals it needs to decide where to intervene. The central principle is to pair every measure of speed with a measure of quality and stability. As the Faros data mentioned earlier shows, throughput can rise sharply while quality quietly deteriorates, and an organization watching only one side of that equation will make confident decisions from an incomplete picture. DORA captures the goal well in its ROI report, suggesting that AI's value should be judged by the bottlenecks it clears.
DX's AI Measurement Framework offers a useful starting structure, organizing metrics across utilization, impact, and cost. We recommend extending it into a scorecard with six dimensions: Adoption and Proficiency, Flow, Quality and Stability, Security Posture, Economics, and Builder Experience. You can find example metrics for each dimension below, and we recommend choosing one metric across each dimension to start.
Adoption and Proficiency: Weekly active use of approved AI tools and agents, the share of changes flowing through the agentic workflow, and evidence that builders are developing real proficiency, such as completion of role-based learning paths and participation in the builder network.
Flow: Total time from idea to production, time spent waiting in review, work items stalled in progress, and throughput across the value stream.
Quality and Stability: Change failure rate, defect density, incidents per merged change, escaped defects, rework and code churn, and the share of changes merged without meaningful review.
Security Posture: The ratio of findings caught by pipeline guardrails to findings discovered in production, remediation time for critical issues, dependency and license violations blocked, and coverage of agent identities and permissions.
Economics: AI and compute spend per team, cost per successfully delivered change, and the portion of reclaimed time reinvested in higher-order work.
Builder Experience: Developer satisfaction, trust in AI output, and the review burden placed on senior engineers, all typically captured via interviews and surveys.
Expectations should be grounded in evidence as well. DX's longitudinal analysis of more than 400 companies found a median pull request throughput increase of 7.76% over a period in which AI usage rose 65%, with most organizations landing in the 5 to 15% range. Gains of that size are meaningful at enterprise scale, and they are well below many vendor claims. Organizations committed to the full operating model can aim higher, provided they plan to earn those results over several quarters as teams work through the J-curve.
Leading People Through the Transition
An agentic transition asks builders to change how they work, how they are evaluated, and in some cases how they understand their own professional identity. The strain of that shift is real and unevenly distributed. McKinsey found that 47% of mid-level managers and individual contributors report experiencing AI-related strains, compared with 31% of executives and senior managers. BCG found that nearly half of workers now spend more time managing and directing AI than doing the underlying work, and that 41% of regular AI users report increased cognitive load even as two-thirds report higher job satisfaction. Engineers asked to review a growing volume of AI-generated code carry an especially heavy share of that load.
Several practices help leaders support builders through this period:
Make It Safe to Stop the Pipeline: Builders need explicit permission to halt an agent workflow, reject a machine recommendation, or escalate a concern without penalty. Every STOP in our ShopFlow scenario depended on a person who felt empowered to act, and that confidence comes from a clear AI stance and from leaders who reward sound judgment even when it slows delivery.
Protect the Growth of Early-Career Builders: Organizations should design learning paths that build the verification skills builders need to Validate machine output, pairing early-career builders with experienced members and giving them structured opportunities to reason through problems before delegating them to agents.
Reinvest Reclaimed Time Deliberately: Time saved by agents should be visibly directed toward the work builders find most meaningful, such as creative problem solving, architecture, resilience engineering, customer behavior research, and mentoring. When saved time simply becomes a longer ticket queue, builders reasonably conclude that the transition benefits everyone except them.
Invite Builder “Allies” to Shape the Change: The people closest to the work will spot friction long before any dashboard does. Retrospectives, open forums, and a visible path from builder feedback to CoE decisions turn potential skeptics into contributors.
Engineering culture is shaped by these everyday signals: who is recognized, which concerns are taken seriously, and how openly knowledge is shared. A strong network of builders makes those signals visible across the organization and gives every team a trusted peer who has already walked the path.
Conclusion: Humans in the Lead of the Transition
Throughout this series, we have argued that the future of software engineering will be defined by what humans explicitly choose to remain responsible for. That principle applies with particular force to the transition itself. The organizations that capture lasting value from the agentic SDLC will be those whose leaders apply the VALUE domain to the change as deliberately as they apply it to the pipeline:
Envision: Executive sponsors define the desired future state and the business outcomes it must serve, and they communicate that intent clearly enough for every builder to see their place in it.
Lead: The CoE sets decision rights, security boundaries, and standards, and takes ownership of the Common Builder Toolkit that makes those standards easy to follow.
Validate: Tiger teams prove the new workflow on real software, beginning at the verification gates where risk concentrates, while the scorecard confirms whether the results are genuine.
Understand: The builder network carries knowledge outward and brings honest feedback back, giving leaders an accurate picture of how the change is landing across every team.
Appreciate: Leaders pay close attention to the experience of the people doing the work, including their cognitive load, their growth, and their sense of purpose, and they design the transition with that experience in mind.
Machines will continue to accelerate the INFER work of generating, testing, and evaluating software at remarkable speed. Bringing an organization along, building trust between teams, and spreading hard-won knowledge from one builder to the next will remain deeply human work. ShopFlow's pipeline was possible because people designed its guardrails, trusted one another at its handoffs, and shared what they learned along the way, and every organization hoping to operate that way will need to invest in the same foundation.
What's Next
Every element of the model we have described depends on a small group of motivated builders who are willing to learn first, share openly, and help their peers succeed. We have called them tiger teams and a builder network throughout this article, though many organizations already have a name for the people who do this work, and that name is "Champions."
The Champion model has been proven in application security for more than a decade, where a handful of engaged engineers extend the reach of a central team that could never scale its expertise across hundreds of developers directly. That same constraint now governs AI adoption, and it applies with more urgency, because the pace of change leaves no room for a central team to reach every builder on its own.
In our next article, we will look closely at what a champion actually does in the age of AI. We will define the role for both security and AI champions, explain where they should sit inside an engineering organization, and separate the responsibilities that matter most in the first months of an agentic transition from the ones that sustain it over years. AI will keep changing what builders do from one quarter to the next, and the need for trusted peers who can translate that change into daily practice is not going anywhere.
Sources
McKinsey & Company, The State of AI in 2026: On the Road to ROI (August 2026)
Faros AI, The AI Productivity Paradox Research Report (2025)
Faros AI, AI Engineering Report 2026: The Acceleration Whiplash and Ten Takeaways (2026)
DORA, 2025 State of AI-assisted Software Development (2025)
DORA, AI Capabilities Model (2025)
DORA, The ROI of AI-assisted Software Development (2026)
Prosci, 2026 State of AI Adoption research announcement (August 2026) and AI Change Management
BCG, AI at Work 2026: Strategy Matters More Than Tools (June 2026)
Gartner, Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (June 2025)
Gartner, Open-Source Change Strategy Research
Team Topologies, Key Concepts
Veracode, 2026 GenAI Code Security Report (July 2026)
OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications 2026 (December 2025)
Black Duck, BSIMM16 AI Application Security Insights and BSIMM16 Release (2026)
DX, Measuring AI Code Assistants and Agents and How to Measure AI's Impact
Shen, J. H., and Tamkin, A., How AI Impacts Skill Formation (2026)
AWS, AI-Driven Development Life Cycle: Reimagining Software Engineering (July 2025)
Comments