Why AI Coding Agents Are Really About Everyone, Not Just Coders

An analyst at a hedge fund turned books on negotiation and deception detection into a working tool that flags when executives hedge on earnings calls, and she never wrote a single line of code.

That outcome sits at the center of a larger argument made by one of the most closely-followed analysts in the AI infrastructure space, someone whose research firm now moves roughly ten times faster than its competitors by applying agent tools to domain expertise rather than to software development. The argument is worth following carefully because it relocates the advantage. The question is no longer whether someone on the team can write code. It is whether anyone on the team understands a domain well enough to describe its logic clearly. Every business has people like that. Most of them have not been handed these tools yet.

The Moment the Reframe Clicked: Agent Means Orchestration, Not Code

The standard way to think about tools like Claude Code, Cursor agent mode, and Codex is as advanced coding assistants: useful if someone on the team writes code, irrelevant if nobody does. That framing is wrong, and the error is expensive for any business that accepts it. These tools are agent orchestration systems. The user describes work in natural language and the agent goes and does it. The output happens to be software code in many cases because software is a useful output, but the underlying mechanism is general-purpose. The agent can produce research summaries, structured data, automated workflows, and analysis tools just as readily as it produces code, because its core capability is following precise instructions expressed in clear language.

The reframe changes who should be using these tools. If they are coding tools, they belong to an engineering team and everyone else waits for features to be built for them. If they are orchestration systems that turn natural language descriptions into working outputs, they belong to anyone in the organization who understands a domain and can describe a desired outcome clearly. That is every senior person in every function, not just engineers. The organizations that have absorbed this insight are pulling ahead of the ones still waiting for their engineering team to build AI capabilities for everyone else.

The clearest evidence of this reframe in practice is an infrastructure lead at a large data center company who had no programming background and now spends several thousand dollars per day on Claude with a million-token context window, building his own internal research and analysis tools. He is not programming. He is describing the outcomes he needs in the language of his domain, and the agent is producing tools that embody those outcomes. The productivity has been documented and it is significant.

The Domain Expert Is the Real Power User

The hedge fund analyst example makes the mechanism most concrete. She spent her career reading earnings call transcripts and developed the ability to recognize specific verbal patterns: the moment an executive hedges a claim rather than affirming it, the shift in language when forward guidance is being quietly walked back, the particular phrasing that signals a non-answer dressed up as a confident reply. That knowledge lived entirely in her professional judgment. It was not written down, not transferable in any practical form, and not available to her team when she was not in the room.

She fed the agent books on negotiation and deception detection. She described the patterns she recognized and explained why each one mattered in an earnings context. She walked the agent through a series of real transcript passages with her commentary on what to flag and why. The agent built a reusable skill from that description. The skill now runs on new transcripts automatically and flags the passages she would have flagged herself, consistently and without requiring her direct involvement each time.

The code she did not write is not the interesting part. The interesting part is that her professional knowledge, the kind that accumulates over a career and usually walks out the door when someone changes jobs, now exists as a tool her entire team can run. She did not need to write a specification document and submit a ticket to an engineering queue. She described what she knew to the agent and the agent built something from it immediately. That compression of the loop from domain knowledge to working tool is what changes the economics of expertise across every industry.

How the Knowledge-to-Skill Loop Works Step by Step

The process of turning domain expertise into an agent skill follows a consistent pattern regardless of the domain. The starting point is identifying the judgment or decision the expert makes, not the process they follow but the outcome they produce. The earnings call analyst does not flag transcripts by running through a checklist. She reads a passage, draws on years of pattern recognition, and identifies the moment where language becomes evasive. That judgment is what gets captured.

The next step is feeding the agent the background material that informs the judgment. In the earnings case, that meant books on conversational deception and negotiation. In a different domain, it might mean a set of internal policy documents, a body of case histories, a regulatory framework, or a collection of industry research the expert has absorbed over years. The agent's job is to learn from that material rather than merely search it.

The third step is walking the agent through annotated examples. Clear cases of the thing to detect or produce, with commentary on why they qualify. Clear cases that look similar but do not qualify, with explanation of the distinction. Edge cases that require judgment, with the expert's reasoning on how to handle them. This annotation phase is where the domain expertise is actually transferred. The agent learns the distinction between a confident forward guidance statement and a hedged one not from a rule but from a series of examples that demonstrate what the distinction looks like in the specific language of the domain.

