Oracle Put Fusion AI Development in VS Code and Made It Work With Coding Assistants

Oracle Put Fusion AI Development in VS Code and Made It Work With Coding Assistants

A public repo, a CLI, a VS Code extension, and a testing framework almost nobody is talking about.

I have spent years asking Oracle product teams to meet developers where they already work and different platform teams have made great strides in this area over the years with varying degrees of success.

However, I want to be direct about this one: what the Fusion AI team has shipped in a short spawn of time around this theme, I think deserves more attention than it is getting.

There is a public GitHub repository at github.com/oracle/fusion-ai-studio. It contains skills, a CLI, a VS Code extension, Oracle-authored sample applications and workflows, and how-to guides. It is published under the Universal Permissive License and updated regularly.

What is actually in it

·        A skills directory that coding assistants can read

·        An aiapps directory with Oracle-authored template applications and workflows

·        The VS Code extension and CLI

·        A how-to folder covering installation and incremental updates

Sample apps span HCM, including career development, journeys, learning, absences, and succession management, along with supply chain areas like inventory and cost management, and procurement content covering purchase orders and agreements.

The repository moved to release-based branching, with release-26C as the current branch and a dedicated branch planned for each future release. Before that change you downloaded ZIP files, extracted them, and placed the contents into the right directories yourself. Now you clone the branch matching your release and pull updates.

That is a small change, but it tells you something about how the team is thinking. Somebody looked at how people actually consume this and removed the friction.

It works with coding assistants

The VS Code extension provides guided commands and visual editing for setting up a workspace, connecting to the right environment, and creating or opening artifacts. The how-to guide walks through using it alongside Codex.

Oracle's product management team also described pointing Claude Code at a workspace directory. There is a CLAUDE.md in the repo, and the assistant reads the skills and works with Agent Studio from that context.

The reason this matters is not novelty. It is that describing a business outcome and having an assistant apply the change across workflows, business objects, agents, and supporting artifacts is a fundamentally different working mode than opening and editing each file in turn. Anyone who has built a moderately complex agent knows how many artifacts a single change can touch.

The builder assistant

In 26C, Agent Studio gained a natural language interface for describing what you want and generating the workflow agents, the business object definitions, and the agentic app itself.

Two things about it are worth calling out. The first is cost. Oracle's product management team told us the builder assistant does not consume AI units, on the basis that you are instructing it rather than running inference against your business data. I have not been able to find that stated anywhere in Oracle's public documentation, so I would treat it as reported rather than confirmed, and check it against your own environment before you build an assumption on it. The second is that it works in reverse. You can point it at an existing workflow, including one Oracle delivered, and ask it to explain what the thing does and why. If you have ever inherited a complicated workflow with no documentation, you already understand the value.

ATLAS is the part people are sleeping on

Sitting in the repository change log is a framework called ATLAS, the Agentic Testing and Lifecycle Automation Suite. It landed in early August and I have seen almost no discussion of it anywhere.

Consider the problem it addresses. You deploy agents. Models change. Providers deprecate versions and release new ones. How do you swap models across a fleet of agents and know with any confidence that everything still behaves the way it should?

ATLAS turns agent scenarios into repeatable, executable tests. Each test combines an input, expected workflow behavior, representative replay data, and evaluation criteria. It validates structurally, confirming required or prohibited execution paths, and semantically, for natural language responses where exact text matching would be too rigid.

The capabilities I find most interesting:

·        File-based replay holds external service boundaries stable while routing, conditions, code, and LLM nodes continue to execute. That makes regressions reproducible rather than dependent on whatever the source system happened to return that day.

·        Labeled runs let you compare a baseline against a candidate model using consistent evidence.

·        Optimization sweeps evaluate model placement at the individual LLM node level, using quality, latency, and usage data. Rather than picking one model for an entire agent, you work out which specific node needs the stronger one.

·        It integrates with local development and CI/CD, producing reports covering results, evaluated outputs, warnings, token usage, and execution duration.

Connect that last point back to cost and it becomes more interesting still. Node-level model evaluation is the mechanism for answering the question I keep raising internally: which parts of a workflow actually justify a premium model? ATLAS replaces intuition with evidence, and evidence is what a finance conversation requires.

Where this is heading

Oracle's product team described the next phase as fleet management and governance. Once an organization has hundreds of agents deployed, the questions change. It stops being how do I build one and becomes how do I understand what they are all doing, whether any of them are misbehaving, and how I make wholesale changes safely.

The CLI investment is aimed at that broader lifecycle rather than only the build step. Designing, reasoning about which agents make sense for a given business problem, then evaluating and maintaining them once they exist.

A few honest caveats

·        The repository does not accept external pull requests. You can consume it, not contribute to it.

·        The samples carry a broad disclaimer and no warranty. Treat them as examples to learn from rather than production code to deploy as-is.

·        The documented assistant path is most complete for Codex. Other assistants work, but expect to do some of your own figuring.

None of that changes my overall read. An Oracle SaaS product team publishing a public repository, shipping a VS Code extension, supporting third-party coding assistants, and building a testing framework for agent lifecycle management represents a real shift in posture. I would like to see it spread to other Oracle products on the Low Code front with more vigor (such as OIC and VBCS), and I have said so to anyone at Oracle who will listen and I know the teams are working on it!

Where to start

If you work with Fusion AI and have not cloned the repository yet, start there and begin with the how-to folder. Reading Oracle's own sample workflows taught me more about the intended patterns than any presentation I have sat through.

Based on a working session between our team and Oracle's Fusion AI product management group in August 2026, combined with Oracle's public documentation and sample repository. Product details and pricing mechanics change between releases. Confirm specifics against your own environment, rate card, and Oracle account team. Views are my own.