Client Story: Pursuing practical, phased, real-world AI SDLC transformation for large legacy engineering org. (Ups and downs included.)

One 3Pillar client, an insurance services and technology firm, tried to transform its large siloed engineering organization with diverse processes and standards and legacy product line, towards AI-native production. The change stalled almost immediately.

Every engineering team operates with its own unique culture. Understanding what works, who to ask, how work is sized, and what counts as fast all tend to come from years of shared, earned instinct. Without real codified ways of work, trust becomes foundational to this dynamic, and it informs a mutual agreement on what good — and fast — looks like in daily operations.

The AI era has been both threatening and exciting for these teams. What began as simple IDE “code complete” features has evolved into a legitimate mandate to change the very culture that past progress hinged upon.

And despite the ability to ship code more quickly being obvious, the cultural and change-management ramifications of uncontrolled adoption and haphazard trust in AI have become equally apparent for leaders.

But the pressure to adopt is very real. Consider private equity (PE), a space in which 3Pillar works heavily, where driving operational change is the core business. PE firms increasingly require AI adoption across their portfolio companies, and as new paradigms like AWS’s AI-DLC take hold, the focus has shifted squarely to engineering.

Our client faced exactly this type of mandate.

Lindsay Kloepping, 3Pillar’s Head of Forward Deployed Practice, and 3Pillar Field CTO Lance Mohring, who architected the program solution, sat down for a conversation about that work and the strategic adjustments that made the difference.

What follows is their conversation on how organizations can move into agentic development while keeping delivery on track.

New methodology vs. real legacy constraints

Moderator: Why was this shift actually hard for the company to do on their own? What obstacles led this firm to seek outside help with their AI DLC engineering transformation?

Lance Mohring: You have to look at their legacy environment and engineering operations first. They have a solid 20-plus-year engineering history and grew largely through acquisitions. This left them with two distinct operating groups that had very different engineering and operational cultures. One group was leveraging their own version of agile, while the other was waterfall-driven. They also had new leadership, including a new CEO and CTO, who recognized an impedance between product management and engineering. They knew they needed a consistent dev culture and their own clarified view of what modern engineering would look like in its finer details to speed delivery. That said, AWS AI-DLC isn’t prescriptive enough on its own to solve that.

Lindsay Kloepping: Adding to that, a PE firm that we’re close with issued an edict to all of its portfolio companies, requiring them to transform engineering. The client started to pursue the change on their own but quickly hit a wall. They didn’t fully understand where to begin regarding tool changes and enablement needs, and they lacked sufficient confidence in their understanding of AI DLC to manage adoption at scale.

Over the past few years at 3Pillar, we transformed ourselves using our AIRE engineering methodology, which aligns closely with AI DLC. Given our own scaled success, we discussed how we could help them adapt an AI DLC “harness” and navigate the pains of transformation. Everything from idea intake all the way through story development, the actual coding of that story, the auditing and decision points along the way, and getting it fully deployed.

Moderator: Are they following the exact AI DLC methodology out of the box?

Lance Mohring: That doesn’t quite exist in the way that many think. AI DLC is a great high-level framework, but it is deliberately non-prescriptive and rightfully so. It doesn’t tell engineers exactly how to execute tasks or what tools, rules, skills etc must be in play. To make it practical, we adapted it using our own internal methodology as a starting point.

We delivered a complete agentic harness—actual workflow commands and a centralized repository of agents that engineers can merge into their projects. This generates test code, creates scaffolded development starting points, and integrates directly with Jira and Github.

Lindsay Kloepping: Exactly, we heavily adapted the AWS methodology based on this client’s reality. For example, we added specific elements to accommodate their team structure. They run in pods, which in their case consists of three people managing work end to end.

We adapted their AI-led software development so that these three-person “mobs” could still go through AI DLC-style inception and construction. Now, we are also helping them adopt operation-style methodologies through CI/CD.

Translating unfamiliar taxonomy to help existing teams adopt AI DLC smoothly

Moderator: How did you approach mapping the new methodology into the client’s existing, established Jira workflows?

Lindsay Kloepping: This was a big, big part of the change—taking the evolving rules and theories of AI adoption and getting practical about what it means for this organization.

We started pretty early with updating the vernacular from the client’s methodology to mirror terms like “bolts” and “mobs”, and we spent a copious amount of time mapping the client’s legacy work units and stories to those ideas.