The fourth step is testing the skill on cases the expert did not use as training examples. Does the skill flag what the expert would flag? Does it miss things she would catch? Does it produce false positives she would dismiss? Each mismatch becomes a new annotated example. After two or three refinement rounds, the skill produces results consistent enough with the expert's judgment to run without constant supervision.

The fifth step is saving the skill and documenting it. The prompt, the background material, and the annotated examples that built the skill should be saved as a named, reusable package so anyone on the team can run it, and so the skill can be refined as the expert's understanding deepens over time. A skill that exists only inside a chat session is a prototype. A skill that is documented and saved is institutional knowledge that compounds.

What Happens When You Add the Production Layer

Prototypes built through this process are valuable and fragile in equal measure. A skill that runs reliably when the domain expert is using it themselves often breaks in subtle ways when it runs without supervision. Inputs arrive in unexpected formats. Edge cases appear that were not in the training examples. Data changes in ways the skill was not designed to handle. These are not failures of the approach. They are the normal gap between a working prototype and a system that runs reliably every day.

The fix is a brief engineering intervention, not a rebuild. One technical person spending roughly ten percent more time on top of a working prototype can add error handling, input validation, logging, and the scheduling or integration work that allows the skill to run automatically in the workflow rather than needing to be triggered manually. That thin production layer turns a useful prototype into a reliable operational tool. The ratio of effort that emerges in practice is roughly ninety parts domain expertise and ten parts engineering infrastructure. That ratio is very different from the traditional software development model, where most effort goes into building features the domain expert could describe but could not produce themselves.

The organizations that get this ratio right scale faster than those that do not. New skills appear as fast as domain experts can describe them. The engineering layer is thin but genuinely necessary. Skipping it produces tools that work sometimes and fail unpredictably, which erodes confidence faster than building slowly would have. Overdoing it produces a queue of engineering tickets that slows domain experts back down to the pace of the engineering team, which cancels the advantage entirely. The right structure is domain experts building continuously and one technical person making the winners production-ready as they appear.

What a Coffee Shop's Version of This Looks Like

A coffee shop owner can run this pattern in a week without any programming background. The right starting point is the decision that consumes the most time and requires the most accumulated knowledge: how much to prepare each morning. The owner knows which pastries sell before nine on rainy Mondays, which specialty drinks spike in the second week of October, which items consistently produce waste on Tuesdays, and which standing corporate orders affect the whole day's inventory balance. That knowledge is applied manually every morning. It is exactly the kind of expertise an agent can learn if the owner describes it clearly.

Feed the agent six months of sales data, the current menu, and the specials calendar. Then describe the patterns that do not appear in the numbers alone: rainy mornings shift demand toward hot drinks and warm pastries. The seasonal latte sells aggressively in its first two weeks and drops back to a steady baseline. Corporate delivery orders on Thursdays require an extra batch of savory items regardless of what the general forecast shows. Walk through five or six specific mornings with commentary on what was prepped, what sold, what was wasted, and what ran short. That annotation is the transfer of expertise.

The resulting skill produces a daily prep sheet from the previous week's sales data plus the day's forecast. The owner reviews it, corrects the occasional misread on a holiday or special event, and feeds each correction back as a new annotated example. After a month, the skill runs with enough accuracy that any shift lead can use it without the owner present.

The numbers make the investment obvious. An illustrative scenario: the shop currently wastes an average of forty dollars per day in unsold pastries and runs short on specialty drinks roughly three days per week. A prep skill that reduces waste by half and eliminates two-thirds of the stock-out days saves roughly twenty dollars per day in waste and recovers perhaps fifteen dollars per day in missed drink sales. That is thirty-five dollars per day in recovered value, over a thousand dollars per month, against an API budget for running the skill that sits well under fifty dollars per month at current pricing.

The reorder alert builds naturally from the same foundation. When the agent is already reading daily sales, a reorder trigger is described in plain English: when bean inventory falls below two days of average usage based on the past week's sales rate, send a notification to the owner's phone. No code. The description is the implementation. Adding a daily scheduler so it runs automatically every morning is the ten-percent engineering layer: an afternoon of work from one technical person. After that, the shop runs its own automated supply management from a skill the owner built by describing what she already knew.

That is the pattern. Domain expertise described clearly, turned into a reusable skill, tested against real outcomes, refined with annotated examples, and hardened with a thin production layer. A business running that loop on one workflow per month builds a compound operational advantage that competitors who have not started cannot replicate quickly. The advantage is not the tool. The advantage is the domain knowledge already inside the business, finally converted into something that runs.