Oracle Designer Lost Support in 2013. My AI Agent Develops in It Anyway.

Oracle Designer 10g is a CASE tool from the early 2000s. Support ended in 2013. At my job it is still the center of development: the repository holds the entire design of a large insurance system (2,741 entities, 3,277 table definitions, 12,841 PL/SQL modules, 5,624 forms), and about 10 developers work in it daily. Everyone, me included, assumed you work with Designer through its GUI. Clicking, dragging, repeating.

The question I wanted to answer: can an AI agent that knows SQL and has database access do that work instead?

Two days later the agent had designed an entity, a table, a sequence, two triggers, and a complete form definition, moved a table between applications, and debugged the generated form to a working runtime. It opened the Designer GUI exactly zero times. Everything I personally did in a GUI fits in two buttons: Generate, and starting the form.

The discovery that made it possible

Designer stores everything in an Oracle schema, and next to the data it ships three layers that are all reachable from a plain SQL session:

• CI_* views (722 of them) for reading. Every entity, column, and form item is a row in a view.
• CIO* packages (about 200) for writing. Every element type has a package with ins/upd/del/sel and a typed record.
• CDAPI for transactions: open_activity, then your changes, then validate_activity (Designer's own validation rules), then close_activity. On failure, abort_activity rolls the repository back.

The basic write pattern looks like this:

declare
   ent cioentity.data;
   st  varchar2(10);
   wa  varchar2(2000);
begin
   jr_context.set_workarea('GLOBAL SHARED WORKAREA');  -- skip this: CDR-00100
   cdapi.initialize('MYAPP');
   cdapi.open_activity;

   ent.v.name       := 'MY ENTITY';  ent.i.name       := true;
   ent.v.short_name := 'MYE';        ent.i.short_name := true;
   cioentity.ins(null, ent);

   cdapi.validate_activity(st, wa);
   if st = 'Y' then
      cdapi.close_activity(st);
      if st = 'Y' then commit; else cdapi.abort_activity; end if;
   else
      while cdapi.stacksize > 0 loop
         dbms_output.put_line('VIOLATION: ' || cdapi.pop_instantiated_message);
      end loop;
      cdapi.abort_activity;
   end if;
end;
/

There is no documentation for any of this anymore. It does not matter, because the API is self-documenting: the package specs are readable from all_source, so the agent's first move for every element type was one query away:

select text from all_source
where owner = :repo_owner and name = 'CIOENTITY'
and type = 'PACKAGE' order by line;

An AI agent does not need the GUI. It needs sqlplus.

The loop that worked

The same four steps repeated for every element type:

1. Read the API from the database. The package spec says which fields the record has.
2. Read an existing element as the template. There is no house-standards document, but there are 3,277 existing tables. Naming conventions, audit columns, domains, window sizes, preference sets: all of it was read from elements my colleagues built over 20 years. "How we do things here" is written in the data itself.
3. Write in small validated transactions. One logical change, validate, and on failure print the violation messages and abort.
4. Verify through CI views before moving on.

With that loop the agent built the full chain: entity with attributes, table with columns on the house domains plus a primary key, the table-to-entity mapping (normally the job of a Designer wizard called the Database Design Transformer), a sequence with the ID trigger, audit columns with their trigger (PL/SQL bodies written through the RMOTEXT API), table ownership moved to another application with a shortcut left in the original, and the complete form definition: module, window, component, table usage, items, preference sets.

Then came the one part SQL cannot do. Generating the actual Forms binary requires a client-side tool, so I pressed Generate in Designer. The generator failed. The agent read the generator output and the .err log file from disk, diagnosed each failure, fixed them through the API, and I pressed the button again. That cycle repeated until the form ran.

One fix deserves a mention. The form compiled and started, but the layout was broken: all fields stacked on top of each other. I gave the agent a screenshot of the running form. It recognized the pattern, found the cause (items without display_width fall back to the column's width, and the layout collapses into a stack) and set the widths on all items through the API. The next generation ran clean.

Errors are data

Around 20 distinct errors came up across the two days. Every one was diagnosable from the message plus the state of the database. A sample:

Error	Cause
CDR-00100: Workarea context has not been set	missing jr_context.set_workarea before anything else
ORA-00001 on an internal unique key	reusing a CIO record between ins calls: it keeps the previous element's IDs, so reset the record to an empty one
PLS-00302: component 'INS' must be declared	some packages are abstract; write through the specific subtype package
CDG-01199: no queryable item at generation	items were created without select_flag = 'Y'
identifier must be declared in the .err file	the physical table did not exist yet on the target dev database

None of these are in any manual. All of them are now in ours, because the collected errors turned out to be the most valuable output of the whole exercise. They went into two places: a handbook for humans, and a Claude Code skill for future AI sessions. The next session does not rediscover CDAPI, it starts from a working recipe.

The skill is open source (MIT), with the transaction templates, the per-element procedures, and the full error table:

nuncij / oracle-designer-cdapi-skill

Drive Oracle Designer (6i/9i/10g) with an AI coding agent via its CDAPI/CIO PL/SQL API - entities, tables, forms, no GUI. Claude Code skill + proven SQL templates.

Oracle Designer CDAPI Skill — drive Oracle Designer with an AI coding agent

Oracle Designer (6i/9i/10g) is a CASE tool from the early 2000s, out of support since 2013, yet still the center of development in many legacy Oracle shops. The common assumption is that you can only work with it through its GUI (Repository Object Navigator, Design Editor). That assumption is wrong.

Designer stores everything in an Oracle schema and ships a complete PL/SQL API next to it. That means an AI coding agent (Claude Code, or any tool that can run sqlplus) can read and write the repository directly: create entities, tables, columns, keys, sequences, triggers, and complete form module definitions — validated by Designer's own engine, without a single click in the GUI. The only steps left for a human are pressing Generate (Forms/DDL generators are client-side) and drawing diagrams.

This repository packages that capability as an…

View on GitHub

An agent with write access to production designs needs guardrails

The same access that lets an agent create a table lets it silently damage a colleague's form with one mistyped ID. Before letting it loose we layered defenses: scripts look up elements strictly by name and verify parentage before touching anything, a control report runs after every session and lists everything that user changed that day across 17 element types, and a log table with a nightly job keeps permanent change history, because Designer itself only stores the last change. The nightly database backup stays as the final net. All of it is running, not planned.

Wrapping up

The limits we actually hit: drawing ER diagrams (the layouts are binary blobs) and pressing the two client-side generator buttons. Everything else that "requires the GUI" turned out not to.

The key insight: a legacy tool with no SDK, no docs, and no support is not necessarily closed to AI agents. If it stores its world in a database, it may be the most open tool you have. The dictionary replaces the SDK, existing data replaces the standards document, and error messages replace support. Designer waited 20 years for a user that reads package specs for fun.