AI coding observability is the practice of measuring how engineering teams use AI coding tools — including adoption, cost, model usage, reliability and plan utilization — without inspecting developers’ source code or work activity.
That last part matters.
When I say observability, I do not mean recording every prompt, reading code or producing a leaderboard of which developer used the most tokens. I mean answering much more basic questions:
- What tools are we paying for?
- Are people using them?
- Which models do they depend on?
- What keeps failing?
- Are we buying capacity we do not need?
- Are local models becoming more favourable for teams
Most companies cannot answer these questions today.
That is strange when you consider how quickly tools like Cursor, Claude Code, GitHub Copilot and Codex have moved from experiments into the everyday development environment.
AI coding became infrastructure before most organizations realized they owned infrastructure.
Nobody planned the AI coding stack
Very few companies deliberately designed their current AI coding setup.
One developer started paying for Cursor. Another preferred Claude Code. A team bought Copilot seats through GitHub. Someone connected an API key to Cline or Continue. A few engineers began running open models locally.
Each choice was reasonable on its own.
Together, they created an unplanned stack of tools, models, subscriptions and accounts.
Finance can see the invoices, but an invoice does not tell you whether a tool is useful. Engineering managers know what their teams say they use, but that does not show how usage changes over time. Vendor dashboards provide some answers, but only from inside their own products.
Cursor knows about Cursor. GitHub knows about Copilot. Anthropic knows about traffic reaching Anthropic.
The organization is left assembling the wider picture manually.
This is the gap we are building UseJunction to close: one observability layer across the AI coding tools an engineering team already uses.
The problem is larger than seat waste
Unused seats are the most obvious problem because they are easy to put into a spreadsheet.
If a company purchased 100 seats and only 43 are active, someone can cancel the rest before renewal. Useful — but not particularly deep.
The more interesting question is what is happening across those 43 active users.
Perhaps a developer has an allocated Cursor seat but does most of their work through Claude Code. Another might regularly exhaust their included plan usage and quietly switch to an API key. A third might prefer a local model for a particular repository.
A vendor dashboard can make one product appear underused while the developer is actually a heavy AI user elsewhere.
That is why AI coding observability needs to cover more than licenses. At minimum, it should help an organization understand five things:
- Adoption: which tools are genuinely part of the development workflow
- Cost: subscription, API and infrastructure spending in one place
- Model usage: which models are being used across different tools
- Reliability: latency, errors, rate limits and failed requests
- Plan utilization: whether paid allowances are exhausted, balanced or wasted
These measurements are related.
A drop in usage may be an adoption problem. It may also mean a tool became slow, a plan reached its limit or developers found a better model somewhere else. Looking at one metric — or one vendor — can give you the wrong explanation.
A gateway is not always the right first move
The standard enterprise response to a fragmented stack is centralization.
Route every request through one gateway. Decide which models are allowed. Block everything else. Put policy in front of the problem.
There are situations where that is necessary. If source code is being sent somewhere it should not be, the company cannot wait six months for a beautiful analytics dashboard.
But I do not think a gateway should be the automatic starting point.
A gateway changes how developers work before the organization properly understands how they work. It can introduce latency, break features that depend on a vendor’s native API and turn the platform team into the owner of another critical service.
Worse, a badly designed control layer can push usage out of sight. Developers do not stop wanting a useful tool because it disappeared from the approved list. They find another account, another API key or another route.
Before inserting control into every request, I would want to know:
Which workflows are important enough to protect? Which tools are redundant? Where is sensitive data actually going? What would break if we standardized too early?
You need evidence to answer those questions.
That is what I mean by visibility before control. It is not an argument against governance. It is an argument against governing an environment you have not yet mapped.
Observe the infrastructure, not the developer
There is a dangerous version of this product category.
Take AI usage data, attach it to individuals and pretend it measures engineering productivity.
It does not.
One developer making 500 requests is not necessarily more productive than someone making 20. They may be asking the model to repair poor generations. They may be exploring an unfamiliar codebase. They may simply work differently.
The same problem already exists with commit counts and lines of code. AI gives companies even more activity data to misuse.
UseJunction is being designed around a simpler boundary: collect the operational information needed to understand the AI system, without turning it into surveillance.
That means looking at information such as the tool, model, request status, latency and plan consumption. It does not require reading the developer’s source code or capturing the contents of every conversation.
There will always be pressure to collect more because more data looks useful on a product roadmap. I think restraint is part of building this category correctly.
If developers believe observability is secretly performance monitoring, they will avoid it. And they will be right to.
Why I ended up working on this
Before UseJunction, I built Tallei around a different version of the same fragmentation problem.
People were working across ChatGPT, Claude and other assistants, repeatedly moving context between them. The interesting part was not any single assistant. It was the behaviour across them: where information came from, what people repeatedly explained and how work moved between tools.
AI coding has the same structural problem.
The developer’s workflow does not belong to Cursor, Anthropic, OpenAI or GitHub. It runs across them.
Yet almost every dashboard is designed as if its vendor represents the whole environment.
That mismatch is what pulled me toward UseJunction.
We are starting with observability because I do not think the first version should try to become the company’s AI police, universal router and procurement system at the same time.
The first job is simpler: show engineering and platform teams what is actually happening.
UseJunction is being built as an open-source, self-hostable system because some organizations will reasonably refuse to send this data to another external SaaS product. Even operational metadata can reveal meaningful information about engineering activity. Teams should be able to decide where that data lives.
What UseJunction should tell you
Imagine renewal season is approaching.
You have Cursor, Copilot and Claude subscriptions spread across several teams. Some developers also use Codex, Cline, Continue or local models. Finance wants to know what can be cancelled. Engineering does not want a cost-cutting exercise to remove tools people genuinely depend on.
Today, this usually turns into a combination of vendor exports, surveys and guesswork.
UseJunction should let you see the environment as one system:
- Which tools are active?
- Which plans are approaching their limits?
- Where are paid seats sitting unused?
- Which teams are seeing failures?
- Are developers moving to another model when one becomes unreliable?
- Are local models becoming a meaningful part of the stack?
The answer may be that the company should standardize.
It may also be that different teams genuinely need different tools.
Observability should not begin with a preferred conclusion. Its job is to make the trade-offs visible.
Start with the boring questions
A company does not need an elaborate AI governance programme to begin.
Start with the questions that should already have answers:
- How many AI coding products are we paying for?
- Who has access?
- Which ones have been active recently?
- What portion of each plan is being consumed?
- Are API costs growing outside the subscription budget?
- Which services are regularly slow or unavailable?
Then define what you will not collect.
That second step is easy to ignore, but it matters. If the system does not need source code or prompt contents to answer an operational question, do not collect them by default.
Once the environment is visible, decisions become less theatrical.
You can cancel genuinely unused seats. Increase capacity where developers repeatedly hit limits. Investigate unreliable providers. Decide whether a central gateway would solve a real problem. Introduce policies around specific risks instead of applying one broad restriction to every team.
The point is not another dashboard
The world does not need a prettier collection of token charts.
The useful outcome is being able to make decisions about AI coding infrastructure without relying on vendor claims, employee surveys or whoever has the strongest opinion in the meeting.
That is the product we are trying to build with UseJunction: an open-source observability layer for AI coding tools, models and plans.
The product begins with visibility. Over time, that visibility may support routing, configuration and policy controls. But those controls should be built on evidence from the real environment — not assumptions about how developers are supposed to work.
If your company already uses several AI coding tools, you already have an AI coding stack.
The only question is whether you can see it.
P.S. You can self host it too: Github Repo
Visibility before control
See your AI coding stack as one system.
Run UseJunction on infrastructure you control, or start with the managed control plane.
About the author
Dinuda is building UseJunction, an open-source observability layer for the AI coding tools, models, and plans engineering teams already use. His work focuses on making fragmented AI systems visible without turning operational data into developer surveillance.