Snippets and Thoughts of One Oracle Developer

H Here is the situation I kept running into. I want an AI agent to help me with a real schema, look up a table, count some rows, sanity-check a column, find which view a column comes from. None of that is risky on paper, it is just SELECT. But the moment you hand a database connection to an agent, you are one bad prompt away from a disaster. TRUNCATE CASCADE, DROP PURGE, even simple UPDATE can do a lot of damage. So I built a small command into ADT.ai for exactly this case. It is called "discovery", and the whole point is that an AI (or any muggle) can poke around a schema without being able to break anything. What it does You give it a SELECT and an environment, it runs the query, prints the result, and writes a Markdown report. That is it. No DML, no DDL, no PL/SQL, no multi-statement smuggling. If you try anything other than a single SELECT, the validator rejects the statement before it ever reaches the database. adtai discovery -env DEV -sql "SELECT t...

I I have been shipping APEX Deployment Tool for a few years now. It is a Python CLI that extracts Oracle database objects, APEX applications, and data exports into files you can version in Git, then via clever patch files deploys them anywhere. Other people also use it, which is great. The problem is I am not a professional Python developer, and after a couple of years of adding features on top of features, the code shows it. So a two weeks ago I started a full rewrite. Not just a refactor, but a full rewrite, done almost entirely by AI, module by module. This post is about why, how, and what is still ahead. Why the rewrite The code quality problem was the most obvious one. The largest files had grown into multi-responsibility monsters that were hard to read and harder to change safely. Normalizers (the functions that clean up DDL before writing files) were woven into the main export script instead of living in their own testable place. Adding a new object type or tweakin...

I I read Tim Urban's "Your Life in Weeks" piece years ago, the one where he draws every week of a long life as a single grid of small squares. The image stuck with me for a reason I could not explain at the time. I rebuilt it as a tiny Claude Code skill that lives in my Obsidian vault and refreshes itself. Let me start with why the idea matters, then the skill, then how to build your own. The power of seeing your weeks A life of 90 years is about 4,680 weeks. Written as a number it means nothing; you read it, you nod, you move on. Drawn as a grid where each week is one square, it stops you cold. The whole thing fits on a single screen. That is the trick, and it is not a gimmick. The reason it works is the unit. A year is too big to feel and a day is too small to matter, but a week is the exact size of a human plan. You already think in weeks. You know what one feels like. So when you see all of them laid out and notice how few are left, the abstraction of ...

A APEX 26.1 dropped and everyone wants to spin it up locally. Good news, you don't have to build anything from scratch. The community have already done the heavy lifting. Here is whats out there. uc-local-apex-dev (United Codes) GitHub: https://github.com/United-Codes/uc-local-apex-dev This is my first recommendation for anyone who just wants to get going. Philipp Hartenfeller from United Codes maintains it actively, and it is kept up with every release since 23ai. Runs Oracle DB 26ai + APEX 26.1 + ORDS 26.1 out of the box. A single "./install.sh" handles everything, including waiting for the database to come up and configuring ORDS. Works with both Docker and Podman (it auto-detects your engine), and it is Mac/Linux friendly. ORDS Docker Compose (Anders Swanson, Oracle) GitHub: https://github.com/anders-swanson/oracle-database-code-samples/blob/main/ords-docker-compose/ Anders Swanson works on Oracle AI Database at Oracle, and he published ...