Because this client uses a Jira-driven workflow, we had to figure out what a work unit is from a client’s-Jira perspective. What is their epic and their story, and how to bring that into this new way of operating.

To measure the effectiveness of this mapping and the subsequent changes, we conceived a new layer of metrics. We built a “control tower” as a parallel workstream to help us understand & visualize adoption and impact. We had to physically map what adoption looked like and match the client’s own language to make the change more understandable and traceable, such as translating how “an intent turns into an epic”.

Lance Mohring: The best way to visualize that structure—the methodology, the tools, and the control tower Lindsay mentioned—is something like a three-layer cake.

• The Foundation Layer: The AI SDLC definition and the human work of governance, change management and organizational enablement, which establishes how they operate and who adopts when.
• The Middle Layer: The tool definition and realization, meaning the actual agentic harness integrating to let engineers generate scaffolded development and test code.
• The Top Layer: What we called the control tower. This brings observability and actual ROI tracking, such as DORA metrics, to see exactly how fast an idea makes it to production and where defects occur.

Moderator: To be honest, this sounds like a complex change management effort, translating new concepts into current systems. Is that right?

Lindsay Kloepping: It can be useful to think of AI SDLC transformation like the mandate for Agile adoption 15-20 years ago. During early agile transformations, agile wasn’t actually a strict prescription. It was flexible, and you adapted it to your world. Someone who came in, threw agile at you, and demanded you do it their way without considering your existing environment almost always failed. That misunderstanding of practical change is why that transformation seems to have taken forever.

Coming in and being able to help them understand where they are today, adapt their language, and adapt their processes was crucial. They do not follow the methodology perfectly, and they are not set up to follow it perfectly right now. We helped them find a happy medium that actually works for them and ensures trackable success today. This is a much more practical approach that drives legitimate adoption progress.

“Someone who came in and tried to throw agile at you and said you must do it this way without considering the world that you live in today almost always failed.”

Pacing change management for effective rollout

Moderator: Let’s double click into your approach with this company a bit further. It makes sense when said out loud–slow and steady vs. fast and haphazard–but specifically why is an incremental approach to this transformation necessary instead of a full, “rip the band-aid” shift?

Lance Mohring: We are dealing with a generational-level shift here, much like the advent of agile 25 years ago, as Lindsay just pointed to.

But the urgency to do it the right way fast, is much higher. You have roughly three groups of engineers in most orgs: a minority who are highly amenable early adopters with creative product mindsets, a large group in the middle who aren’t as immediately ready for this shift and that you have to train and help adjust, and another minority who will have a much more difficult time to make this transition. You have to manage those real team and cultural complexities strategically. It requires a phased approach.

Lindsay Kloepping: Structurally, they are not set up for an immediate shift, though they will get there eventually. When you are dealing with change management—aiming for a just-noticeable difference over time—you can’t simply rip that bandage off. They are already mid-progress on real and important development cycles. We can’t just say, “Today you are going to do this, and tomorrow you are going to do that,” because in the real world, the team still has actual work to finish. And echoing Lance, they also have people who aren’t ready to work this way. We’re not just dropping in new rules or tools. So it’s our job to help the team to learn how to operate in an agentic fashion.

Moderator: How does leadership handle the varying speeds at which individuals adapt?

Lindsay Kloepping: Some individuals adapt to these changes faster than others. They are utilizing a rolling structure—starting small, learning, moving to the next pod, learning again, and continuing that cycle. It is about iterative improvement over time.

By the time we reach the engineers who are most resistant to the change, we will have already answered the majority of their questions and solved the early operational hurdles.

Establishing ambitious performance targets

Moderator: What incremental performance gains or even ambitious targets is leadership aiming for with these changes? Can you speak specifically?

Lindsay Kloepping: They didn’t really lay out stepwise changes or individual performance targets at a phase level. Not initially anyway, though our control tower is helping here now. Instead, they were primarily looking at adoption numbers and the number of live agent-first pods. They focused on hard adoption numbers rather than process metrics. The CTO is driving all of this, and wants 100 percent agentic code generation by the end of the year.

Lance Mohring: Yes and that’s made more practical and possible by tracking non-vanity metrics aggressively. Real indicators of progress so that the hard adoption figures we’re after are supported with data-driven team buy-in.

