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.

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:

ins/upd/del/sel

and a typed record.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 same four steps repeated for every element type:

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.

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:

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:

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…

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.

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.