In December 2025, Stack Overflow published its annual survey of more than 49,000 developers worldwide. The headline number: 80% of them now use AI tools at work, a sharp jump from the year before. A month earlier, GitHub's Octoverse report had shown another angle on the same phenomenon — nearly 80% of new developers signing up on the platform already use an AI assistant within their first week.
JetBrains' survey, with more than 24,000 developers across 194 countries, lands on a similar number from the angle of ongoing use: 85% of developers use AI regularly at work, and 62% rely on at least one AI coding assistant, agent, or editor with built-in AI to complete tasks, review snippets, generate tests, or write documentation.
Few software categories have climbed an adoption curve this fast within one specific technical audience. And that is exactly the point of this piece: a specific audience. These tools were designed, tested, and tuned for someone who already knows how to code, already lives inside a terminal and version control, and already understands what it means to review a piece of code before accepting it. When the same tool reaches the desk of someone in finance, HR, or sales, it carries assumptions that stop holding.
Where these tools genuinely shine
AI coding assistants were built on a simple assumption: whoever is on the other end knows how to program. Completing a function, suggesting a test, refactoring a snippet, explaining a compiler error — each of these uses, listed by JetBrains' own survey among the most common, assumes the person can read the result, notice when it is wrong, and correct course.
That is a task developers have done for decades while reviewing a colleague's code. AI arrives as an accelerator for judgment the person already had before the tool existed — which explains why adoption moved so fast: the product fit exactly into an existing routine, inside the programming environment the person already used, without requiring a change of tool or vocabulary.
Stack Overflow's own trust data confirms that fit, if indirectly. Only 29% of developers fully trust the accuracy of what AI produces — a sharp drop from the year before — and 66% report spending more time reviewing AI-generated code than they expected. That is not the tool failing. It is the professional applying exactly the technical skepticism their job demands. Seventy-five percent said that, when in doubt, they would rather turn to another person than trust the AI's answer.
Why the same tool stumbles outside code
That trained skepticism is the first piece missing once the tool leaves the technical team. Someone in finance who gets an answer about a contract clause does not have the same instinct to doubt a number that "looks right but isn't" — because they never had to train that instinct. The issue is not that this person is less capable. It is that the tool was designed assuming a kind of review only people who code every day practice.
The second missing piece is structural, and it explains why this is a matter of architecture, not of team personality. These tools typically ask for a personal account, set up by whoever installed the program on their own machine — often paid for with a personal or corporate card, outside the company's identity controls. When that person changes teams or leaves the company, access is not revoked automatically along with everything else: someone has to remember to cancel that one specific account.
The third piece is the absence of role and approval. The tool does not know, and does not need to know, whether the person on the other end is an intern or the CFO — because it was built for a scenario where that does not matter: code goes through a colleague's review and an approval process before reaching production. Outside of code, that second reviewer does not exist by default. And there is no central record IT or compliance can consult afterward, because the conversation happened inside a tool the company never even knew was in use.
None of this is a flaw in the product. It is the right product, built for the right audience, reaching a different audience than the one it was designed for.
What has to be in place
Bringing AI to the whole company — not just to whoever codes — requires a different design, verifiable in five points.
Corporate identity, not a personal account set up on the spot. Access comes from the same directory that already controls email and internal systems, so offboarding and role changes update AI access along with everything else, without depending on someone remembering a standalone account.
Access based on each person's role. Finance sees what finance needs; sales sees what sales needs — without requiring anyone to understand a developer's concept of permissions to work safely.
Approval before a sensitive action. When a request involves something with real impact — sending a message, changing a record, approving a value — the flow pauses and asks a person to confirm, right inside the conversation, instead of assuming whoever is there knows how to review it the way a developer would.
The company's own approved knowledge. Answers draw from documents, policies, and processes with an owner and a current version — not from the general internet knowledge any assistant ships with out of the box.
A central audit trail. Who asked what, when, and with what result stays recorded in one place IT can review — not scattered across personal accounts the company does not even know exist.
This is how Skyller was designed: identity from the company directory, permission by role, approval and logging as the default for any department — not just for people who already know how to code.
Where each tool belongs
None of this makes agentic coding tools worse at what they do. An assistant tuned to read an entire repository, suggest a refactor, or generate a test remains, for whoever codes, the right tool — and will keep being the right tool as long as there is code to write. The mistake is one of fit: taking a tool designed and tested for that specific audience and offering it, unchanged, to the rest of the company, expecting the same adoption curve and the same technical judgment to appear on their own in people who never needed them before.
A platform built for the whole company solves the problem from the other side: it already ships with identity, role, approval, and audit built in, plus ready-made agents by department — Skyller, for instance, already comes with more than 100 pre-configured agents for finance, HR, sales, and other routines — instead of asking every department to reinvent, without support, what the technical team spent years learning to do safely.
Questions for your next IT meeting
Before rolling out to the rest of the company a tool that today only the technical team uses, these questions are worth asking:
- Who outside the technical team already uses AI on their own, with a personal account and without the company's knowledge? If the answer is "we don't know," the first step is finding out — not banning it.
- If that person left tomorrow, would their access to these tools drop along with everything else? If the answer depends on someone remembering to cancel a standalone account, the problem is identity, not the tool.
- Is there a central place where IT can see what was asked and with what result? If the answer is no, the company is exposed to a risk it cannot even measure.
- Is the tool the technical team loves the same one that should reach finance, HR, and sales? The answer is almost always no — and that is fine. These are different problems, and each deserves the right tool.
