Most of my time writing a SQL script was never the actual logic — it was finding the right trigger template to copy, pasting in the logging code that inserts into our scriptslog table, getting the naming convention right: date, developer, purpose. I know this code by heart. I've written it a thousand times. And I was still copy-pasting it every time, then tailoring the edges to fit. At some point the obvious question showed up: if I know it this well and 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 that comes with any new table — and fed them in as context for an agent, the same AGENT.md/Codex setup I'd built for the ADA compliance work. For the simple stuff — a column add, an update, a delete — I used to Google a template and copy-paste it in. Now I just ask for the script.
How it applies them
Ask it to add a column and it doesn't hand back a bare ALTER statement. It writes the column, the logging entry, and whatever naming gets attached to the script file — the full package, the same way I'd assemble it by hand from three or four different reference scripts, except now it's one shot.
The complex case
The real test was a task on a legacy system with a genuinely awkward schema. A table had a clientcode field — free text — but no foreign key tying it to an internal clientid. The problem: clientcode wasn't reliable. The same code could map to more than one client, and some codes weren't assigned to any client at all, just leftover artifacts of user input over the years.
Getting from clientcode to clientid meant joining through several other tables, hoping to land on a valid clientid at the end of the chain. Once that mapping existed, every record in the table needed to be backfilled with the actual clientid where one could be found — and only then could the foreign key constraint actually be applied.
I asked the agent to take this on, and it flagged the edge cases on its own — the multiple-client matches, the unassigned codes — without me pointing them out first. The script it produced included print 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. The agent surfaced them before I had to.
Where the time actually goes
After the script was generated, almost all my time went into verification — checking the temp tables it built, walking through each section of the logic against the actual data. The agent had already handled the trigger scripts, the logging code, and the new columns that would eventually carry the foreign key. My job was confirming it got the edge cases right, not writing any of it from scratch.
That verification paid off in review. Two senior developers went through the script and were genuinely impressed — not just with the logic, but specifically with the row-count logs it printed along the way. That's the detail that's easy to skip when you're moving fast, and the one that actually told them, at a glance, what the script had done.
What's next
Right now this is still part of my own workflow — something I keep refining as I use it. The bigger shift came out of a demo at one of our internal AI meetings, where a different senior developer was impressed enough to ask me to put together a repository for these agents — somewhere others could use them, and progress on them could actually be tracked over time. That's the next thing on the list: turning a personal tool into something the rest of the team can build on, not just admire from a code review.