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

An engineer at an insurance company demonstrated that an AI agent with SQL and database access can develop in Oracle Designer 10g, a CASE tool whose support ended in 2013. The agent designed entities, tables, triggers, and forms, and debugged generation errors, all without opening the GUI. The engineer found that the repository's API is self-documenting via all_source, enabling the agent to work through sqlplus.

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: | 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 https://github.com/nuncij/oracle-designer-cdapi-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.