AI is the biggest buzzword out there right now. It’s everywhere—conference sessions, product announcements, LinkedIn posts (sooo many LinkedIn posts)—and it’s driving a lot of conversation about how software gets built. Some of that is useful. A lot of it, frankly, is more hype than help. For developers working in Oracle APEX, the question isn’t whether to use AI. It’s how to use generative AI for Oracle APEX development in a way that actually improves your workflow without introducing unnecessary cost, complexity, or risk.
Across our team, we’ve established a set of practical approaches for using AI within our development workflow. The specifics vary by developer, but the patterns are consistent. AI is useful in a few very specific parts of the workflow, and much less helpful outside of those. The risk isn’t just that AI gets things wrong, but that it gets them wrong confidently, suggesting API parameters or APEX functionality that looks plausible enough that developers might not catch it on a quick read.
In this article, we focus on practical steps you can take today—based on how we’re using these tools in real projects—to make generative AI a useful part of your APEX development process.
1. Work inside your development environment
Most of our development happens in Visual Studio Code with database connections managed through Oracle extensions. That’s also where AI has been the most effective.
Using something like GitHub Copilot directly in the editor changes how we interact with it. Instead of copying code into a separate tool, we can:
- Select part of a package and ask for a modification.
- Let inline suggestions complete a query or procedure.
- Apply changes directly to a file, then review before saving.
On tool choice, there’s no one “right” solution (at least not yet). In practice, these are the tools we see used most often:
- GitHub Copilot
- Gemini
- Claude and Codex-based tools
- ChatGPT
Each tool behaves a little differently in terms of accuracy, output style, and integration. The bigger factor has been how well it fits into your development workflow, not which model is “best.”
2. Streamline repetitive coding work
The most consistent value we’re seeing is in reducing the amount of repetitive work. For example:
- Writing one version of a PL/SQL pattern and letting AI complete the rest.
- Using autocomplete to fill in predictable SQL structures.
- Asking for targeted updates, like calculating a date differently inside an existing package.
This saves time, especially on tasks where the structure is already clear.
Where it becomes less reliable is when the request gets too broad. If you ask for a full solution or a large piece of functionality, the output tends to drift. Sometimes the AI introduces unnecessary complexity. Other times it references user interface elements or APEX functionality that doesn’t exist. For example, we have seen AI suggests APEX_UTIL parameters that don’t exists in the installed version or reference DA events that were deprecated.
Keeping requests narrow and focused produces more reliable results. Moreover, as token costs continue to rise alongside increased usage, it is becoming imperative to formulate highly precise and concise queries. Mastering this efficiency in using AI for Oracle APEX development will be essential for optimizing your resource consumption.
3. Use AI to diagnose bugs—not fix them
We consistently use AI to help diagnose issues as a first step in debugging. If we provide an error message or a section of code, it can often point us in the right direction. It’s particularly good at identifying where something might be going wrong.
The fixes it suggests are a different story.
In many cases, the proposed solution is more complicated than it needs to be. We’ve seen examples where a simple change—like adding an index or adjusting a condition—gets replaced with a much larger rewrite.
Our approach is to use AI to narrow down the problem, then implement the simplest solution that fits the system.
4. Fill the gaps in business logic
A lot of APEX work involves translating business rules into code, and those rules aren’t always familiar to development teams. We’ve used AI to:
- Explain domain-specific concepts in plain language.
- Break down complex rules into something easier to implement.
- Help structure requirements into a more usable format.
One example that came up recently was around tax and depreciation rules. We needed to understand how straight-line vs declining balance depreciation behaves on a mid-year asset addition. We’re developers not accountants, so we had AI walk us through the calculation mechanics in plain language before we validated the details with the client.
It doesn’t replace that validation step, but it reduces the time it takes to get there.
5. Define your standards explicitly
Out of the box, AI doesn’t know how we write code. If we don’t give it direction, it will generate something that might work, but doesn’t follow our conventions—naming, formatting, structure, or even basic layout.
We address this in a few consistent ways:
- Including formatting instructions directly in prompts.
- Providing examples from existing code.
- Using repository-level configuration where tools can pick up those patterns: GitHub Copilot, for example, supports a .github/copilot-instructions.md file where you can define the standards/team naming conventions and formatting rules. Copilot picks these up automatically without needing to repeat them in every prompt.
With the right setup, the output becomes much closer to what we expect. Without it, we end up spending time reworking what was generated.
6. Review every line before it goes in
One of the risks we’ve talked about as a team is how easy it is to paste in code that we didn’t fully write or fully understand.
It may run. It may even pass initial testing. But if we don’t understand how it works, it becomes difficult to maintain later. For example, packages in APEX often handle complex financial calculations, access control, and other business critical logic. Debugging AI-generated code after-the-fact in one of these areas can be very painful—especially if you didn’t fully understand it in the first place.
A common failure pattern looks like this:
- The first attempt doesn’t work.
- Follow-up prompts add more complexity.
- The final result is harder to reason about than the original problem.
To avoid that, we treat AI-generated code the same way we treat any other contribution. We conduct a code review, simplify the code where needed, and make sure it aligns with the rest of the application before committing it.
7. Treat AI as a potential data risk
Security is a consistent concern when using AI for Oracle APEX development.
With most personal accounts, AI tools process prompts externally, which means anything you paste in could be stored or used for training. That’s a big problem when working with sensitive or proprietary company data. Because of that, we avoid:
- Sharing full packages or large sections of code.
- Including client data in prompts.
- Working directly with production logic in external tools.
Instead, we focus on patterns and smaller examples.
For teams working with sensitive data, enterprise-level AI tools provide isolated environments with stronger data controls and are worth serious consideration. The enterprise tiers of tools like GitHub Copilot for Business, Claude for Enterprise, and Azure OpenAI service offer contractual no-training guarantees. That allows broader usage without the same level of risk, but it requires an intentional investment and setup.
Where Oracle Is Taking This: APEXlang
Oracle is clearly thinking about generative AI at a deeper level with the introduction of APEXlang (based on the announced direction for APEX 26.1). Instead of generating loose snippets of code, APEXlang represents an application as structured, human-readable files that can be versioned, validated, and diffed. The focus is on generating something developers can actually read and manage—not just execute.
That aligns closely with how AI is most useful in practice. The more structured and reviewable the output is, the easier it is to integrate into a real development workflow. It’s still early, but the direction is clear: AI for Oracle APEX development is moving toward generating application intent in a format developers can control.
Focus on What Actually Moves the Work Forward
There’s no shortage of ideas about what AI might do for development. What matters more is what it does reliably today.
Used well, AI can remove friction from the parts of APEX development that slow teams down—without changing the fundamentals of how good applications get built. That comes from being deliberate in how you apply it, not from trying to use it everywhere.
If you’re looking to put these ideas into practice, Traust provides Oracle APEX development services to help teams build, extend, and modernize applications with the right level of structure and control.
