The latest AI models are remarkably capable; but they’re not perfect. So how do you use AI for coding without letting it go off the rails?
First, let’s get a few things out of the way. I do not use AI to write my articles for me. I do use AI for coding – but as a collaborator, not as a “vibe coder”. I personally review and understand every line of code deployed to production. Is it perfect? No. But it is a massive time-saver and accelerator.
I use GPT-5.6 extensively for both work and personal coding projects. When I first started (not that long ago – yes I’m a late adopter) I was told to use Plan mode for any non-trivial coding task. That helped a lot because it allowed me to review the changes the AI intended to make before it wasted a lot of tokens building something I didn’t want.
I rarely use Plan mode anymore. Instead, before writing the first line of code, I create a file.
In my repositories, I have a docs folder. Under that, I create a folder for the feature, containing one or more Markdown files. For example:
For a relatively simple feature, I might use just one file containing all the details. For more complex features, I’ll use two or more Markdown files.
I start with the feature title, a summary, and whatever ideas I already have in my head. I then ask the AI to read the file and flesh out the details. It has access to the entire repository, including the schema, source code, and APEX applications; so it can design and plan the feature with direct reference to the existing codebase.
The document(s) grow over time, gaining whatever sections the AI or I think are needed, such as:
Summary
Requirements
Current State
Scope
Design
Project Plan
Technical Implementation
Open Questions
… whatever else …
This starts a tight review-and-update loop. I read the changes made to the design doc, ask and answer questions, make adjustments, and commit the documents to the repository in stages. This makes it easy to see what changes the AI is making and revert them if it badly off track.
At any stage I can ask the AI to review the specification:
"is this spec clear, no ambiguities, gaps, or hand-waving" "are we ready for implementation"
I can also switch to a different model or level of reasoning whenever I need to. A higher-reasoning AI is great for doing a sanity check. The document provides all the context it needs.
One advantage of this approach is that avoids the chat history problem. Long conversations involving design decisions, experiments, discarded ideas, and changes of direction can sometimes lead the AI accidentally down the wrong rabbit hole.
The document is a living specification, but it also serves as a definitive source of truth for the feature. At any point, I can start a new chat and get a fresh perspective without losing the important design decisions that have already been made.
The document also becomes a coordination tool during implementation. I ask the AI to update it with the current status of the feature, the stage we’re at, what has been deployed to development so far, and what the intended next step should be. In many cases, the implementation can proceed without interruption from start to finish. If it gets interrupted (e.g. because I’ve run out of credits) it’s easy to recover later.
In the repository root I have the AGENTS.md file containing instructions such as:
- Store feature artifacts in a folder under `docs`, named after the feature. Create the feature folder if it does not exist.
- If a feature design document does not exist, create one inside the feature folder.
After the feature is complete, I’ll typically keep its documentation. Later, if bugs or further changes arise, those documents provide valuable history and context for the AI, including the design decisions made in the past.
I’m not suggesting this approach is revolutionary or original. It’s just something that works for me, because it provides just the right level of rigour and continuity I need, without any layers of bureaucracy or unnecessary overhead.
Plan mode is wonderful. However, for serious development in collaboration with AI, design documents offer so many benefits that I can’t imagine working without them.
The Australian Oracle User Group is hosting a series of webinars this year and on 17 February I’ll be speaking about how to add an interactive Google Map to your APEX application. If you’re using APEX and want to see how easy it can be to integrate Google Map capabilities into your application, this is for you.
My session is at 9am in Perth time (1am UTC) – which is:
Pictured: Hamersley Gorge, Karajini National Park, Western Australia
Why is this blog called “Jeff Kemp on Oracle”?
Pretty much my entire career has been underpinned by the Oracle database. My first few I.T. jobs involved maintaining and building Oracle Forms and Reports. SQL and PL/SQL have been my indispensable two-pronged tool since day one and remain so today. Through fortuitous circumstance I had the opportunity to swap Forms for APEX quite a few years ago and I’ve been busy working on APEX applications since then.
The Oracle database is pretty old, and it’s huge and horrendously complex. It’s not the most popular – it certainly is among the “most dreaded” technologies in recent surveys; and (apart from XE) it is not cheap. But it unarguably has been, and still is, a major force to be reckoned with. When handled well it is still top of the line when it comes to performance and reliability.
Oracle APEX started out as a kid brother to Oracle Forms back in the mid-2000s, and has since quietly risen to be a nimble and capable development platform. It allows developers from different backgrounds to be productive very quickly.
If you’re a web developer skilled with HTML, CSS and Javascript, you can let APEX handle the database plumbing for you and build beautiful, functional and responsive web sites.
If you’re a PL/SQL nut like me, you can let APEX handle all the user interface and web browser complexities and build beautiful, functional and responsive web sites.
Either way, APEX gives you a starting point to learn the “other side”, whichever angle you came from.
I’ll be presenting a talk about some APEX applications I’ve been building gradually over the past five years at the AUSOUG Connect 2017 conference in Perth, Western Australia on 29 November.
My hope is that you’ll get some ideas on how best to set up the overall architecture for your APEX applications that may need to serve more than one customer – whether different organisations or different business groups within your organisation.
Although it’s just one day, there’s a lot of good content packed in for developers, DBAs and eBusiness professionals so you really don’t want to miss it!
I’m looking forward in particular to hearing the following talks:
This will not be of interest to most of my readers, but one person did ask.
This is just to document how my system (which was built quite a few years ago) handles credit card payments via Westpac’s payment gateway, PayWay. The interface is rather dated and the way my system uses it is a bit hackish (in other words, this is not best practice!) but for what it’s worth: (more…)
For a number of years now I’ve been using LetsEncrypt to provide free SSL certificates for the APEX applications I provide. These certificates last for 90 days and are renewed automatically by a simple script on my server.
By the way – if you’re not already using https for your public-facing APEX applications, youshould, okay – even if your site doesn’t have data entry.
Each LetsEncrypt certificate can cover multiple subdomains. They don’t currently support wildcard domains (e.g. *.example.com) but they are planning to add this next year (2018).
To install LetsEncrypt I ran the following on my Amazon Linux instance (note – this is my web server, not my database server):
cd /opt
git clone http://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto -v --debug
(when prompted at the last step I typed “c” to cancel the subsequent steps)
It wasn’t easy at first because I got a number of errors which I’d google (or search the community forum) and eventually find reasonable answers. I’ve had to reinstall a number of times, as the OS is patched regularly and certbot is updated from time to time.
I use Apache to provide about a dozen virtual hosts and therefore the automated installation option didn’t work for me. Instead, I’ve got lines like these in each VirtualHost:
This generates all the keys and certificates and stores them locally. No private keys ever leave the server. This command is using SAN to combine multiple subdomains in one certificate. I run this command again separately for each domain.
To renew all my certificates I run the following command as root:
/opt/letsencrypt/letsencrypt-auto renew -n --no-self-upgrade
service httpd restart
This will automatically skip any certificates that are not yet due to expire. I’ve put the above script in a file which is run by cron on a monthly basis.
0 20 1 * * /path-to-script/renewall.sh
To get usage info on the options:
/opt/letsencrypt/letsencrypt-auto --help
Since it’s free, one cannot expect support from LetsEncrypt directly if there are issues; however, there is an active LetsEncrypt support community which can be helpful at times.
But it’s certainly made a big difference to my bottom line, and provided a bit of peace-of-mind to my users.
If you can get yourself to Perth in November, you must try to get to AUSOUG Connect. Here is my “Must See” list based on the current program (subject to change):
Lots of APEX goodies, a new (to me, at least) database IDE, plus plenty of solid Oracle database content – there’ll probably be a few conflicts leading to some decisions to make on the day.
I’m looking forward to a long-awaited return of the AUSOUG conference series – I hope to see you all there.
You’ve finished the design for an Apex application, and the manager asks you “when will you have it ready to test”. You resist the temptation to respond snarkily “how long is a piece of string” – which, by the way, is often the only appropriate answer if they ask for an estimate before the design work has started.
Since you have a design and a clear idea of what exactly this application will do, you can build a reasonable estimate of development time. The starting point is to break down the design into small chunks of discrete modules of work, where each chunk is something you can realistically estimate to take between half a day up to a maximum of three days. In cases where it’s something you haven’t done before, you can reduce uncertainty by creating a small Proof-of-Concept application or code snippet and seeing how the abstract ideas in the design might work in reality. This is where Apex comes in handy – by the time the design has completed, you’ll have a database schema (you created the schema in a tool like SQL Developer, didn’t you – so you can generate the DDL for that in a jiffy) and you can just point Apex to that and use the New Application wizard to create a simple application.
I plan all my projects using Trello, recording estimates using the Scrum for Trello extension. I don’t know much about the “Scrum” method but this extension allows me to assign “points” to each task (blue numbers on each card, with a total at the top of each list). I used to use a 1 point = 1 day (8 hours) convention, but I was finding most of the tasks were more fine grained (I was assigning 0.5 and 0.25 points to most tasks) so I’ve now switched to a convention of 1 point = 1 hour (more or less). In other words, I’d report my estimates with the assumption that my “velocity” would be 8 points per day.
(note: the blue numbers are the Scrum for Trello points, and the orange numbers are simply the number of cards in the list)
My points system looks roughly like this:
Simple report, form or process = 4 points
Complex report or form or process = 8 points
Very complex form or process = 24 points
Simple bug fix / tweak = 1 point
Complex bug fix / enhancement = 2 to 8 points depending on complexity
In addition to that, I keep a daily diary of work done in Evernote which has allowed me to do what I’ve wanted to do for a while now: measure my actuals vs. estimates for my projects, in order to calibrate my estimates for future projects. I made up a quick spreadsheet showing the development work for two projects, showing the original estimate, the start and finish dates, and actual development days worked (accurate roughly to the nearest half day, not counting non-development time like meetings and other project work). This allows me to see how my actual development time compares to my original estimates.
Since my reported estimates were roughly 8 points = 1 day, it seems I tend to underestimate. It may seem that my estimates are getting better (since my Points per Day is approaching 8), but that trend is more likely a result of SUM involving a lot less uncertainty and risk and being a smaller project overall. SAM was in a new environment and new client, whereas SUM is merely an additional application in the same environment for the same client. I was also able to re-use or adapt a lot of infrastructure-type code and Apex components from SAM in SUM.
The other thing that I can see from the details is that my “velocity” (points per day) is higher in the earlier stages of development, probably because I have plenty of work planned out, and I can work for several days in a row, uninterrupted by meetings and other distractions. In later stages, my attention gets divided by bug fixes, enhancement requests, meetings, doing design work for the next project, and general waiting-for-other-people-to-do-their-jobs.
For my next project I’ll estimate using the same points system as above, but factor in a 7 points-per-day to the estimates that I report.
Do you have a system of your own you use to create estimates and measure their accuracy? If not, why not try this for yourself? Do you keep track of your estimates and progress? If not, I recommend you start 🙂
I have Tom Kyte’s “Ask Tom” in my feed reader, and every now and then it opens for questions and the flood pours in. Quite often there is an interesting question, but more often than not there are quite a lot of “poor” questions: some just poorly worded, some too-easily-googleable, others are could-have-answered-from-the-docs questions. It’s not dissimilar to StackOverflow, which doesn’t suffer so much because of the army of people who work together to either improve or close these types of questions. Sometimes I think “Why did you waste Tom’s time with that? You could have googled it, searched the docs, or opened SO and you’d probably find a good answer there without even having to ask it.”
However, my impression is wrong, I think, because my feed reader only shows me the initial question, and not the detailed follow-up by Tom and others. I was reminded today of how a poor question can still lead to enlightenment, by this excellent quote by Tom:
As things grow and change over time – engineers need to use different approaches. The planes I fly in have wings that go straight out from the plane. That is because I fly at about 500 mph. A fighter jet at mach 2 would be going 1,500 mph. The wings on a fighter jet are significantly different in their architecture – because if they weren’t it wouldn’t work. We have different types of bridges in order to cross different types of chasms. We have different building styles for different types of builds (stick and brick for a 2 story house, steel girders in a frame for 30 story buildings).
As you scale up, the solutions that worked for trivial amounts of data will not necessarily work for large amounts of data.
If you are in a place that says “make it work but do not change code” – expect to have a bad day.
And, if you’re wondering how he keeps up with all this:
After 14 years on asktom and 20 years total (usenet news groups last century) answering tens of thousands of questions, I took a break from social media stuff.
What a great conference – there’s been a lot of praise for the organisers and all the speakers. I haven’t missed a conference since I started 15 years ago, and I hope it keeps going (in one form or another) for a long time to come.
This year I attended the following sessions (some titles changed for effect):
Björn Rost – 12c for DBAs and Developers; FDA (time to drop those journal triggers)
If you are interested, you can review the slides from my presentation here: Building Maintainable Applications in Apex. Whether or not you agree with all my points, I hope it at least makes you think 🙂
For a number of years now I’ve been using 