Moderator: Does hitting full code generation mean eliminating the pod model entirely?

Lindsay Kloepping: No, not for this team. It is still the pod model, but roles are evolving and further emphasizing judgement and product mindset. Engineers are not actually writing the code, that’s done by the agents. There are still skilled engineers in the loop making sure that the spec, the testing, and the acceptance criteria are correct. However, the primary coding is being done by agents 100 percent of the time. I don’t think they had a clear sense of what that velocity would look like. I really don’t think any company has seen what that is yet because there is so much change management involved. People used to promise us crazy results with agile too, but this is unique.

Measuring developer experience and quality

Moderator: What kind of feedback are you receiving from the engineering teams as they work through this new process?

Lindsay Kloepping: All in all, great feedback. The CTO likes to see progress. Every new pod that comes online and executes the process end-to-end without major problems represents progress. The volume of feedback is also a big metric for them. They would actually rather receive more feedback than less. Even if it is negative, “bad” feedback is great data that tells us that we collectively either missed something and need to adjust, or that we are doing something right and causing discomfort as we work to grow.

Moderator: Does this “bad” feedback focus more on the process mechanics or the emotional experience of the developers?

Lance Mohring: It is highly emotional because of classic change resistance and discomfort. Teams need a sounding board, through an organizational transformation unit to address those specific concerns, which is why we provided tools and support specifically for the CEO and CTO to manage this effectively at an organizational level.

Lindsay Kloepping: It is definitely both. We get hard feedback about the process itself. We sometimes might hear things like, “It took me three hours to get through something that should have taken me one!” This is to be expected as we shift and we all understand that not all changes–method, tools, measurement, agents, etc.– will come without friction or a need to fine tune. The net gains are clear and positive.

Moderator: How do you evaluate that short-term friction against long-term quality?

Lindsay Kloepping: When we hear about things slowing down unexpectedly, for example, it’s helpful to zoom out. What is missing from the comparison equation is usually how many times they had to rework the agent-written code at the end of those two hours of controlled execution versus the 15-minute fix the devs may have expected or been used to. If you’re used to a 15-minute fix manually, how many of those actually make it all the way through without needing rework? That is what we are trying to collect and understand right now. There is a perception in some cases that the new process is slower, but is it just slower upfront while providing a better long-term run?

That is part of what the control tower helps us identify. When you look at the quantitative feedback and see people passing through four quality gates without having to rework anything, that represents a significantly higher level of quality.

Scaling the model across the organization

Moderator: With these early teams providing good insights on adoption, how do you plan to scale this across the rest of the engineering organization?

Lance Mohring: They have successfully demonstrated this early success to the whole company, which was an incredible leap forward. Because the transformation is backed by a real toolset, the teams aren’t just hearing executives hand-waving about the future of AI—they are seeing actual recorded video of teams making things happen and achieving real outcomes with a clearly defined process and standard specific to their organization.

Lindsay Kloepping: Exactly. They have pods up and running now, and they are already collecting and sharing that information. We have been incorporating the feedback back into the control tower and the core processes so that the next pod comes online faster.

Moderator: What enables your team to guide this level of technical implementation so rapidly?

Lance Mohring: Ultimately, the number one success factor here is providing a consistent, applicable methodology backed by a real-world toolset.

We enabled their transformation group with the actual tools, ideas, and concepts they needed to navigate this significant industry change without gaps in understanding or definitions. They know what it takes for their organization and the job now is applying that understanding.

Lindsay Kloepping: We also had experts in the room who had done this before and navigated similar transformations. We had already done this transformation for ourselves with 3Pillar’s AIRE engineering framework.

We came in as experts who genuinely know how to execute this. We banged our heads against the wall doing it internally across thousands of engineers and for companies like ours, so we knew we could do it for them. The transformation itself is the incredible part.

This was a slow-moving company with some archaic systems, but it proves that you can take this methodology and use it on any system. They have modern repositories, older repositories, and repositories that don’t even run agile, yet we were still able to make this work inside their environment.

Engineering transformations succeed when leaders adapt new technologies to existing team realities rather than forcing immediate compliance. Organizations scaling AI must prioritize continuous feedback and iterative rollouts to secure both technical quality and operational stability. Interested in discussing? Contact 3Pillar here.