Forem: Usman Khan

Stop Briefing AI. Let It Interview You

Usman Khan — Sun, 17 May 2026 11:42:07 +0000

A classic "so close, yet so far" AI experience. Here is the scenario:

You spend a long time giving the AI every detail it needs, but it still misses the mark. You end up spending more time fixing its mistakes than you would have spent doing the work yourself. Also, the result are not consistent with every new prompt for smaller task it perform well but fails in complex task.

And you can't even blame the AI. You gave it everything at once and expected a magic.

The Real Problem: One Big Prompt Is a Trap
When you dump a giant prompt at AI, you feel like you've communicated well. You've written paragraphs. You've attached files. You've been thorough.

But here's what's actually happening: your prompt has gaps. It always does. You don't know what you don't know. The AI fills those gaps — silently, confidently, and often incorrectly. It doesn't stop and ask. It just builds.

And you won't find out until the end.

That's the black-box problem. You get back something that almost matches what you imagined. Then you spend the next hour in refactor mode, wondering where it went wrong.

A Better Way: Let AI Question You First
What if instead of giving AI everything upfront, you let it ask you the right questions first?

That's exactly what the Grill Me skill does.

Here's how it works:

You tell the AI what you want — in a short line or two. No essays, no spec docs.

The AI starts questioning you. One question at a time. Sharp, targeted questions that expose the gaps in your thinking.

For each question, it gives you a recommended answer with its reasoning — you just confirm, correct, or redirect.

If the answer can be found by reading your codebase, it reads the codebase instead of bothering you.

When every branch is resolved, you get a clean Decision Summary — and you can say: "Implement."

No surprises. No refactoring. No "oh I didn't realize it would do that."

What It Actually Looks Like in Practice
Here's a real implementation session. Three Jira tickets needed implementing — a legacy compatibility layer for an NRP publish service. Instead of writing a long prompt, I just ran:

/grill-me "implement XYZ-10499, XYZ-10501, XYZ-10503"

The AI pulled up all three tickets, then explored the codebase before asking a single question. It came back with:

"Got the full picture. The codebase has no legacy-compat mode detection yet — that's the foundational piece all three tickets depend on.

Question 1: How will legacy-compat mode be detected?

My recommendation: An org level config flag is more reliable than a header because it doesn't depend on callers always sending it correctly. Though a header-based override on top for testing would be useful. Which approach are you taking — header, org config, or both?"*

Notice what happened there. I gave it three ticket links. It read them, explored the codebase, identified a missing foundational piece I hadn't even mentioned, and then asked one sharp question with a recommended answer.

I responded in one line: xyz-legacy request header will be added by the intermediate service for all legacy calls automatically.

The AI confirmed and moved to Question 2 — where to read and store the header — and again it had already looked at the codebase and suggested the exact right place, with code references.

Question 2: Where should the xyx-legacy header be read and stored on the request context?

Looking at the codebase, there are two existing patterns for request-level data propagation:
. . .

My recommendation: read xyx-legacy in abc.ts and store it as something like var.isLegacy= true/false, so all downstream pipes and services can branch on it without re-reading the header repeatedly.

Is that the right place, or do you have a different layer in mind (e.g., a dedicated middleware, or reading it directly in each pipe)?

Total 09 questions in, every design decision was locked in. No ambiguity. The overall session ran for 15mins. But I ended up with confidence. Overall task completion time was 45mins. Which includes below mentiond skills execution, which we will see in later post.

Then I typed /to-prd and it generated a full PRD.
Then /to-issues and it created vertical implementation slices.
Then create a pr — and a pull request was live on GitHub.

From Jira tickets to open PR, with zero rework.

What Makes It Different
A few things Grill Me does that a plain prompt never will:

It reads your codebase before asking. If the answer already exists in your code, it won't ask you to re-explain it. In that session, it checked abc.ts, pqrs.pipe.ts, xyz.service.ts — and tailored every question to how your project actually works, not how a generic project would.

It gives a recommendation first. You're not staring at an open-ended question wondering what the right answer even is. It says "here's what I'd do and why" — you just react. This is way faster than thinking from scratch.

It catches things you missed. In that same session, the AI caught that the codebase had zero legacy-compat detection — before even getting to the actual ticket requirements. That's the kind of gap that bites you mid-implementation.

