A lot of Foundry teams now have access to AI FDE.
That does not mean they are getting much out of it.
The teams that get real leverage from it are usually not the teams prompting it all day. They are the teams that know when to use it, how much context to give it, and where it is already strong.
That matters because AI FDE is already useful in real work. In our own material, it shows up in transform work, ontology engineering, OSDK React scaffolding, and persistent iterative sessions. We have even documented a production Foundry app shipped in 6 weeks with AI FDE in the loop.
So the gap is no longer access. It is operating discipline.
The real promise is not generic code generation. It is platform-aware execution across repositories, ontology resources, and application logic.
The Gap Is Not Access
The problem is rarely that teams do not have AI FDE available.
The problem is that many still treat it like a better autocomplete layer instead of a different way to work on the platform.
That leads to a familiar pattern:
- teams ask it for isolated tasks instead of structured workflows,
- they overload it with context and burn tokens too early,
- they use it for flashy generation before they understand where it is genuinely strongest,
- they evaluate it on poor prompting habits and conclude the tool is inconsistent.
This is not really an AI FDE problem. It is a usage maturity problem.
Where AI FDE Is Already Strong
The strongest use cases are not evenly distributed across the platform.
Teams get better outcomes when they stop expecting one uniform magic trick and start using the tool where it already has clear leverage.
Today, the most compelling patterns are:
- transform work in code repositories,
- ontology creation and editing,
- ontology functions,
- OSDK React application scaffolding,
- plan generation before execution,
- persistent iterative sessions.
That is already a serious footprint. It touches data engineering, ontology work, application development, and delivery speed.
What makes AI FDE different is that it can operate inside the logic of the platform rather than outside it. It understands the environment it is acting in.
In our recent material, one capability stands out repeatedly: zero-shot ontology function creation already works unusually well. That is the kind of detail that separates platform-native leverage from generic code generation.
Where Teams Still Get Burned
The hype around AI-assisted development makes it easy to ignore the failure modes.
They are real, and they usually come from poor operating discipline rather than from some abstract weakness of the model.
The first issue is context overload. Teams attach too much material, too many repos, too many documents, and then wonder why the conversation gets expensive and fuzzy.
The second is weak prompting in OSDK React work. If the task is framed badly, the tool may generate application code that over-queries the Ontology and drives unnecessary cost into the system.
The third is workflow confusion. Teams use AI FDE for tasks that are better handled by something else, then judge it as if the tool failed.
These are not small details. They decide whether AI FDE becomes a force multiplier or just an expensive novelty.
The Most Important Mindset Shift
The best teams do not ask, "Can AI FDE do this?"
They ask, "What is the right handoff between human judgment, local iteration, and platform-aware execution?"
That is a better frame because AI FDE works best when it is part of a development system.
A practical pattern looks like this:
- iterate quickly on local UI or isolated code where speed matters most,
- move into AI FDE when platform context and ontology awareness become critical,
- shift back out when local refinement is faster,
- use AI FDE again when the work needs to touch live Foundry structure.
This is less glamorous than the fantasy of one prompt doing everything. It is also much closer to how serious teams actually ship.
The point is leverage: what used to take months of accumulated platform fluency can be compressed when teams learn how to use AI FDE deliberately.
Why Ontology Awareness Changes the Equation
This is the part many non-Foundry teams miss.
The value of AI FDE is not just that it writes code. The value is that it can act inside a system where data models, application logic, and business semantics are connected.
That makes certain tasks unusually powerful: creating ontology functions, updating object relationships, scaffolding apps that depend on ontology structure, generating plans before touching a branch, and keeping work reviewable through branch-based changes.
This is the real reason AI FDE matters strategically. It shortens the distance between platform knowledge and implementation.
Why Training Still Matters
It is tempting to think a tool like this reduces the need for enablement.
In reality, it raises the need for better enablement.
That is why our own training material does not position AI FDE as magic. It is structured as 5 focused days, use-case anchored, and explicitly aimed at the teams where 1-3 engineers are doing everything. The point is to build judgment: when to use AI FDE, how to scope context intelligently, how to prompt for the platform instead of just for code, how to review generated output critically, and how to turn one successful pattern into a repeatable team habit.
That is why the difference between a team with AI FDE access and a team that is genuinely productive with AI FDE can be enormous.
What This Means for Foundry Leaders
The wrong question is whether AI FDE is impressive in a demo.
Ask instead:
- are we using it where it is already strong,
- are we wasting time and cost through poor prompting,
- do we know when to switch between local iteration and platform-aware execution,
- are we teaching the team repeatable patterns rather than celebrating one-off wins?
That is usually where the return shows up.
Final Thought
AI FDE is not underused because the capability is weak.
It is underused because most teams have not yet adapted their way of working to what the tool actually is.
Once that clicks, the conversation changes. AI FDE stops being an assistant bolted onto the workflow and starts becoming part of how the workflow itself is designed.
Remi Barbier
