Mike McQuade, VP of Engineering + R&D Operations at Thinkific, is a guest contributor to this post.
tldr;
Even with a legacy codebase, this is a case study on how code output could be doubled (2X), net velocity tripled (3X), and deployment velocity increased by 11X through the adoption of an AI-native SDLC.
Framing the Shift to an AI-native SDLC
During my tenure at Thinkific (and where Mike is still the VP/Engineering & R&D Operations), we decided to be overtly aggressive on the adoption of AI. We were early on the Cursor bandwagon, which moved the needle of AI produced code. But, this wasn’t a game changer; it was a slight boost.
When the Claude Opus 4.x models appeared in Fall of 2025, it was clear a next-level game changer had arrived. As we entered 2026 planing, we decided to set out some aggressive goals and remake our SDLC with the goal of achieving an X-factor in net engineering productivity.
At Thinkific, Atlassian DX is utilized. One of the things we like about DX is that you can compare your engineering metrics against those within Atlassian’s aggregated and anonymized data sets across hundreds-to-thousands of companies.
To get to an X-factor in terms of net developer productivity, in the sprit of “less is more”, we decided to focus on:
- Lead Time – getting this to best in SaaS levels of 10 days or less.
- Cycle Time – getting to the 90th percentile for comparable SaaS companies as measured by DX
- PR Throughput – getting to the 90th percentile for comparable SaaS companies as measured by DX.
- 30% of Code per Team Contributed by AI – we set this target based on big tech (e.g. Microsoft, Google, etc.) were publicly claiming based on having comparable legacy codebases and all of the assorted complexity.
- 90% of Engineers Using AI Daily – We didn’t set 100% because people need to take training, vacations, and/or occasionally get sick.
We calculated that if we did this – and did NOT sacrifice quality or reliability – we would be several times more efficient than we were going into the year and achieve our X-factor goals.
The journey we then set upon to get there took many twists and turns as is the case when trailblazing when there is zero map or precedent. We had many “lessons burned” along the way and have now emerged much smarter for the next time Mike or I go about doing this. (Those lessons burned are literally enough material for its own blog series. I’ll summarize key considerations in a few other posts in this series.)
What did we ultimately end up doing?
We took our two most pro-AI teams, gave them Claude code (and some consulting help of arguable utility, though it was a good forcing function), and the mandate to build a new SDLC while driving like they are in a F1 race going for the podium. We took the best of both of these teams outputs and created a homogenized framework, which was then rolled to the entire organization as a V1.0 AI SDLC. And, leveraged the great results from these first two teams as internal thought leadership to address internal fear/uncertainty/doubt and/or skepticism. After one quarter in flight with the entire organization and the V1 1.0 AI SDLC, the results are in – and FAR exceeded our expectations.
Trunk-based Development; an Important & Dependent Shift
To uphold our desire of maintaining quality, we made the call that as part of our AI SDLC shift that we would move to Trunk-based Development (TBD). It is a version control strategy where all code is merged into a single central branch (“the trunk” or “main”) frequently – often multiple times per day.
Instead of developing features in long-lived side branches for weeks or months, engineers work in short-lived branches continuously moved into the trunk. This results in changes being broken down into small incremental updates versus large monolithic changes. Every merge into the trunk requires an automated Continuous Integration suite (tests, linters, security scans, etc.) to ensure the trunk remains stable and deployable at all times. Incomplete or in-progress features are wrapped in feature flags so code can be safely merged and deployed without exposing something incomplete or “under construction” to users.
This was a key dependency to unlock the speed an AI-native SDLC is capable of unleashing – WITHOUT sacrificing quality or stability.
What results did we achieve?
While we can’t get into absolute specifics publicly, we can definitely dive into relative improvements. We are now producing ~2x as much code on a daily basis. With the other delivery improvements, this translated into ~3x net velocity.
Here’s where we netted out against our original goals:
- End-to-End Cycle Time – we improved this by approximately 30%; this didn’t quite get us to goal but will likely see it achieved in the 2nd half of 2026. (This goal is highly influenced by product and design and requires significant streamlining of the pre-engineering work.)
- PR Cycle Time – we improved this by approximately 90%.
- PR Throughput – we improved this by over 100%, effectively doubling the amount of code we were producing on a daily basis.
- Code Written by AI – we were able to get this over 80%, proving that even with a complex, legacy codebase – AI can be the majority contributor when done correctly.
Obviously, it goes without saying that this was an all-hands-on-deck exercise and everyone was participating, including many in non-Engineering disciplines.
But, it didn’t stop there. We ended up seeing may other improvements across-the-board, including on failure rates and ability to recover via the combination of the AI SDLC and Trunk-based Development. Examples include:
- Trunk Build Failure Rate – reduced by over 90%
- Pre-merge Check Failures – reduced by 15%
- Time to Recover for the Trunk – reduced by over 90%
- Time to Merge a PR into Production – reduced by over 80%
- CI Pipeline Runtime – reduced by over 30% and changes in flight will reduce that further in the 2nd half of 2026
This translated into a net deployment velocity improvement of ~11x.
The results are phenomenal and I am incredibly proud of the team and what was achieved. Although this was by no means a simple or pain-free process, the “eggs broken” were more than worthwhile as evidenced by the results.
What’s more amazing is this is a v1.0 effort. With the application of learnings, continuous improvement, and rapid improvement in underlying AI frontier models, it’s only going to get better from here, albeit probably much more incrementally.
So, as one navigates the SaaSpocalypse, the question on whether or not the pain of implementing a native AI SDLC is worth can be definitively answered: YES it is worth it. And, as for it being a table-stake, it almost certainly is going to become one or be one of the very first steps in an acquiring entity’s value creation plan (combined with a requisite discount on purchase price) if not already in place.
Leave a Reply