Oracle Designer lost support in 2013. Its write API is still one SQL session away.

A developer working on a large insurance system published an account on dev.to of an AI agent that designed an entity, a table, a sequence, two triggers and a complete Oracle Forms definition inside Oracle Designer 10g, moved a table between applications, and debugged the generated form to a working runtime, without opening the Designer GUI once ^[5]. Designer is a CASE tool from the early 2000s whose support ended in 2013 ^[1], which puts it roughly twelve years past its last patch ^[21] and makes it the kind of system usually filed under "replace eventually" rather than "script this week".

The repository in question is not a toy. It holds 2,741 entities, 3,277 table definitions, 12,841 PL/SQL modules and 5,624 forms ^[2], about 24,483 catalogued elements in total ^[19], with roughly ten developers working in it daily ^[3]. Everyone there, the author included, had assumed the tool was its GUI: clicking, dragging, repeating ^[4].

What the account documents is a three-layer API sitting in the same Oracle schema as the data. Reading is 722 CI_* views, where every entity, column and form item is a row ^[7]. Writing is about 200 CIO* packages, one per element type, each with ins/upd/del/sel and a typed record ^[8]. Transactions go through CDAPI: open_activity, then the changes, then validate_activity, which applies Designer's own validation rules, then close_activity, with abort_activity rolling the repository back on failure ^[9]. That is roughly 922 SQL-callable objects ^[20]. Forget jr_context.set_workarea and you get CDR-00100 ^[10].

No documentation for any of this survives, according to the author, and it did not matter: the package specs are readable from all_source, so the API documents itself ^[11]. The working loop was four steps: read the API from the database, read an existing element as the template, write in small validated transactions that print violations and abort on failure, and verify through the CI views before moving on ^[12]. The second step is the interesting one for anyone maintaining a system with no written standards. There was no house-standards document, but there were 3,277 existing tables, and naming conventions, audit columns, domains, window sizes and preference sets were all read out of elements colleagues had built over twenty years ^[13]. That included work normally done by a wizard, the Database Design Transformer, which handles table-to-entity mapping ^[14], plus a sequence with its ID trigger, audit columns and their trigger with PL/SQL bodies written through the RMOTEXT API, and a table ownership move that left a shortcut behind in the original application ^[15].

The boundary is where the tooling stops being data. Generating the actual Forms binary needs a client-side tool, so the author pressed Generate; when the generator failed, the agent read its output and the .err file from disk, fixed the causes through the API, and the cycle repeated until the form ran ^[16]. One failure was visual rather than textual: fields stacked on top of each other because items without display_width fall back to the column width, diagnosed from a screenshot and fixed by setting widths through the API ^[17]. Around twenty distinct errors came up over the two days, each diagnosable from the message plus the state of the database ^[18]. Total human GUI time: two buttons ^[6].

Worth watching: whether the same read-template-write-validate loop holds on repositories where twenty years of convention are inconsistent rather than merely undocumented, and how much of a legacy stack's remaining GUI dependency is, like the Forms generator, a compile step rather than a design step.