It builds a shared record. By the end, the Decision Summary is the ground truth. No more "wait, what did we decide about the depth override?" It's all written down.

When to Use It
The best moments to reach for Grill Me:

Before writing a PRD or TRD

Before asking AI to implement a feature

Before committing to a data modelling or API implementation

When several design choices depend on each other

When you want the AI to push back instead of just agree

If you're about to write a long prompt — stop. Write two lines about what you want. Then type /grill-me. The questions alone will surface things about your own idea that you hadn't fully thought through.

The anatomy of an APEX 26.1 APEXlang file

Usman Khan — Sun, 17 May 2026 11:41:32 +0000

Introduction
If you have spent any time reviewing traditional APEX export SQL, you know the problem. The application is there, but it is buried inside hundreds of calls to internal APIs. You can version it, search it, and deploy it, but reading it fluently is hard work.

To be fair, this is not the first time APEX has given us something better than one huge SQL export. Older versions of APEX could export an application using the Split into Multiple Files option, and APEX has also had a human-readable YAML export format. Those were useful, especially for review and source control, but the YAML format was read-only, and the split SQL export was fundamentally SQL export syntax.

APEXlang makes that structure easier to work with. It mirrors the APEX Builder mental model in a source format that is intended to be read as APEX metadata: applications contain pages, pages contain regions and components, shared components live together, and SQL, PL/SQL, JavaScript, CSS, and HTML still appear where you would expect them.

In this post, I will walk through the anatomy of an APEXlang .apx file and show how to build a mental model of an app quickly.

The Folder Structure
An APEXlang export is not one giant SQL file. It is exported as a zip file that expands into a folder structure.

For the customers sample app, the tree looks like this:

