When APEX 26.1 finally dropped, the new APEX Lang was the most exciting feature for me. I decided to test its capabilities immediately. Since the APEX environment I work with daily didn't support vibecoding previously, I lacked practical experience with this workflow. This made it a double experiment. First, I needed to figure out the most effective way to work with it. Second, I wanted to see how LLMs would handle APEX Lang syntax, given they weren't trained on it as heavily as on other programming languages.

I imagine I'm not the only APEX developer facing this challenge right now. Many of us are just beginning to explore the vibecoding concept. Here is a summary of how my experiment played out.

The Benchmark Requirements

When starting this task, I carefully considered how to approach it. I knew I simply had to try vibecoding something, but I wasn't entirely sure what kind of application to build. Ultimately, I decided to prepare a benchmark. I wanted a set of requirements that wouldn't be overly complex for a first attempt, but still diverse enough to test the waters. A typical real-life application often revolves around a single core feature, like reporting. I aimed for something more well-rounded:

• Report based on a REST source

• Data loader from Excel

• Reports based on existing data

• Filter regions: Faceted Search, Smart Filters

• Dashboard with different shapes of reports: charts, template components, maps, cards

The "Empty Folder" Struggle

I opted to test a few different approaches. First, I started in a completely empty folder, simply telling GitHub Copilot what I wanted to achieve. Copilot clearly lacked confidence in generating an application from scratch. It attempted to find existing templates or APEX Lang syntax examples within my local files. When it failed to locate them, it turned to the internet. It is obvious that the model is not sufficiently trained on this syntax yet.

I attempted to import the resulting application a few times, but I encountered errors during every single try. I downloaded the error logs as CSV files from the App Builder and pasted them back into the chat. Copilot corrected them step by step, and after three or four iterations, the application finally imported successfully.

From that point on, further development progressed much smoother. Imports generally worked without issues, although adding new functionalities remained somewhat buggy. To help it out, I exported Oracle Sample Apps from the App Gallery to APEX Lang and placed them in my project directory. I instructed Copilot to use them as a reference, which significantly improved the final results.

The AI is Very Literal

The very first thing I noticed is that the AI takes instructions quite literally. If I don't state something explicitly, Copilot almost certainly won't include it. For a developer experienced in APEX, many platform defaults are obvious. For instance, I didn't specify how users should log in, assuming the new app would be generated with the default Oracle APEX Accounts authentication. That part actually happened, but the generated login page was missing the username and password fields entirely, making logging in impossible.

Copilot also struggles to navigate the available APEX options and often chooses the path of least resistance. I asked it to move the filter regions to the left side and keep the report regions in the center. It worked fine for the reports, but the filters were awkwardly placed into the Navigation Bar. For a human developer, it would be perfectly logical to change the page template to "Left Side Column" and place the filters there. However, since I didn't provide that exact instruction, the LLM couldn't figure it out on its own.

Ignoring APEX Standards

The AI's lack of familiarity with APEX best practices becomes obvious at almost every step. I requested a simple form with two fields displayed conditionally, based on the user's selection in a third field. The natural approach for a human would be to create a Dynamic Action utilizing native Show and Hide actions. Copilot did create a Dynamic Action, but it populated it with a large chunk of custom JavaScript containing an IIFE function. The code itself was secure and of high quality, but completely bypassing native APEX features was definitely not what I expected.

Here is another example. Even though I shared the sample-grids application in the repository as context, Copilot generated an Interactive Grid without a Save button. We know you can enable this button by flipping literally one setting in the region properties. When I pointed out the missing Save button, Copilot generated a brand-new, custom button completely outside the Interactive Grid region. This new button remained entirely non-functional and disconnected from the grid's logic.

Do Oracle Agent Skills Help?

Did things improve significantly after loading the official agent skills prepared by Oracle? Honestly, not quite. At least, not immediately.

Once I loaded the skills, I asked the chat if it had access to them and how exactly they assist in the process. It provided an excellent answer, explaining that the skill helps with APEX Lang syntax, shared components, and proper application structure. I then asked if it had used this skill to generate that custom JavaScript form earlier. It admitted it hadn't. I instructed it to use the skill and generate the form once more. Unfortunately, this only updated the names of the Dynamic Actions, while the core logic remained firmly programmed in JavaScript.

Finally, I asked a direct question: "Doesn't the skill explicitly tell you to prioritize native capabilities first?" It confirmed that it does. After acknowledging my point, it regenerated the page, and this time, it did it correctly.

The Positives and Best Workflow

Despite these hurdles, there are definitely positive aspects to this technology. After overcoming the initial struggles of generating an app from scratch, having a solid skeleton makes further development go quite smoothly. I type a prompt, click "Import to APEX," and the changes are instantly reflected in the database. In a separate test run, I started by creating a basic application manually in APEX Builder, exported it to Lang, and then continued development within Copilot. Everything moved much faster, and I completely bypassed that initial phase of frustration.

Furthermore, some specific tasks were completed correctly on the very first try. A great example is the Excel data import. I provided a sample Excel file in the project folder. The chat analyzed its structure accurately and generated a page featuring a simple data import to a collection, along with a functional data preview.

When I experimented with more complex prompts describing advanced business logic, I fully expected weaker results. However, these attempts yielded surprisingly good outcomes. With a difficult technical task, you never really expect an AI to get it perfectly right away. But the short distance between the first generated output and a truly acceptable solution was a very positive surprise.

Occasionally, though, the chat would get stuck right at the finish line. The application would import and work almost perfectly, except for a few stubborn validation errors on the generated page. I pasted these errors into the chat one by one, but it proved unable to resolve them, even after several iterations. In the end, I had to manually debug the code and suggest the right solution to finally eliminate the bug.

Final Thoughts

The journey with vibecoding in APEX is really just beginning. It clearly holds massive potential, especially as LLMs gradually learn the specifics of APEX Lang. However, at its current stage, you need to closely inspect every single change the AI generates.

In a perfect scenario, it would be amazing to see APEX evolve into a platform similar to Lovable. Imagine a tool where business analysts or direct stakeholders could build working prototypes simply by writing prompts. Unfortunately, we still have a long way to go before reaching that reality. The errors Copilot makes right now are strictly technical. Someone without a solid background in APEX development would find them completely incomprehensible and impossible to resolve.

For now, I plan to continue my research on this topic. I will keep exploring new ways to improve the daily workflow with Copilot, whether that means crafting better instruction files, developing custom skills, or setting up dedicated sub-agents.