How I build Oracle apps with a team of AI agents

A single AI coding agent is fast, confident and wrong in ways it cannot see — because it is also the one checking its own work. On Oracle projects the damage is quiet: a package compiles, the page renders, and the tenant filter or the rollback script is simply missing. What works for me is to stop treating the agent as one developer and organise several of them like a small team, with roles that check each other.

This guide is the general pattern. It works with Claude Code or any agent that can run in parallel sessions, on APEX, PL/SQL, ORDS or a Forms modernization.

The architecture

The lead

The lead owns the plan and the contracts: table definitions, package specs, REST shapes, page inventories — anything other work depends on. It splits the work into lanes, merges what comes back and decides what is done. It does not do bulk editing itself; a lead buried in code stops seeing the whole board.

Worker lanes

Each lane is a separate agent session with its own set of files. Two writers never touch the same file, which removes most merge pain before it starts. A lane gets a short brief: the files, the contract it must honour, and the exact test that proves it finished.

• Cut lanes by files, not by feature names: db/packages/billing_* is a lane; "billing" is not.
• Mechanical lanes (renames, seed data, translations) run on a smaller, cheaper model.
• Cap the number of lanes. Past three or four, the lead spends its time merging instead of thinking.

The adversarial reviewer — three moments

The reviewer is a fresh agent whose only job is to find what is wrong. It never sees the author's reasoning, only the result, and it is told to look for failures rather than confirm success. It steps in at three fixed moments:

1. Before a contract locks. Changing a package spec or a table after five lanes depend on it is the most expensive mistake in the project. A review here is cheap.
2. When a test breaks twice. The second identical failure means the author is stuck in a loop. Stop, hand it to fresh eyes, and do not allow a third blind retry.
3. Before done. Nothing is called finished until someone other than its author has tried to break it.

The traffic controller

With parallel lanes, someone has to keep order: queue merges so they land one at a time, enforce the lane limit, notice when two lanes drift towards the same files, and hold a lane that is waiting on a contract. This can be a small agent or a script; what matters is that it is not the lead doing it in its spare attention.

Parity testing

On a modernization, "it works" must mean "it does what the old system did". Parity tests compare the new app with the legacy behaviour rule by rule and screen by screen: the same inputs, the same validations, the same totals. On new builds the equivalent is a clean-install test — every release deployed into an empty schema and the full suite run there, because an install that only works on the developer's database is not an install.

• Run the one focused test you touched first; the full suite only before a merge.
• Every check must be able to fail. Break it on purpose once to prove it is not a silent pass.
• Keep the parity list visible as a count: 37 of 40 screens matched says more than "nearly there".

Budget pacing

A team of agents can spend a week's budget in an afternoon. Pace it like money:

• Right model per task. The large model plans, reviews and resolves conflicts; smaller models do searches, renames and boilerplate.
• Retry limits in code, not in the prompt. A script with MAX_RETRIES = 2 stops; a prompt saying "keep trying" does not.
• A budget line. Decide in advance the usage level where new work stops and only finishing work continues — and never stop in the middle of a merge.
• Small context. Point agents at files and line numbers instead of pasting full exports.

Security fences

Agents move fast, so the fences have to be in configuration, not in good intentions:

• Deny rules for destructive commands (force pushes, recursive deletes, dropping users) and for reading secrets such as .env files and wallets.
• A least-privilege database user for the agent. Never SYS, never a DBA account, never a production wallet on the machine.
• Hash-checked apply scripts. The script that touches a database is reviewed, its SHA-256 recorded, and it only runs if the hash still matches — so nothing edits it between review and apply.
• Protected settings. The agent cannot edit its own permission file. A fence the agent can move is not a fence.

A starting checklist

1. Write the contracts first and have the reviewer attack them before any lane starts.
2. Split lanes by file sets; give each lane its files, its contract and its finishing test.
3. Put the deny rules, DB user and settings protection in place before the first run.
4. Wire a clean-install (or parity) test as the definition of done.
5. Set the retry limit and the budget line, then start.

The commands and settings for this setup are collected on the Claude Code cheat sheet, and the full skills are in the Premium Skills Pack.

Check your understanding