It’s February 2026, and if you spend any time on X.com, you might get the impression that software engineering is dead. My feed is full of people who used to write code now running experiments with Claude Code and other AI tools.
The vibe is clear: coding is solved. Time to move on.
Funny. Because every day I talk to software engineers working on one of the least glamorous problems in our industry: building the systems that turn what we ship into revenue. Pricing. Metering. Entitlements. Billing. The stuff that breaks and leaks revenue, like an enterprise customer abusing their limits for years without anyone noticing.
For years, we called these people billing engineers. Revenue engineers. Monetization engineers. But something bigger has been happening. The pace of shipping has accelerated. Business models evolve faster. Pricing needs to adapt continuously. It is not just billing anymore. It is a full financial infrastructure problem. Companies like OpenAI and Anthropic recognized this and built dedicated teams around it. That is not a coincidence.
They are investing because the gap between “we ship AI features” and “we know how to make money from them reliably” is getting wider, not narrower. Most companies still do not have a clear owner for that gap. That needs to change.
Let’s explore this emerging discipline, what it means, why it matters, and how to build it from the ground up.
Here’s a take that might be uncomfortable: AI coding agents are not making engineers more productive. They are making certain kinds of engineering work worthless.
Think about what Cursor, Claude Code, and GitHub Copilot actually commoditize. Writing a REST API. Setting up a database schema. Building a CRUD service. Scaffolding a React app. This stuff used to take days. Now it takes minutes. And it’s getting faster every day.
The industry response has been to celebrate “the generalist engineer.” Someone who can do a bit of everything. Frontend, backend, infrastructure, a little ML. Jack of all trades.
But I think that framing misses the point entirely.
If an AI agent can write your backend in an afternoon, what’s left for the human? The answer isn’t “more backend.” It’s knowing what the backend should do and why. The real scarcity isn’t coding ability. It’s domain knowledge. Understanding the problem space deeply enough to know which system to build, what tradeoffs matter, and how the technical decisions connect to business outcomes.
The industry is calling these people “generalists.” I think that’s the wrong word. They’re actually domain experts who happen to be fluent in code. They’re T-shaped: broad enough in technology to use any tool, deep enough in one domain to know what to build with it.
And the domains are splitting fast. Security engineering. Data engineering. ML platform engineering. Developer experience engineering. Each one requires years of accumulated judgment that no coding agent can replicate. Because the hard part was never writing the code. The hard part was knowing what to write.
The most valuable engineers I work with today are not the ones with the prettiest GitHub profiles. They’re the ones who understand entitlements, metering, pricing models, revenue recognition, credit systems, and usage governance. They’re the ones who can sit in a room with finance, RevOps, and product and actually hold the conversation.
They’re Financial Engineers. And the market desperately needs more of them.
Know other Financial Engineers that might benefit from reading it?
I see four forces converging that make this domain uniquely critical right now.
Traditional SaaS had near-zero marginal cost. Once you built the feature, serving it to 100 customers or 100,000 customers cost roughly the same. Pricing was mostly about packaging and positioning.
AI broke that model completely.
Every API call to a language model costs money. Every token processed has a price tag. When your product runs Claude or GPT under the hood, your COGS moves with every single customer interaction. A heavy user doesn’t just consume more server time. They consume real dollars in model inference costs.
This means engineering decisions now directly impact gross margin. How you batch requests, which model you route to, how you cache responses, whether you let a user retry five times or once. These are not just performance questions. They are financial questions.
And the engineer who builds the system needs to understand both sides.
A new model drops and your cost-per-query halves. Or doubles. A provider changes their pricing tier and suddenly your margins look completely different. Your customers discover that agents make ten times more API calls than humans do, and your carefully designed credit system is underwater.
This isn’t a one-time migration. It’s constant. Every model change ripples through your entire monetization stack. New costs mean new metering requirements. New metering means new entitlement boundaries. New entitlements mean new pricing. New pricing means new billing logic. And all of it needs to ship before the old numbers stop making sense.
The engineering team that hardcoded plan === 'pro' into fifty microservices six months ago? They’re now spending an entire quarter untangling that decision. I’ve seen this happen at companies of every size. It never gets easier. It only gets more expensive.
Your monetization infrastructure needs to move as fast as the models themselves. That requires engineers who understand cost structures, metering, entitlements, pricing, and billing as one connected system. Not five separate tickets across five separate teams.
Here’s the irony. You’re shipping products powered by models that are approaching AGI. And you’re depending on NetSuite to manage your quotas and billing. NetSuite is 25 years old.
The moving parts of monetization infrastructure are enormous. Entitlements. Metering. Pricing catalogs. Subscription management. Usage governance. Billing. Revenue recognition. CRM sync. CPQ. Data warehouse integration. Each of these systems needs to stay in sync, in real time, across every customer and every plan.
Most of these systems were designed for a world of fixed seats and annual contracts. They work fine when pricing changes once a quarter. They break when your AI product needs to update pricing weekly, launch a new credit model mid-month, or enforce real-time usage limits that didn’t exist last Tuesday.
The first two forces move at the speed of AI. Your monetization infrastructure moves at the speed of enterprise software procurement cycles. That gap is where revenue leaks, billing errors, and customer trust issues live. Someone needs to bridge it.
Three years ago, a typical SaaS customer had a relatively flat usage pattern. An admin bought seats. Users used features. The pricing model mapped cleanly to how the organization actually worked.
AI products broke that too.
Think about an admin managing an Anthropic or Clay account inside a large enterprise with multiple departments. They’re now dealing with two fundamentally different cost structures at the same time. Usage-based costs for API calls, tokens, and credits. And profile-based costs for seats and licenses. Each has different limitations, different pricing mechanics, and different ways users map to spend.
API keys might be correlated to individual accounts or to an organizational master account. Departments need separate budgets. Teams need visibility into their own consumption. Finance needs to allocate costs across business units. And the admin sitting in the middle needs to make sense of all of it.
Every AI-native company is heading toward the same place: they need to build something like AWS Cost Explorer for their own customers. A way for enterprise buyers to see, understand, and control what they’re spending across usage dimensions that didn’t exist two years ago.
This is not a reporting feature. It’s a core infrastructure problem. And it’s one more reason the Financial Engineer role exists.
Here’s something most people haven’t noticed yet.
OpenAI appointed Sara Conlon as Head of Financial Engineering. She built an entire organization around it, organized into four dedicated pods: Pricing & Packaging, Monetization Infrastructure, Financial Automation, and Payments. At OpenAI, financial engineering is not a side project. It’s a core platform function.
Anthropic hired Shan Alagumuthu to lead their Billing Platform team. He came from six years leading Payments and Billing engineering at Turo.
When OpenAI and Anthropic both decide they need dedicated engineering leadership for monetization, it tells you something about where the industry is heading. The companies generating billions in revenue from AI have figured out that this is a first-class engineering discipline. Not a billing vendor problem. Not a finance spreadsheet problem. An engineering problem.
Snowflake, Figma, Gitlab, and Twilio each employ dozens of engineers on internal billing infrastructure. Most companies can’t afford that. But every company shipping AI features needs someone who understands this domain deeply.
That’s the gap this newsletter exists to fill.
Let me be concrete. A Financial Engineer is not a finance person who learned Python. And it’s not a backend engineer who got stuck maintaining the billing code nobody else wanted to touch.
A Financial Engineer is someone who owns the full lifecycle of how software turns into revenue. From the moment a customer signs up to the moment an invoice gets paid. And everything that can go wrong in between.
Here’s what that actually covers:
Entitlements and access control. What is each customer allowed to do, based on their plan, contract, and current usage? This sounds simple until you have 200 enterprise customers on 47 different plan versions with custom overrides on half of them. I wrote my first deep dive on entitlements years ago and it’s still the most common problem I see teams struggle with. It will be the topic of next week’s post.
Metering and usage infrastructure. Tracking consumption in real time, at scale, with enough accuracy that finance trusts the numbers and enough speed that your product can make enforcement decisions in milliseconds. This is harder than most people think. A metering system that’s off by 2% can mean hundreds of thousands of dollars in revenue leakage per year.
Pricing model architecture. Designing systems that can support subscriptions, usage-based billing, credits, prepaid commitments, and hybrid models. Ideally without rewriting everything when the business decides to change direction next quarter. The architecture choices you make here either give your company speed or take it away for years.
Billing integration and revenue recognition. Making sure what your product tracks actually lines up with what your billing system charges and what your finance team reports. Credits that look correct in your dashboard but don’t match what Stripe invoiced are a special kind of nightmare that usually surfaces during an audit.
AI usage governance. The newest and fastest-growing piece. Controlling who can consume what, with what limits, in real time. Especially when “who” is increasingly an AI agent, not a human clicking buttons. Enterprise customers don’t just want to know what they spent. They want to control what gets spent before it happens.
These are not five separate jobs. They’re one discipline. And right now, most companies either don’t have anyone who owns all of it, or they have it scattered across six teams with no coordination.
I’m starting The Financial Engineer as a weekly technical deep dive into everything I just described. Every week, I’ll cover one topic in depth. Real code. Real architecture decisions. Real patterns from real companies.
This is not a Stigg product blog. I won’t be selling you anything here. My expertise comes from working with hunderds of companies as CTO of Stigg, and I’ll reference that work when it’s relevant. But the goal of this newsletter is to build the knowledge base that this emerging discipline needs.
If you’re a senior engineer or staff engineer who owns billing, pricing, or monetization infrastructure at a SaaS or AI company, this is for you.
If you’re a VP or CTO trying to figure out whether you need to invest in this area (you do), this is for you.
If you’ve ever picked up a Jira ticket that says “add new usage limit to Pro plan” and discovered it took way longer than anybody appreciated, this is definitely for you.
Topics I’ll be covering (not an exhaustive list):
Entitlements: the one thing nobody gets right early, and everybody pays for later (next week’s post)
Building credit systems for AI products and why it’s harder than you expect
Usage governance at enterprise scale: limits, allocations, and budgets
Why your billing system is not your monetization system
Metering infrastructure that doesn’t lie
The real cost of building monetization in-house
Pricing model migrations without burning the house down
What happens when your customer is an AI agent
I’m writing the newsletter I wish existed when I started working in this space. I hope it becomes the resource that helps financial engineers everywhere do their best work.
Subscribe, and let’s build this discipline together.
— Anton