Today’s Problem
The widespread adoption of AI tooling in software engineer teams has been a mixed bag for most. One side sharing how significant the tooling has been at both a individual and team level productivity, on the other hand others who simply do not see the wow factor
As a preface I am far from an AI skeptic, as my firm belief is that when used correctly, AI can certainly improve your team’s ability to ship — surpassing even the 30% metric. Emphasis on “used correctly”
The Adoption Dilemma
The biggest issue like any new tool on the software market is that adoption. Let’s take a step back to 2010s when Jenkins was driving through the adoption of CICD pipelines. Similar to AI there were folks who were skeptics and those who were quick to integrate into their projects. Those who spent time and attention to adopting structured pipeline designs into their SDLC flow found significant gain. Others who dismissed its return on investment or implemented it just to “have it” saw no materialized gain. A perfect analogy of this point, is that you can use the latest and greatest SDLC tooling, but the ROI will not be felt if you’re waiting hours running a pipeline.
“Just because your team has access to Copilot, Cursor, or Claude Code does not mean you’ll realize that X% gain.”
If your team is not invested or aware on how to utilize these tools to the best of their ability, they’ll be staring at a chat bot screen wondering why they’re even using it.
Food for thought
As a team lead or senior on your team, if you find yourself realizing these productivity gains at an individual level, bring it to a larger forum and share what works and what didn’t work. Below I’ve shared a 3 step checklist you should bring to this forum.
3-Step Guide
(1) Do Research Outside Your Job Facet
Just because you found a way to improve X% of some Y flow. It doesn’t mean this is perfect approach to the solve the problem.
If you believe you could use a custom MCP server for your project to allow users to ask platform questions. Maybe you could reduce the MCP overhead and create a custom CLI that reduces token usage by 94% (for a great read on this topic look at https://kanyilmaz.me/2026/02/23/cli-vs-mcp.html).
If you are driving the AI initiative in your team or org, you will be asked questions on your technical decisions, so do come prepared.
(2) Speak individually with your teammates
Before you present, understand what pinpoints your team or organization is facing, to better understand why gains are not being materialized.
Some examples are:
- “Even with AI tooling our SDLC is frustrating”
- “I can’t seem to get
to give me a good response” - “I don’t trust the code”
- “We don’t have enough token usage”
(3) Bring The Numbers To The table
If your audience is more senior or closer to the business it is crucial to use language that can be understood at a their level.
Think along the lines of business analytics, PnL benefit, operating cost reduction, DAU/MAU, compute savings, system performance optimization, increase in customer response time, etc…
An example might be, you work on a CRM product. Every week your team has to perform a manual analysis to check whether users have had meaningful conversations with clients. This comes from an ask from the sales analytics team that needs this info.
Instead of performing this manually you could argue a benefit from utilizing AI to vectorize these conversations and provide a review from these conversations. You’ll have to provide the time/cost to implement and the benefit.
The time and cost here could be 2 engineers working on this for the next 2-3 months. The benefit would be that you save an engineer 4 hours a week from having to manually query this data, clean it, then send it over to the analytics team.
If an engineer on your team is paid $50/hour you could do simple math and say:
$50 * 4 = $200 (per week) $200 * 52 = $10,400 (per year) Your team would be saving $10,400 year
If you want to read more about pitching AI solutions in an enterprise world a great read is Frictionless by Nicole Forsgreen and Abi Noda.
Final Words
What separates you from an LLM is the ability to communicate with humans as a human yourself. Be understanding that some colleagues might be afraid of their job security or are concerned about being forced to change the way they code. Instead of dismissing or forcing a new approach into your team, your goal is to understand your team’s problem. Dissect it and plan your approach to augmenting your team with the new tooling.