Most of my time writing a SQL script was never the logic. It was finding the right trigger template to copy, pasting in the logging code that inserts into our scriptslog table, and getting the naming convention right: date, developer, purpose. I know this code by heart and I've written it a thousand times, and I was still copy-pasting it every time. If it's this repeatable, why am I the one typing it?
Templating the conventions
I templated the conventions I kept reaching for (the audit logging pattern, the date_devname_purpose naming format, the history-table-and-trigger setup for any new table) and fed them to an agent, the same AGENT.md/Codex setup from the ADA compliance work. Ask it to add a column and it doesn't hand back a bare ALTER: it writes the column, the logging entry, and the script-file naming, the full package I'd otherwise assemble by hand from three or four reference scripts.
The complex case
The real test was a legacy system with an awkward schema. A table had a free-text clientcode field but no foreign key to an internal clientid. clientcode wasn't reliable: the same code could map to more than one client, and some codes weren't assigned to any client, just artifacts of years of user input. Getting from clientcode to clientid meant joining through several tables, then backfilling every record with the real clientid where one existed, before the foreign key constraint could be applied.
The agent flagged the edge cases on its own, the multiple-client matches and the unassigned codes, without me pointing them out. The script it produced printed logs reporting exactly how many clientcodes would be matched, merged, or left alone. I didn't know those edge cases would be a problem going in.
Where the time goes
Almost all my time went into verification: checking the temp tables it built, walking each section of the logic against the actual data. The agent handled the trigger scripts, logging code, and new columns. My job was confirming the edge cases, not writing from scratch. In review, two senior developers went through the script and were impressed, specifically with the row-count logs, the detail that's easy to skip when you're moving fast and the one that told them at a glance what the script had done.
From my workflow to the team's
After a demo at an internal AI meeting, a senior developer asked me to put these agents somewhere the team could use them and track progress. It's now packaged into our shared agent library, so a developer who needs a column add and its logging and history-table setup asks the agent instead of hunting for a script to copy and adapt.