customers/
|-- application.apx
|-- page-groups.apx
|-- pages/
| -- p00001-dashboard.apx |-- p00050-customer.apx
|-- shared-components/
| |-- app-computations.apx
| |-- app-items.apx
| |-- app-processes.apx
| |-- authentications.apx
| |-- authorizations.apx
| |-- breadcrumbs.apx
| |-- build-options.apx
| |-- classic-navigation-bar-entries.apx
| |-- component-settings.apx
| |-- legacy-data-load-definitions.apx
| |-- lists.apx
| |-- lovs.apx
| |-- messages.apx
| |-- plugins/region/APEXLANG-14855697926908483213/{custom-attributes.apx,plugin.apx}
| |-- shortcuts.apx
| |-- static-files.apx
| |-- report-layouts/report-layouts.apx
| |-- report-layouts/CUSTOMER-REPORT.rtf
| |-- static-files/icons/app-icon-32.png
| -- themes/universal-theme/{template-option-groups.apx,theme.apx} |-- supporting-objects/ | |-- deinstall-script.sql | |-- install-scripts.apx | |-- install-scripts/activities.sql | |-- supporting-objects.apx | |-- substitutions.apx | |-- upgrade-scripts.apx |-- upgrade-scripts/upgrade-eba-cust-spec-and-body.sql
|-- deployments/default.json
|-- .apex/apexlang.json
`-- workspace-components/app-groups/APEX-184853421316436653.apx
application.apx is the application-level definition. This is where you find the application name, version, authentication, authorization, navigation, theme, globalization, security settings, substitutions, JavaScript, CSS, and other global configuration.

pages contains one file per page. The filenames are practical: p00001-home.apx, p00003-event-details-p3-event-name.apx, p00050-customer.apx, and so on. You can usually tell the page number and purpose before opening the file.

shared-components contains the things you would expect from APEX Builder: LOVs, lists, breadcrumbs, authentications, authorizations, app items, app processes, themes, plugins, messages, build options, static files, and report layouts.

supporting-objects contains installation, upgrade, substitution, and deinstallation metadata. The actual SQL scripts can live under folders such as supporting-objects/install-scripts and supporting-objects/upgrade-scripts.

deployments contains deployment configuration. In the examples, default.json maps the app to an application ID.

.apex contains APEXlang metadata. In the examples, .apex/apexlang.json identifies the APEXlang metadata version.

This structure matters because it lets you navigate an app the same way you think about an app. That idea existed before APEXlang, but APEXlang makes the files easier to read. You can edit, validate, and import them back into APEX.

What Lives in application.apx
Open application.apx first.

It starts with an app block:

app TEAM-CALENDAR (
name: Team Calendar
version: 24.2.1
authentication {
publicUser: APEX_PUBLIC_USER
authenticationScheme: @apex$8947201266001685638
}
navigation {
homeUrl: f?p=&APP_ID.:1:&SESSION.
}
)
That reads much closer to a configuration file than an export script. You can scan it and answer basic questions quickly:

What is this application called?

What authentication scheme does it use?

Is authorization configured globally?

What is the home page?

Which theme is current?

Are there global substitutions?

Is custom CSS or JavaScript included?

You will also see the same APEX ideas you already know: session management, security, globalization, navigation, Progressive Web App settings, and substitutions.

Read application.apx like the App Definition screen in APEX Builder. Do not try to understand every reference yet. Get the global shape first.

How Pages Are Modeled
Page files are where APEXlang becomes especially useful.

A page starts with a page block:

page 1 (
name: Home
alias: HOME
title: &APPLICATION_TITLE. - Home
appearance {
pageTemplate: @/standard
}
)
After that, the file is organized around page components. In the examples, pages contain:

region

item

button

dynamicAction

validation

computation

process

branch

Again, this follows the APEX Builder mental model. To understand a page, scan the top-level component blocks first.

Regions often contain their own nested configuration. A report region may include a source block, layout settings, template choices, columns, actions, conditions, and attributes.

region APEX$1553489748373581675 (
name: Events Calendar
type: calendar
source {
location: localDatabase
type: sqlQuery
sqlQuery:
sql select e.event_id , e.event_name from eba_ca_events e
}
)
That is the key pattern: the declarative APEX component is modeled structurally, and the executable code remains embedded in a fenced block.

For form or dialog pages, I would scan in this order:

Page name, alias, template, and security.

Regions, especially the main form region.

Items and their source/default/session state behavior.

Buttons and button positions.

Processes and branches.

Validations and dynamic actions.

You can usually tell whether a page is display-only, a report, a modal form, or a complex transactional page in a couple of minutes.

Shared Components Become Readable
Shared components are split into focused files. That is one of the biggest readability wins.

For example, shared-components/lovs.apx contains lov blocks. A static LOV contains nested entry blocks. A SQL-based LOV contains a source block with the SQL query.

lov APEX$14836072312031628364 (
name: USERNAME_FORMAT
source {
location: staticValues
}

entry APEX$14836072618328628365 (
    sequence: 1
    display: Email Address
    return: EMAIL
)

)
Lists work the same way. shared-components/lists.apx contains list blocks, and each list contains entry blocks with labels, icons, links, current-page logic, and parent-child relationships.

App processes live in shared-components/app-processes.apx. Authentication schemes live in shared-components/authentications.apx. Plugins live under shared-components/plugins, separated by plugin type and id. Themes live under shared-components/themes.

This is much easier to review than a traditional SQL export because the file boundaries match the APEX Builder navigation, and the file contents are not wrapped in API calls.

Understanding References
APEXlang uses references heavily, and learning the reference style is what makes the files click.

You will see @apex(... references in exported files. These are references to APEX components by generated identifier. For example, an application may point to an authentication scheme or navigation list using an @apex)... value.

You will also see more readable references based on static ids and names:

authentication {
scheme: @oracle-apex-accounts
}
userInterface {
currentTheme: @universal-theme
}
navigationMenu {
list: @navigation-menu
}
That matters because APEX 26.1 adds static ids across APEX components, and APEXlang uses those ids to make references more stable and readable.

You will also see @/... references, especially for templates:

pageTemplate: @/standard
listTemplate: @/side-navigation-menu
buttonTemplate: @/text-with-icon
These are easier to read because the component is referenced by a friendly path-like name.

Page item references still look like APEX page item references. SQL and PL/SQL blocks use bind variables such as :P50_ID, :APP_ID, and :APP_USER. URL targets still use familiar APEX substitution syntax, such as f?p=&APP_ID.:1:&SESSION..

Named component references also appear naturally in places such as authorization checks, build option logic, template references, and links.