Dyad committed early to AI-led software development across an engineering organization built by 20 years of growth and acquisition. Getting there took translating popular approaches into the company’s own language, agent tooling built with Claude Code, and a rollout phased to fit teams mid-delivery.
Dyad has been building insurance software for more than twenty years, and it grew largely through acquisition. That left a large engineering organization with diverse processes and standards across legacy product lines, and two operating groups with distinctly different engineering cultures. One ran its own version of agile. The other was waterfall-driven.
A new CEO and CTO, together with the company’s private equity partners, agreed that AI-led development was worth moving on now rather than waiting for the market to settle.
At a Glance
Client: Dyad, an insurance services and technology firm with a 20-plus-year engineering history
Opportunity: Move a siloed engineering organization with diverse standards and two operating cultures to AI-native development
Dyad’s requirement: A practical path its teams could adopt mid-delivery, without stopping the work in flight
3Pillar’s role: Methodology translation and change enablement, agent tooling designed and built with Claude Code, and a governance and observability layer
Target: Every team on AI-DLC practices by the end of 2026, tracking on schedule
Moving early showed the work was organizational as much as technical
Dyad was ahead of most of its peers in committing, and committing early is what surfaced the real challenge ahead for the team. An effective, resilient AI SDLC isn’t just a tooling rollout an organization can install and push into teams. It changes how real-world work is spec’d, who reviews it, and what counts as done – and those answers were not identical across Dyad’s operating groups.
This fragmented operational condition is pretty common in companies built this way. Twenty years of growth, change and M&A had brought in teams with their own working practices. And most of those practices had shipped software successfully for years, they weren’t just getting thrown out.
A large organization with diverse standards does not have one starting point for an AI SDLC so Dyad named the three things it needed rather than working around them: a method fitted to its own context, the tooling to execute that method, and a change approach its teams would accept. 3Pillar was brought in for all three, and the program was scoped as one problem rather than three parallel workstreams.
The Three-Layer Cake
3Pillar translated AI-DLC for the taxonomies and methods that Dyad’s engineering org already used
The AWS AI-DLC is a strong high-level framework and a deliberately non-prescriptive one so 3Pillar’s first work was translation rather than construction. The team mapped Dyad’s legacy work units and stories onto AI-DLC concepts, worked out how an intent becomes an epic in Dyad’s own terms, and adapted the existing Jira workflows to the new terminology rather than asking engineers to learn a vocabulary that did not describe their work.
3Pillar selected Anthropic’s Claude to drive the program ideation and to produce the content and architecture underneath the methodology, so the method was developed with the same class of tooling it was teaching people to use. The same layer covered executive enablement: organization-level guidance for discussing AI adoption with teams and answering workforce transition questions honestly, and goal setting in terms that could be measured later rather than asserted. Leaders who can answer their teams’ questions are able to sponsor a change. Leaders who cannot are only able to announce one.
The agentic harness put the method inside the tools engineers already opened
The team knew that a method with nothing to execute it is essentially just documentation. That middle layer is the agentic harness 3Pillar designed and built with Claude Code: workflow commands and a centralized repository of Dyad-specific agents that engineers merge into their own projects. The agents generate test code and scaffolded development starting points, and they integrate directly with Jira and GitHub.
And that level of team-level integration into familiar tooling was key to adoption. Dyad’s work already lived in those systems, so nothing about an engineer’s daily routine had to change before the benefit arrived. The central repository matters for the same reason: a team adopts by merging agents into a project, and knowing the human roles in working with those agents, rather than by standing up an environment first. 3Pillar also recorded demonstrations of the workflows running end to end and showcased them across the company, proving the AI-DLC approach and tooling speed to people who had not yet used it.
With agents producing the first draft and the scaffolding, an engineer’s day moves toward specifying accurately, reviewing, and validating what comes back. That is a different skill from writing the code, and a different thing for a team to get good at.
What the Engagement Covered
Methodology translation mapped to the AWS AI-DLC. Executive enablement and change management. Goal setting and ROI framing. Agentic harness setup and configuration. Agent design, build, and adoption support. Jira and GitHub workflow automation. Pod-by-pod rollout and governance. Observability and measurement.
Phasing and honest measurement kept adoption on track and meaningful over time
Dyad’s teams adopted this new way of work in waves. The standard delivery unit is a three-person pod that owns its work end to end, and the rollout moves pod by pod: start small, learn, move to the next pod, learn again. Because they had active roadmaps to deliver on, Dyad teams were mid-progress on real development cycles throughout, which ruled out a single cutover.
The program planned for friction rather than hoping against it so all work was under a top layer of observability. 3Pillar and Dyad partnered to engineer a control tower reporting DORA-derived delivery metrics alongside adoption numbers, live agent-first pod counts, deployment speed, and defect rates. Quality is assessed on whether work clears its gates without rework rather than on how quickly a first draft appeared, which is the measure that separates AI acceleration from AI rework. Full-year data is still accumulating, and the program is tracking toward the end-of-2026 target.
Variety becomes an asset once teams share a method
Dyad’s disparate engineering org starting condition is what twenty years of acquisition-led growth produces, but differing practices are not in themselves a problem. They become one when ignored and change gets pushed without planning. Most established software organizations are in the same position, and an AI program tends to expose it, because AI tooling accelerates whatever process it is dropped into, including the parts that don’t work so well with one another. Change is as complex as it ever was.
The sequenced approach undertaken at Dyad made all the difference and is worth considering for other large engineering organizations seeking AI DLC adoption or similar paths. Method first, translated into the organization’s existing language. Tooling second, built to that method and merged into the systems the work already lives in. Phasing and measurement third, engineered in early.
Dyad now has one shared development methodology driving adoption, The Dyad Way. 3Pillar continues to partner in their transformation as methodologies, models, and best practices evolve and lessons are learned.
This program exercised 3Pillar’s AI SDLC transformation practice and its AIRE governance framework. For more on phased AI SDLC adoption in a large legacy engineering organization, see Pursuing practical, phased, real-world AI SDLC transformation. For the measurement model behind the control tower, see The four metric domains of effective AI SDLC adoption, governance, and ROI tracking. Contact 3Pillar here.
