The principal engineer’s reaction to Larridin’s more accurate cost attribution was measured: “That’s one plus.” Then: “I imagine it’s a small part of what would be interesting in all this.” The bigger question was what distinguishes two engineers using the same tools — and what the rest of the team could learn from the stronger performer.
In the Larridin demo, the principal engineer said they already extract AI cost data with API calls and Python scripts.
That can be useful for a focused reporting need. Depending on what each provider exposes, internal scripts can give engineering teams detailed usage and cost data without adding another platform simply to answer “What did we spend?”
That works until leaders want to know more than what they spent.
Cost data can show what AI activity consumed. It can’t explain why two engineers using the same tools are getting different results or what the rest of the team could learn from the stronger performer.
That was the question the principal engineer actually cared about.
Two engineers can use the same AI tool and generate similar spend without using it equally effectively. Cost data alone won’t show why their results differ. That requires looking at how each engineer is actually using AI in the work.
Larridin’s AI Fluency capability measures how well teams use AI and helps organizations identify stronger adoption and fluency patterns. For engineering organizations, the goal is to put AI usage in enough context to see where stronger practices are developing.
Cost is only one part of the picture. Leaders also need to see whether AI use is showing up in engineering results.
Larridin’s Developer Productivity platform connects to the development toolchain and measures AI alongside velocity, quality, workflow performance, cost, and ROI. That gives engineering leaders a way to compare AI activity with what teams are actually shipping. That comparison doesn’t show that AI use caused the engineering result, but it gives leaders a way to investigate the relationship instead of looking at each dataset separately.
The principal engineer’s question was specific: find a high performer, compare that person with a peer using the same tooling, and ask what’s different. That requires more context than a cost total. The comparison needs to show enough about AI effectiveness and engineering outcomes to identify patterns worth investigating.
Larridin’s developer platform includes personal AI effectiveness, peer benchmarking, and team-level diagnostics. Those comparisons can help engineering leaders see where stronger patterns are emerging and decide which ones are worth testing more broadly.
“Golden nuggets” is how the principal engineer described what they wanted to find.
The idea is straightforward: identify someone getting strong results from AI, compare that person with a peer on the same tooling, and look for meaningful differences that could help the broader team. Cost tracking can show what was spent. The comparison asks what stronger AI use looks like in practice.
The measurement does not have to declare that one behavior caused better performance. Its job is to make the differences visible enough to investigate. Engineering leaders can then decide whether a pattern is worth turning into coaching, workflow guidance, peer mentoring, or a practice the team should test more broadly.
Larridin’s AI Fluency capability similarly helps organizations identify power teams and use their expertise to support other teams. The engineering version of that idea is exactly what the principal engineer was getting at: find what’s working and help other teams learn from it.
A homegrown script doesn’t become useless if the organization adds a measurement platform.
If the scripts answer a stable internal need, they may keep doing that job. The reason to add a purpose-built layer is that leadership wants to answer questions the cost data could never answer, such as
That’s where the decision moves beyond whether engineering can pull the data itself. The question becomes whether the organization can turn the data into repeatable insight without building every new analysis from scratch.
Usage and cost logs show what AI activity occurred and what it consumed. Proficiency measurement adds context about how effectively AI is being used. Engineering measurement can then put those signals alongside delivery, quality, and other outcomes.
Yes. Internal scripts may still serve useful reporting, integration, or workflow needs. A purpose-built platform becomes useful when leaders need broader comparisons across AI usage, proficiency, cost, and engineering outcomes.
The useful comparison is whether differences in AI effectiveness appear alongside differences in engineering outcomes, and which patterns are worth investigating or sharing with the team.
There isn’t a fixed minimum team size. It becomes useful once you have enough engineers using the same or similar AI tools to make meaningful comparisons across people or teams.
Larridin helps engineering leaders put AI cost and usage alongside proficiency, delivery, and quality so they can see what stronger AI use looks like and where those practices may be worth adopting more broadly.
Book a discovery call to see how Larridin adds context to the AI cost data your engineering team already collects.