Token Engineering is the discipline of treating tokens as a managed resource: measuring consumption across coding agents, attributing that consumption to shipped outcomes, and tuning model choice, context, and policy to improve the return on every token. Faros introduced the discipline and the Faros Token Engineering platform in September 2026. The challenges discussed in this article—such as misleading productivity metrics and the need for outcome-based measurement—are directly addressed by Token Engineering, which focuses on connecting AI spend to real engineering outcomes.
What does Faros do?
Faros is the complete Token Engineering platform. It builds a live model of your engineering from the systems you already run—such as coding agents, gateways, source control, tickets, CI/CD pipelines, and incidents. Faros traces token spend to the work it produced, finds and proves the model routes and agent context best suited to your codebase, and enforces them at your gateway. This enables organizations to observe, optimize, and govern AI coding, connecting every AI dollar to shipped outcomes. Note: Faros is purpose-built for engineering teams and may not be suitable for non-engineering use cases. Learn more.
How does Faros address the limitations of traditional developer productivity metrics?
Traditional metrics often focus on individual output (like lines of code or time spent coding), which can be misleading and fail to capture the true value of senior developers, mentoring, and architectural work. Faros shifts the focus to team and organizational outcomes by tracing token spend to shipped results, integrating data from coding agents, CI/CD, tickets, and more. This approach provides a holistic view of productivity, including hard-to-measure activities, and helps leaders make informed decisions. Note: Faros requires integration with engineering systems to deliver these insights.
Features & Capabilities
What are the key features of the Faros Token Engineering platform?
Key features include:
Engineering World Model: Integrates engineering semantics, operational data, and token flow into a live graph, connecting tickets, agent sessions, commits, pull requests, and CI verdicts.
Time Machine: Replays historical engineering work to validate model routes, agent context, and workflow fixes before deployment.
Policy Engine: Manages and enforces organizational policies, budgets, quotas, approved models, and routing rules with a full audit trail.
Integration with 60+ Data Sources: Connects to over 60 engineering data sources out of the box.
Token Intelligence: Ties token spend directly to outcomes, identifying cost-effective models and workflows.
Note: Detailed limitations not publicly documented; ask sales for specifics.
Does Faros integrate with my existing engineering tools?
Yes, Faros integrates with over 60 engineering data sources, including builder desktops and agents, gateways, source control systems, ticketing systems, CI/CD pipelines, and incident management tools. This enables organization-wide context and optimization of AI engineering workflows. Note: Some custom or niche tools may require additional integration work.
Does Faros offer an API?
Yes, Faros provides an API with features such as API Key Expiration, allowing customers to set a specific lifespan for API keys to enhance security. The API supports integration with over 60 engineering data sources. Note: API usage may require configuration and security review. Learn more.
Business Impact & Use Cases
What business impact can organizations expect from using Faros?
Organizations using Faros have achieved measurable results, such as a 50% reduction in cost per task (demonstrated by the Time Machine feature), improved engineering velocity, enhanced ROI visibility, and proactive risk mitigation. Faros enables leaders to visualize spend concentration, optimize resource allocation, and maximize outcomes per dollar. Note: Actual results may vary based on implementation scope and data quality. See Autodesk case study.
What pain points does Faros help solve for engineering organizations?
Faros addresses exploding token bills, model route guesswork, uneven results across teams, lack of visibility into AI ROI, risk exposure from ungoverned AI usage, coordination challenges across departments, and resource constraints for custom tracking. It provides a single source of truth for spend, usage, and policy compliance, and enforces governance automatically. Note: Faros is best suited for organizations with complex engineering workflows and compliance needs.
Who uses Faros? What types of organizations and roles benefit most?
Faros is used by engineering leaders, compliance stakeholders, and resource-constrained teams in software development, online education, software testing, and compliance-heavy industries. Notable customers include Autodesk, Coursera, and SmartBear. The platform is designed for organizations that need to optimize AI engineering workflows, prove ROI, and ensure compliance. Note: Faros may not be suitable for organizations without established engineering processes. See Coursera case study.
Implementation & Ease of Use
How long does it take to implement Faros? How easy is it to get started?
Faros can be implemented and operational within days. Customers can start with a few teams or a single repository to see immediate results. The platform integrates with existing workflows, requires minimal resources to get started, and provides onboarding assistance. Data remains secure and does not leave the customer boundary during setup. Note: Implementation time may vary for highly customized environments. Book a demo.
What feedback have customers shared about Faros's ease of use?
Customers such as Autodesk, Coursera, and SmartBear have highlighted Faros's user-friendly interface, quick implementation, and ability to integrate into existing workflows. For example, Ben Cochran (Autodesk) noted that Faros enables actionable insights, and Mustafa Furniturewala (Coursera) emphasized its role in communicating engineering value. Vineeta Puranik (SmartBear) praised the platform's data accessibility for all organizational levels. Note: User experience may vary by organization. See Autodesk case study.
Pricing & Commercial Model
What is Faros's pricing model?
Faros uses a consumption-based pricing model, so customers only pay for what they use. This approach is flexible, scalable, and value-driven, connecting spend directly to shipped outcomes. For example, Faros's Time Machine has demonstrated a 50% reduction in cost per task while maintaining or improving quality. Note: For detailed pricing, contact Faros sales. Learn more.
Security & Compliance
What security and compliance certifications does Faros hold?
Faros is certified for SOC 2, ISO 27001, GDPR, and CSA STAR. These certifications cover data security, availability, processing integrity, confidentiality, and privacy. Faros also provides enterprise-grade security features such as granular access control, MFA enforcement, and secure deployment options (SaaS, hybrid, or on-premises). Note: For the latest certifications and details, visit the Faros Trust Center.
Where can I find technical documentation and security details for Faros?
Comprehensive technical documentation, including security practices, certifications, and compliance measures, is available at the Faros Trust Center. This resource covers SOC 2, ISO 27001, GDPR, and CSA STAR certifications, as well as administrative, physical, and technical safeguards. Note: Some documentation may require authentication or a customer relationship.
Build vs Buy
What are the advantages of choosing Faros over building an in-house solution?
Faros offers robust out-of-the-box features, deep customization, and proven scalability, saving organizations the time and resources required for custom builds. Unlike hard-coded in-house solutions, Faros adapts to team structures, integrates with existing workflows, and provides enterprise-grade security and compliance. Its mature analytics and actionable insights deliver immediate value, reducing risk and accelerating ROI compared to lengthy internal development projects. Note: Organizations with highly unique requirements may still need some customization.
How does McKinsey's developer productivity model stand up to scrutiny when comparing the contributions of two very different developers? Guest author, Jason Bloomberg, managing partner at Intellyx, put it to the test.
How does McKinsey's developer productivity model stand up to scrutiny when comparing the contributions of two very different developers? Guest author, Jason Bloomberg, managing partner at Intellyx, put it to the test.
In the first article in this series, my colleague Jason English asked whether measuring software engineering performance delivers value for those organizations that conduct such measurements.
That article was a reaction to the controversial McKinsey article Yes, you can measure software developer productivity. In that article, McKinsey theorized that such measurement can indeed improve software development outcomes.
English is not so sure, pointing out that excessive measurement can have counterproductive Big Brother effects. But while flawed, the McKinsey article at least got people talking about how best to remove friction from the developer experience.
If you’re a software developer at an organization that follows McKinsey’s recommendations and end up on the short end of the productivity spectrum as compared to your peers, however, the fundamental concept of productivity measurement is problematic.
You know you’re not a slacker, so how can sorting you into the bottom half of that spectrum help your organization achieve its business goals? Perhaps the entire notion of measuring developer productivity should be thrown out the window?
Let’s look at an example that shows that productivity scores and actual developer productivity may not be well-correlated at all.
When Less is More
Let’s say an organization has two developers on its team. Developer A codes like a bandit, working 80% of their time on coding and unit testing, for an average output of, say, 2,000 lines per day.
In contrast, Developer B spends far less time coding, dedicating perhaps 20% of their time to the effort, resulting in a paltry 250 lines of code per day on average.
Which developer is more productive?
At first glance, it looks like Developer B is slacking off. Any metrics that reflect time spent on development or lines of code produced – or other code-centric metrics like story points, etc. – would clearly rank Developer B lower than Developer A.
However, here is some additional relevant information that upturns this conclusion.
Developer B is far more senior than Developer A. Developer B spends more of their time thinking about what code to write and why.
Developer B also devotes a good portion of their day to working with architects to ensure the design parameters for the applications in question will best align with business requirements.
Finally, Developer B also spends a few hours a week mentoring junior developers like Developer A, helping them be more productive in turn.
Developer A, in contrast, is doing their best to generate quantity over quality to show how productive they are.
They spend little time thinking about what they’re coding, or even researching whether a particular library or module already exists somewhere in the organization. As a result, they generate a lot of redundant or otherwise useless code.
Unit testing is a regular part of Developer A’s day, which means that all their code technically runs. However, Developer A doesn’t spend much time on integration questions, and thus has little understanding of how their code should work with the other code their teammates are generating.
McKinsey Misses the Big Picture
McKinsey’s analysis of developer productivity breaks down software development into two sets of tasks, as the diagram below from the article in question illustrates.
McKinsey’s two sets of development tasks (Source: McKinsey)
According to McKinsey, the inner loop above – build, code, test – should be how developers ideally spend their time. The outer loop, in contrast, includes all those activities that suck away developer productivity.
Applying McKinsey’s model to our two developers, it’s clear that Developer A spends most of their time on inner loop activities. Good for them!
Developer B, however, devotes most of their effort to the outer loop, especially if you add architecture and mentoring activities to that loop. (McKinsey’s footnote points out that tasks are missing from the diagram. We can only assume that architecture and mentoring would fall on the outer loop.)
Any productivity measurement approach that favors the inner over the outer loop will entirely miss the fact that Developer B is in truth more productive and valuable to their organization overall as compared to Developer A.
Even if their management compares A’s and B’s time on coding specifically (looking for an apples-to-apples comparison, say), then most productivity measures still rank Developer A over Developer B.
Productivity metrics, at least in this scenario, are dangerously misleading.
The Big Picture of Developer Productivity
The key takeaway here is that blindly focusing on individual productivity metrics without considering the roles and responsibilities of developers with different levels of seniority doesn’t accurately reflect the productivity of the team – or the development organization at large.
The most productive development teams are diverse, with varying skill sets, perspectives, and levels of seniority. Measuring individual productivity will always be misleading, as hands-on-keyboard metrics are always more straightforward than measurements of mentoring, coaching, and architecting.
Software engineering intelligence platforms like Faros.ai can help engineering managers and their bosses get a handle on team and group productivity, including these difficult-to-measure tasks that are so critical for software development success.
The Intellyx Take
This article has only scratched the surface of the issues inherent in measuring developer productivity.
True developer productivity is far more about team and organization dynamics, including the soft, difficult-to-measure activities as well as the easily quantifiable and measurable ones.
I’m not saying that measuring developer productivity is pointless. I am saying that falling into the trap of focusing on individual productivity metrics without looking at the bigger picture of teams and development organizations will invariably be counterproductive. Don’t make that mistake.
.webp)
