Although Ollama and Llama.cpp are close relatives, the disparity API is significant enough to break the Cline functionality. Short research yielded two alternatives: an OpenAI-compatible API and an Anthropic-compatible API.

I have decided to start with the Anthropic option, but quickly gave up. Anthropic provider for Cline allows you to specify a custom model endpoint, but model names are pre-coded, and you can only choose one from the dropdown. Reasonably enough, my server container declines messages with an unknown model name.

Next try was for the "OpenAI Compatible" provider. This provider is fully customizable and can either retrieve the list of models registered on the server or allow you to specify any other model name.

Since I started the server with the GPT OSS argument --gpt-oss-20b-default, the model name for the Cline configuration is gpt-oss-20b. Another difference from Ollama, the OpenAI-compatible provider requires the API key. Use one if you define it through the server configuration, or put any value if your server is not protected.

Save the provider configuration, and select your new model for plans and acts.

There are no new takeaways or revelations:

• Local models, as good as your acceleration hardware. On the RTX3060, the 12 GB of video RAM drastically limits the size of models you can run and response speed.
• The same limits force the usage of smaller context windows, which makes your agent a little bit dimmer than its youngest relatives.
• Although the modern models do not demonstrate record speeds, the local model is more like a human; some answers take minutes to process and complete. Be patient.
• You may experiment with agents and skills, but you may want to keep your configuration files very lean.

With all that said, I keep my local agent for simple executions that do not require complex autonomy or deep reasoning and planning. Especially if you know the limitations and can deal with them.

I submitted 1 prompt that initially described the application I wanted, followed by 12 more follow-up prompts throughout the duration of the session for a total of 13 prompts. The session lasted an estimated 6-7 hours and the total cost was $28.9049 utilizing Anthropic Claude Sonnet 4.6 as the LLM (this model was released on February 17, 2026).

What I want to see is if modern day AI agents can design, develop, and deploy a 3-tier application to the cloud autonomously with little to no human intervention (hint: it can):

The current state of autonomous AI coding agents is honestly impressive. If you look at the software development lifecycle diagram below, the large majority of the steps were actually successfully performed by the AI agent.

So are we able to go from "idea" to "production" in a matter of hours? Yes, it's getting there.

A little of the prerequisite content below is reused from this blog post of mine which was an earlier attempt from a few days ago, but this post is a different example and a slightly better documented effort.

(Note: I use "Cline" and "AI agent" interchangeably in this post.)

What is Autonomous Code Generation?

Let's get a few concepts clarified first.

AI code generation is generally meant to refer to a developer's use of AI to assist in code generation through human prompting. The human (i.e., developer) types what he'd like to see, and the AI somehow automagically creates the code.

I use the term autonomous code generation where through the use of human prompts, an AI agent independently performs multiple steps of the software development lifecycle, including coding the application, building it (i.e., packaging it), and deploying it. The level of autonomy can become a topic of debate, which I'll shed some light on.

The following screenshot is one of the pages of the completed application. I deem the exercise a success. I could have continued engaging the AI agent to refine the application, enhance the look-and-feel even further, add more functionality, enable security, create separate non-production and production environments in the cloud, and so on. It would just take longer and cost more money.

What was I aiming for?

I remember coming across this table from Stride Conductor a couple of years ago that laid out the different levels of AI code automation. It's hard to believe that just two years ago we were floating around Level-2 Semi-Autonomous, and here we are today almost nearly reaching Level 5 Full Automation.

The purpose of this exercise is to see if we're able to reach automation Level 4 or even a Level 5 (note: it was a Level 4).

The entire development process was 100% autonomous, the build phase was 100% autonomous, and the deployment steps were 95% autonomous. Deployment included provisioning all Oracle Cloud Infrastructure (OCI) services and resources, creating sample data, inserting seed data into the database, downloading free-to-use images, installing an nginx reverse proxy and Gunicorn server, as well as deploying/configuring the Python application in a compute instance.

I provided minimal guidance to the AI agent on the design of the target cloud architecture. The only mandate was to store all data in an Oracle Autonomous AI Database and to try to use as many free tier services within OCI as possible.

Lots of bugs in the code and errors during deployment were encountered, but the AI agent worked through all of it on its own.

There were a couple of areas of confusion/conflict between me and the AI agent. For example, I had updated all the API token values in the terraform.tfvars early on in the process (this was practically the only manual step needed), but it was overwritten later when the AI agent started creating all the Terraform files. Also, I manually added a second approved sender in the Email Delivery service on the OCI console (to send out emails), and I'm guessing it would not have worked if I let the AI agent do it since there was a permission exception on the console and I had to use elevated access to perform this particular step.

But aside from these two manual interventions, the rest of the process was entirely autonomous.

Software Tools Used

In this exercise, I attempted to leverage certain tools to perform autonomous code generation. These multiple tools and services included:

1. Visual Studio Code (aka VS Code) - A lightweight, extensible source code editor (i.e., IDE) from Microsoft with a large ecosystem of extensions for many programming languages.
2. Cline - An open-source AI coding assistant that integrates with development environments such as VS Code to autonomously plan, write, modify, and run code using large language models such as Claude Sonnet.
3. Claude Sonnet - Anthropic’s best performance-value large language model (LLM) designed for reasoning, coding, and problem-solving tasks.
4. Oracle Cloud Infrastructure (aka OCI) - Oracle’s enterprise cloud platform that provides compute, storage, networking, databases, and AI services for building and running scalable applications.

Essentially the only software you need to download is VS Code to get started. Later on during development, other tools such as Terraform and various Python packages will be downloaded automatically by the AI agent.

Summary of Steps

This is a list of all activities performed, and each one is detailed below.

1. Create an API key to access the Claude models
2. Download and install VS Code
3. Install the Cline extension in VS Code
4. Set up your API provider and model in Cline
5. Create an empty project
6. Add a Cline rules files (optional)
7. Decide on auto-approve for the AI agent
8. Write an initial prompt to design your application
9. Ask the AI Agent (Cline) to create a "Plan"
10. Switch to "Act" mode for the AI agent to generate the code
11. Get the required API tokens from the OCI Console (manual step)
12. Let Cline provision the cloud resources autonomously
13. Manually verify the database objects (optional)
14. Test the application
15. Generate SMTP credentials (manual)
16. Create a cloud architecture diagram (optional)
17. Generate documentation summary (optional)
18. Shutdown the cloud servers to save money (optional)

1. Create an API key to access the Claude models

You will need to create an account on the Claude platform, create an API key, and purchase some credits. This API key will be con

1. Navigate to platform.claude.com and create a free account.

2. After logging in, click on "API Keys --> Create Key", give your key any name, click "Add", and copy the value of the API and store it somewhere (it will never be displayed again, so save it someplace safe!).

3. Click on "Settings --> Billing --> Buy credits" and purchase any amount of credits to start with (e.g., $10).

2. Download and install VS Code

Download and install the VS Code IDE. This is a straightforward process.

1. Navigate to code.visualstudio.com/download, then download and install the software.

3. Install the Cline extension in VS Code

Cline is an autonomous coding agent that is used inside VS Code and is available via an extension. Alternatives include Claude Code and Oracle Code Assist.

1. Open VS Code.
2. Click on the "Extensions" button on the left.
3. Search for "cline".
4. Click on "Install".

Cline is now ready for use.

4. Set up your API provider and model in Cline

Now that Cline is installed, it's not still ready for use. Cline relies on a 3rd party LLM model of your choice. Now that we've created an API key within Claude from earlier, we will use those values here.

1. If the Cline sidebar is not showing in VS Code, click on the Toggle Secondary Side Bar button on the top right or click CTRL+ALT+B.
2. Click on the Settings icon.
3. Select "Anthropic" as the API Provider.
4. Enter the API key that you created in the Claude platform console.
5. Select a model such as "claude-sonnet-4.6".

Now Cline, your AI chatbot and agent, is ready for use!

5. Create an empty project

Start with an empty project.

1. Click on "File".
2. Click on "Open Folder" and select an empty folder on your local file system.

6. Add a Cline rules files (optional)

Cline rules files are markdown documents (.md files) that define persistent instructions and coding standards for Cline, stored in the /.clinerules directory to maintain consistent behavior across sessions.

Cline rules serve as a persistent memory for Cline, which otherwise resets completely between sessions, ensuring consistent behavior and adherence to project-specific standards.

1. Create a subfolder in your project called .clinerules.
2. Create one or more filenames (e.g., coding.md, testing.md) and in plain English describe the rules for your standards.

Below is a single rules files that I created with some basic rules. If you are using a specific programming language, you can be more specific in your rules and coding standards.

7. Decide on auto-approve for the AI agent

Before you start engaging with Cline (by pressing the play button, highlighted in red), note the sections highlighted in blue first.

It's important to understand a few things.

Plan or Act?

Typically, you want to select "Plan" first. Cline here generates a step-by-step strategy and it doesn't actually do anything. It will not create any code. It will not perform any actions. It will simply present you with a proposed plan of what it intends on doing. This allows you to refine your design before asking the AI agent to implement it.

With Plan:

• No changes are made.
• No files are edited.
• No commands are executed.

Agentic AI systems can be dangerous if they act immediately. Plan gives you a preview of the AI's reasoning and intended actions.

In Act mode, Cline executes the plan.

It will read and edit files, run terminal commands, download and install dependencies, run builds, create and update code, and so on.

Auto-approve or not?

Auto-approve controls whether the developer must approve each operation during Act mode.

If auto-approve is on, as shown in the last figure above, Cline will automatically perform certain actions without asking. It is not unusual to be asked for hundreds of approvals in a single session, so setting auto-approve may seem tempting, but it obviously comes with its risks.

In this exercise, I had set auto-approve on every action; reading files, editing files, and executing commands.

8. Write an initial prompt to design your application

In a text editor, start by creating a prompt of the application. Here is the prompt I spent time writing for my "Presidents of the United States" application.

1. PROJECT NAME: "Presidents of the United States"

Act as an expert Full-Stack Cloud Architect and Python Developer. Your goal is to build a modern, serverless web application deployed on Oracle Cloud Infrastructure (OCI) using Python.

2 GOAL:
- Create a simple, modern, visually impressive web application that provides basic information of all presidents of the United States of America.

3. FUNCTIONAL REQUIREMENTS:
- The web application will be called "Presidents of the United States".
- The web application should use a modern, responsive UI.
- The web application should default to a dark mode style, but provide the ability to switch to a light style.
- The welcome page of the application should be a simple welcome page, where the user clicks on "Enter" or something like that to enter the application.
- The second page should be a gallery of every single president. Every president should have a professional looking, flattering photo.
- Each president will have a tag line under it, giving an impression of that president.
- There should be a thumbs up and a thumbs down icon. Clicking on the thumbs up icon will show a popup with text that describes a notable or impressive feat this president has done. Clicking on the thumbs down icon will show a popup with text that describes a major failing or shameful act that this present has done.
- There should be an option to click on the president to take it to a detailed page of the president.
- The detailed page should provide at least a page of details of each president. On this page, there should be a mail icon, where clicking it will popup a field that requests an email address, and the details of the president will be emailed to that email address.

4. NON-FUNCTIONAL REQUIREMENTS
- The web application should use a modern and stylistic CSS template.
- None of the pages requires authentication, so all pages are publicly accessible.
- The web application will be deployed to Oracle Cloud Infrastructure (OCI).
- Emails should be sent in HTML format using the OCI Email Delivery service.
- On the bottom of each page will be a footer that states "© 2026 Path Infotech LLC".
- Include Terraform scripts to automatically provision all required infrastructure. 
- Any combination of services is acceptable, but the simpler the architecture, the better.
- The web application should be developed in Python.
- Provide test cases and instructions on how to run the test cases.
- The code should include comments describing some information throughout the code.
- Detailed instructions to create the infrastructure within OCI should be provided.
- Detailed instructions to deploy the web application to OCI should be provided.
- Include anything relevant you think should be added.
- The web application should be publicly accessible.
- The database should be Oracle Autonomous Database in OCI that stores the details of each president.
- Use a serverless architecture as much as possible.
- All OCI services provisioned should include a tag with a tag name of "webapp" and value "uspresidents".
- Use free tier services within OCI whenever possible.
- Provide instructions on how to install, setup, and execute the Infrastructure-as-Code scripts.
- Provide instructions to setting up the public/private RSA key pair on the client host where Terraform will be executed.
- Provide instructions on where to place the Terraform configuration file information returned from the OCI console.
- I want you create the public/private key pair, and after I upload the public key to the OCI console, I will update "terraform.tfvars", afterwards I want you to perform all provisioning, deployment, and testing fully autonomously on your own.

In an ideal scenario, I would be much more specific in my functional requirements, dictating navigation paths, grid layout, text I wanted to see, and so on. I would also add more technical requirements, detailing the language, services, and frameworks I want to use, add any restrictions and constraints, and so on.

Some people like starting with a light prompt as you see above, and continue engaging the AI agent to continue refining it, while others (such as myself) prefer spending the effort up front to be as specific as possible.

5. Ask the AI agent (Cline) to create a "Plan"

Now that the prompt is created, it's time to submit it to Cline.

1. Paste the entire prompt in the box.
2. Click on "Plan".
3. Click on the play button.

Cline will take several minutes and start spitting out output. Up until this point, the cost was $0.0801.

Scrolling down through the output, I can see all the services that Cline intends on using.

WARNING: The brief text architecture in the last image was not the final architecture that Cline actually used. At some point it decided to go a different route when it ran started running into deployment errors during execution.

Cline stated that it would use the API Gateway, Functions, Object Storage, and Container Registry. None of these were used in the end.

Cline laid out the entire project structure. Remember, none of this has been created yet.

At the end of the output, Cline wanted me to confirm a few things:

I responded with the following:

1. OCI Region: us-ashburn-1
2. I already have an OCI tenancy/account already set up.
3. Email address should be "noreply@revelationtech.com". Please provide instructions on how to verify the domain in OCI Email Delivery, or if you can automate it with Terraform that would be better.
4. I prefer Flask.

Now that Cline had its answers, it summarized the execution plan. Very few of the steps needed to be done manually as I had requested:

But I then noticed that Cline suggested doing a remote HTTP reference to the images. Basically, it wanted to hyperlink the images to Wikemedia directly, and I didn't want that. So I asked it the following:

One more thing. I want all images hosted locally, and the local images referenced by URL in the database. I do not want to link to the publicly available Wikimedia Commons URLs.

After which Cline said that it would create a download script in Python to eventually do just that:

The total final cost of the Plan phase was $0.1783 using Claude Sonnet 4.6 and took 16 minutes and 47 seconds. This included the time it took for me to respond with my follow-up prompts.

Remember, none of the above had been created up until this point.

10. Switch to "Act" mode for the AI agent to generate the code

Now that I've reviewed the plan, it's time to "Act", or execute the plan.

1. Click on the "Act" button.
2. If nothing happens, type a message like "Act" and click on the play button.

For the next several hours, or however long it takes, Cline will start creating all files. I asked it to create the public/private key pair for me, which it did. I needed this in order to get the API tokens from the OCI console. These tokens will later be added to the Terraform configuration files so that it can provision the cloud services.

I see here that the public key was created. That's exactly what I needed.

2. Copy the public key.

11. Get the required API tokens from the OCI Console (manual step)

Now that the public key was created on my local machine, I need to paste it in the OCI console to get all my API tokens. These tokens will eventually be saved into my local client so that Cline can run the Terraform scripts to create my cloud resources.

1. Login to the your cloud.oracle.com account.
2. Click on the profile icon.
3. Click on "User settings".
4. Navigate to the "Tokens and keys" subtab.
5. Click on "Add API key".

6. Select "Paste a public key", paste the key, and submit.

7. Copy all these values, as they will be needed later.

8. Now under the /terraform folder in VS Code, create a file called terraform.tfvars and paste your values as shown. You will need to add your Compartment ID as well.

WARNING: This file was overwritten later on when Cline started created all the files. So I had to redo this step later.

Why does Cline hang sometimes?

Every so often, Cline would appear to hang. It looks like it's still "Thinking..." but there is no indication of activity. Even submitting a prompt does nothing.

It is safe to click on "Cancel" and then "Resume Task". But more often than not, it's not hung and it's just the model thinking and reasoning behind the scenes. Don't be surprised with having to wait an hour plus to see some activity.

Also, every now and then you may run out of tokens and receive this message.

Simply login to the Claude platform at platform.claude.com and purchase some credits. Though it may look it, it won't be made available immediately, so come back an hour later before trying to continue.

12. Let Cline provision the cloud resources autonomously

Cline will continue creating all the files in the project (155 of them total!). Depending on the complexity of your project and the model you've chosen, times may vary. The good thing is that on the top of the chat window you can see a list of the main tasks.

1. Let Cline continue working.
2. Observe the status on the top of the Cline chatbar until you see that all tasks have been completed (as shown in the following snippet).

Every now and then, Cline may ask you a question such as the following. In most cases, accepting the answer is acceptable.

After my 8 tasks were completed, I wasn't sure whether the cloud services and resources were created by Cline (i.e., Did Cline run the Terraform scripts to create all the cloud resources?). I do recall that in the Plan phase, it said that I needed to run it manually, but there's no harm in asking my AI agent:

Is the cloud infrastructure provisioned (i.e., did you run the Terraform scripts to create all resources in the cloud)?

Cline confirmed that it had not run it, and gave me three options to choose from. I did not select any one of those options (yet).

That's because I noticed that my terraform.tfvars file was overwritten. So I went and re-pasted my API token values again and saved the file.

But what value should I use for the compute SSH key that was in the file (not shown above)? Let's ask Cline!

Where do I get the "Compute SSH key" from? It is a required value in "terraform.tfvars"?

Cline decided to figure it out and do it all itself, thankfully.

After about 5 minutes, it finally got the key.

Now here is the part where all it needed to do was to copy the key from the terminal and paste it into the terraform.tfvars configuration file. This led to incredible struggles by the AI agent. It had issues with Windows wrapping the string, faced challenges with special characters, and so on. After struggling for quite some time, Cline finally decided to write a whole Python script just to copy the key value from the terminal prompt and paste it into the configuration file. But it worked, and that's what mattered. I could have saved 15 minutes of AI thinking if I just copied and pasted it myself though.

Cline then decided to mess everything up and must have created a new private key or something. Who knows. Because the Terraform script wasn't authenticating. So I just followed its lead and answered its questions when it asked me to check certain values in the OCI console.

It eventually worked in the end. Yes, it did in fact create a new private key for some odd reason.

Cline continued proceeding with running the Terraform scripts via terraform apply and observing the output. In the following screenshot, it seems it ran into an issue. In this case, it tried to use a feature that was not available in the free tier of the Oracle Autonomous AI Database, so it updated the script to remove this feature.

Keep in mind that these are merely a few glimpses into the issues that Cline experienced (there were many!), but it worked through them all autonomously and rarely needed my input.

Though the Terraform scripts were completed, as you can see in the following screenshot, it did give me a public URL of the application. The cloud resources were now fully provisioned, but the application was actually not deployed yet.

That is where Cline began a lengthy process of installing nginx, Gunicorn, and deploying my Python Flask application onto a compute instance. The following screenshot is just a progress point.

At this time, I must have missed why Cline decided to switch up the architecture that it had originally planned. Instead of deploying the code onto a serverless OCI Function fronted by an API Gateway, it decided drop those and deploy the application on a compute instance instead.

Here is another issue where Cline tried to connect to the database but failed. However, after 15 minutes of autonomous troubleshooting, it was successful in the end.

It now was able to successfully connect to the database!

Cline wanted to insert the seeded data, but ran into yet another issue. Apparently, in the CREATE TABLE script, it named one of the columns "number" but NUMBER is a reserved word in the database. As with all other errors, it managed to rewrite the script, and retry the process again.

13. Manually verify the database objects (optional)

I wanted to verify and make sure that the database objects and data were in the database. The Oracle Autonomous AI Database in the OCI console gives you the ability to run SQL statements against the database. Here you can see that all was good.

One of my requirements was to tag every cloud resource with a custom name:value pair of webapp:uspresidents. You can see that the database has this tag.

I was able to confirm that my compute instance also had the tag.

14. Test the application

Cline gave me a link to the public IP address and here's the final application. It looked professional, sharp, clean, and modern. I was impressed.

I told Cline about that the images were not showing up. This is what I said:

When I navigate to http://157.151.235.148, everything works fine. However, none of the portraits for the presidents are showing up. It seems that the direct URL of the images are all "http://157.151.235.148/static/images/presidents/placeholder.jpg" which appears to be a placeholder.

Cline had issues linking to, and even downloading, approved for-use images from Wikimedia. Cline finally found out that Wikimedia places restrictions on robots and had rate limits. It tried using their API to get the images, but was unsuccessful.

So Cline ended up putting placeholders initials as you see here.

All my requirements were satisfied and the application was working as expected (mostly).

Though Cline had already run its test cases, I wanted to run the full suite of tests manually myself, so I opened up TESTING.md document the instructions stated that all I needed to do was simply type pytest in the terminal window.

All test cases that Cline had created passed.

15. Generate SMTP credentials (manual)

The email functionality in the application wasn't working though. I would get an error on the web page when I submitted my email address. So I let Cline know:

When I try to send the email, upon clicking on "Send Details", I receive the error "Failed to send email. Please try again later."

Cline offered some suggestions:

The problem is, these steps were not accurate. The suggested navigation in the OCI console didn't exist and I couldn't find where to generate the SMTP credentials.

I referred to the Oracle documentation. And guess what? It wasn't accurate either. I wasn't sure what was going on. But at least Cline was consistent with the Oracle documentation.

So I asked ChatGPT. Now the instructions from ChatGPT weren't exact or perfect either, but it had the right idea. As ChatGPT suspected, I was indeed using the newer Identity Domains, and I was finally able to generate the SMTP credentials.

Here's the page on the OCI console where the SMTP credential was finally created.

It still wasn't working, so Cline stated that I had to add an approved sender in the OCI console, and gave me the appropriate instructions to do so.

The approved sender was added on the OCI console, and I manually added my tag as well as shown.

Now when I submit my email address in the web application, I no longer received an error. But did I actually receive the email?

The OCI Email Delivery service seemed to confirm that 1 email was received by the service and 1 email was relayed, so that was a good sign.

The email was actually in my Spam folder, and the resulting output was very nice.

16. Refine the application (optional)

I still wasn't happy with the fact that I had placeholder initials in lieu of official portraits of the presidents. I know Cline had spent a significant amount of time trying to pull them from Wikimedia (unsuccessfully), but I made this request nonetheless:

I don't like the current placeholder for the portraits which just shows the initials of each president. Are there alternate resources you can use to get actual portrait photos of each president?

After much churning, somehow, somewhere, Cline was able to get some photos and it was looking great as you can see!

And here's the detail page.

16. Create a cloud architecture diagram (optional)

Now, when Cline was in the Act phase executing the Plan that we had developed together, I noticed that it really didn't follow the original Plan, specifically in regards to the cloud architecture. I know this because as I was observing the AI agent perform its actions over the course of two hours, I noticed it was constantly pushing code to a compute instance, but there was no mention of a compute instance in the original plan.

So here I asked Cline to generate an architecture diagram for me using OCI format standards:

Create a custom architecture diagram that shows the cloud architecture in place and its components/services/resources. It should follow the standard OCI format and service icons as documented here: https://docs.oracle.com/en-us/iaas/Content/General/Reference/graphicsfordiagrams.htm

This was the final architecture. It wasn't what I would consider a pretty "cloud" architecture diagram, as it included details often not found in these types of diagrams, but it provided sufficient detail for me to understand the overall design.

I preferred the original architecture, and I suppose I could have insisted that it re-architect the entire application to go full serverless, leveraging OCI Functions and add an API Gateway to front the application. But I didn't go that route.

17. Generate documentation summary (optional)

There's unfortunately no way to export the entire chat history with Cline. It would be incredibly useful to go through all the actions that Cline took offline. That way, I'd know exactly what the AI agent performed.

So my other best option is to ask it to generate something:

Export this entire chat session, maintaining all formatting and include all responses, and save it in an HTML file under the /docs folder. Additionally, include a section with some basic statistics such as total number of files in the project, frameworks used, OCI services used, patterns used, total session duration, and other relevant metrics. Include results of the testing. Includes key errors and steps to resolve them. Also include suggested future recommendations.

Cline generated a detailed export, but it's more of a session summary than a word-for-word chat export. This summary was still incredibly useful.

18. Shutdown the cloud servers to save money (optional)

Cline based the cloud design on a single compute instance and a single Autonomous AI Database. When browsing the OCI console, I was able to confirm that the database was indeed the free tier option, so I would not be paying anything for it. However, I had noticed during the Act phase that Cline was unsuccessful trying to start up the free tier compute instance, likely because I exhausted my free tier limits.

So after testing, I asked Cline to:

Shutdown the compute instance and the database instance.

Not only did the AI agent get the resource OCIDs from the Terraform state file to shut them both down, but it also created a companion start_oci_resources.py script so that I can easily restart them later.

Even better, when the VM is up, Cline mentioned that the services would auto-start.

Conclusion & Final Thoughts

This effort took quite a while, but not as long as it would have taken had I programmed it all from scratch. This may have taken me anywhere from 20-40 hours to complete manually.

What was the total duration of the session, minus all the wait times of inactivity caused by me? Provide a response in hours and minutes.

Cline estimated the net active AI working time to be 9 hours and 29 minutes, in addition to 52 minutes of human "wait" times, but I don't believe this to be accurate. There was probably a 3 hour pause caused by me as I went out to dinner and putting the kids to bed when I came back. So my rough duration estimate would be 6-7 hours instead.

Though I tout Cline as being "autonomous", it really operates on a permission-based model (i.e., it won't do anything unexpected). The human/developer still needs to approve most actions, unless you decide to auto-approve everything like I did.

One of the biggest risks of fully autonomous code creation is the loss of developer control (I have a whole post on AI code generation risks and mitigations worth reading). As I let the AI agent loose, it created code, encountered errors, troubleshooted the errors, fixed the bugs, and repeated the process hundreds of times. Given that I let the AI agent select the development framework and design the architecture, as time passed, I starting becoming unaware of what it was doing. This was partly due to me keeping auto-approve on, mostly because I didn't want to spend another two days reviewing and validating every single change the AI agent wanted to do before approving it.

Also, 2026 is the year of the MCP Server. I mention nothing of MCP Servers this time around, but stay tuned for a future post.

In conclusion, there are a very few important things worth noting:

• Use AI agents whenever you can during your programming sessions. AI agents (like Cline) are powerful, so don't hesitate taking advantage of them. Ask it to clarify items, refine the code, or perform mundane manual steps for you.
• AI agents can save you an unbelievable amount of time. It can easily reduce the time it would take a human to manually troubleshoot and resolve issues by 99%. It is truly amazing.
• Repeating the same set of instructions will likely not yield the same output. That's because current generative AI models are non-deterministic. AI models will usually produce different outputs even if the input is exactly the same each time. My application above will likely look drastically different if I repeated the same exercise again.
• The AI agent can seem to work in circles when trying to resolve simple problems. But it goes about it methodically and eventually finds a fix.
• AI agents but can be dangerous. Here's a recent article on how an AI agent deleted Meta's AI Alignment Director's entire email inbox irrecoverably.
• Auto-approve is exceptionally dangerous. It is not recommended, though it would take considerably more time to review every proposed course of action by the AI agent.

Try the app here as long while it stays up: http://pathinfotech.app/

What is Autonomous Code Generation?

Let's get a few concepts clarified first.

AI code generation is generally meant to refer to a developer's use of AI to assist in code generation through human prompting. The human (i.e., developer) types what he'd like to see, and the AI somehow automagically creates the code.

I use the term autonomous code generation where, through the use of human prompts, an AI agent independently performs multiple steps of the software development lifecycle, including coding the application, building it (i.e., packaging it), and deploying it.

In this exercise, I attempted to leverage certain tools to perform autonomous code generation.

The following screenshot is one of the pages of the completed application. The effort was eventually a success. Had I spent more time on it, I would have continued to refine it, improved the look-and-feel, added more functionality, created separate non-production and production environments in the cloud, and so on.

Conclusion

This is a rather lengthy post, going into semi-detail of what I went through creating a simple e-commerce web application. But let me start by summarizing my experience:

Software Tools Used

This effort I embarked on relied on multiple tools and services.

1. Visual Studio Code (aka VS Code) - A lightweight, extensible source code editor (i.e., IDE) from Microsoft with a large ecosystem of extensions for many programming languages.
2. Cline - An open-source AI coding assistant that integrates with development environments such as VS Code to autonomously plan, write, modify, and run code using large language models such as Claude Opus.
3. Claude Opus - Anthropic’s most capable large language model (LLM) designed for advanced reasoning, coding, and complex problem-solving tasks.
4. Oracle Cloud Infrastructure (aka OCI) - Oracle’s enterprise cloud platform that provides compute, storage, networking, databases, and AI services for building and running scalable applications.

Essentially the only software you need to download is VS Code. Later on during development, other tools such as Terraform and the OCI CLI and various Python packages will be downloaded by the AI agent.

1. Create an API key for Claude Opus

You will need to create an account on the Claude platform, create an API key, and purchase some credits. This API key will be con

1. Navigate to platform.claude.com and create a free account.

2. After logging in, click on "API Keys --> Create Key", give your key any name, click "Add", and copy the value of the API and store it somewhere (it will never be displayed again, so save it someplace safe!).

3. Click on "Settings --> Billing --> Buy credits" and purchase any amount of credits to start with (e.g., $10).

2. Download and Install VS Code

Download and install VS Code. It is a straightforward process.

1. Navigate to code.visualstudio.com/download, download, and install the software.

3. Install the Cline Extension in VS Code

Cline is an autonomous coding agent that is used inside VS Code and is available via an extension. Alternatives include Claude Code and Oracle Code Assist.

1. Open VS Code.
2. Click on the "Extensions" button on the left.
3. Search for "cline".
4. Click on "Install".

Cline is now ready for use.

4. Configure the Model in Cline

Now that Cline is installed, it is not still ready for use. Cline relies on a 3rd party LLM model of your choice. Now that we've created an API key within Claude, we will use those values here.

1. If the Cline sidebar is not showing in VS Code, click on the Toggle Secondary Side Bar button on the top right or click CTRL+ALT+B.
2. Click on the Settings icon.
3. Select "Anthropic" as the API Provider.
4. Enter the API key that you created in the Claude platform console.
5. Select a model such as "claude-sonnet-4.6".

Now Cline is ready for use!

5. Create a First Draft of Your Prompt

In a text editor, start by creating a prompt of the application. Here is the prompt I created.

I want you to create a web application for me.

The details of this web application are as follows:
* The web application will be called "My Comic Book Collection".
* The web application should use a modern, responsive UI.
* The web application should use a CSS template or style similar to what is found on https://github.com/projects.
* None of the pages requires authentication, so all pages are publicly accessible.
* The web application is intended to list my comic book collection.
* Every comic book series has one or more issues (for example, the series name could be "Amazing Spider-Man volume 2" of which I only own issues 10-20).
* Each series has a price. Individual issues are not sold separately. Only entire series can be sold.
* Users can add or remove series from their cart.
* The IDE is Visual Studio Code.
* The extension being used is Cline.
* The API provider is Anthropic.
* The model is Claude Opus 4.6.
* A list of all series should be shown. Each series should display the cover of the first issue of the series, alongside the title and issues numbers owned. The user can simply add the series to the cart from here.
* The user can click on a series, after which they are taken to a page showing the cover of each comic book in the series, it's issue number, and condition (Mint, Near Mint, Very Fine, Fine, Very Good, Good, Fair, Poor).
* The web application should have an impressive home page, with impressive graphics and images that appeal to the typical comic book buyer. Generate any images needed for this page.
* When the user chooses to check out, it will send him a list of his cart in table format in an HTML email using the Oracle Cloud Infrastructure (OCI) Email Delivery service, after which his cart is cleared.
* Each page will have a logo on it. Create a new custom logo for this.
* On the bottom of each page will be a footer that states "© 2025 Ahmed Aboulnaga".
* The web application will be deployed to Oracle Cloud Infrastructure (OCI).
* Include Terraform scripts to automatically provision all required infrastructure.
* Any combination of services is acceptable, but the simpler the architecture, the better.
* The web application should be developed in Python.
* Provide test cases and instructions on how to run the test cases.
* The code should include comments describing some information throughout the code.
* Detailed instructions to create the infrastructure within OCI should be provided.
* Detailed instructions to deploy the web application to OCI should be provided.
* Include anything relevant you think should be added.
* The web application should be publicly accessible.
* The database should be Oracle Autonomous Database in OCI.
* All data should be stored in the Oracle Autonomous Database.
* Use a serverless architecture as much as possible.
* Provide instructions on how to install, setup, and execute the Infrastructure-as-Code scripts.
* Provide instructions to setting up the public/private RSA key pair on the client host where Terraform will be executed.
* Provide instructions on where to place the Terraform configuration file information returned from the OCI console.

This prompt covers, to the best of my experience, what I'm looking for in the application.

The quality of the output will only be as good as my prompt. The more details and specifics I add to the prompt, the less guessing the LLM has to do.

6. Use Meta Prompting to Improve the Prompt

Now that your prompt is mostly ready, let's use meta prompting to refine it. Meta prompting is a prompt engineering technique in generative AI where you ask a chatbot (such as ChatGPT or Gemini) to help you in creating a prompt.

In this case, my prompt is mostly ready, but we need some assistance improving it.

ROLE: <<< I am a web developer. >>>

CONTEXT: <<< I need help creating a prompt to use in my AI code generator.>>>

EXPECTATION: <<< I want you to create me a prompt that I will use in my AI coding agent (Cline) to create a web application for me. Refine the prompt and make sure it is detailed enough to produce a high quality output.

---paste the entire prompt above here---

>>>

Depending on which chatbot you use, the output could be drastically different, but it will nonetheless be an improvement and made more specific to AI coding agent.

This is the updated prompt generated by Gemini:

# Project Name: "My Comic Book Collection" Web Application

Act as an expert Full-Stack Cloud Architect and Python Developer. Your goal is to build a modern, serverless web application deployed on Oracle Cloud Infrastructure (OCI) using Python.

## 1. Tech Stack & Architecture
- **Backend:** Python (Flask or FastAPI) deployed via OCI Functions (Serverless).
- **Frontend:** Responsive UI using HTML5/JS/CSS, styled with a professional "GitHub Projects" aesthetic (clean grids, muted borders, high-contrast labels).
- **Database:** Oracle Autonomous Database (Serverless).
- **Infrastructure:** Terraform for all OCI resources.
- **Email Service:** OCI Email Delivery via SMTP/SDK.
- **Hosting:** OCI Object Storage (Static Frontend) or OCI API Gateway + Functions.

## 2. Functional Requirements
- **Home Page:** A high-impact landing page with comic-themed hero graphics. Generate a custom SVG/CSS logo for "My Comic Book Collection".
- **Gallery View:** List all comic series. Display: First issue cover image, Title, Issue range (e.g., 10-20), and Price. Include a "Quick Add to Cart" button.
- **Series Detail Page:** Display a grid of all individual issues in a series with cover images, issue numbers, and condition ratings (Mint to Poor).
- **Cart & Checkout:** - No authentication required.
    - Persistent cart (Session or LocalStorage).
    - Checkout triggers an HTML email via OCI Email Delivery containing a formatted <table> of the items.
    - Clear cart post-checkout.
- **Footer:** Must include "© 2025 Path Infotech LLC" on every page.

## 3. Infrastructure & DevOps (Terraform)
Provide complete Terraform scripts to:
- Provision a VCN and necessary subnets.
- Spin up an Oracle Autonomous Database.
- Configure OCI Email Delivery and approved senders.
- Deploy the Python application code to OCI Functions.
- Set up API Gateway to route traffic to the functions.

## 4. Documentation & Setup Instructions
Please provide the following in separate Markdown files:
- **Client Setup:** Instructions for generating RSA Key Pairs (PEM format) and configuring the OCI CLI/Terraform provider.
- **Terraform Execution:** Where to place the `tenancy_ocid`, `user_ocid`, and `fingerprint` from the OCI Console.
- **Deployment:** Step-by-step guide to `terraform init`, `apply`, and deploying the Python code.
- **Testing:** Provide a `pytest` suite and instructions for running integration tests against the API.
- **Sample Data:** Create sample data and sample images.

## 5. Design Guidelines
- Use a "GitHub-like" UI: San-serif fonts, `#f6f8fa` backgrounds, and rounded card borders.
- Code must be heavily commented for educational purposes.
- Ensure all OCI resources are within the Free Tier limits where possible.

This is the prompt that will eventually be used in Cline.

Note here that I did not define the target architecture in the cloud aside from the use of the Oracle Autonomous Database and OCI Email Delivery services. Everything else is up to the AI agent to choose.

7. Submit the Prompt to Cline to Create the Application

Copy the entire prompt from earlier, and back within VS Code, paste it in the prompt.

1. In VS Code, open a new, empty folder to host your project files (in this example, I had an empty folder called comic-collection).
2. Paste the prompt.
3. Click on the play button highlighted in red.

But before you do, note the sections highlighted in blue. It's important to know a few things:

Plan or Act?

Typically, you want to select "Plan" first. Cline here generates a step-by-step strategy and it doesn't actually do anything. It will not create any code. It will not perform any actions. It will simply create a plan.

With Plan:

• No changes are made.
• No files are edited.
• No commands are executed.

Agentic AI systems can be dangerous if they act immediately. Plan gives you a preview of the AI's reasoning and intended actions.

In Act mode, Cline executes the plan.

It will read and edit files, run terminal commands, download and install dependencies, run builds, create and update code, and so on.

Auto-approve or not?

Auto-approve controls whether the developer must approve each operation during Act mode.

If auto-approve is on, as shown in the figure above, Cline will automatically perform certain actions without asking. It is not unusual to be asked for hundreds of approvals in a single session, so setting auto-approve may seem like the ideal choice, but it comes with its risks obviously.

Here's a screenshot of one of the SVG images that it created as part of the sample data generation:

8. Review Documentation Upon Completion

In my little exercise here, I set auto-approve to on and I set it to Act immediately, bypassing the Plan phase. It still performs the planning, but it just doesn't wait for my review.

After a few hours with some back and forth with the AI agent, my entire codebase is generated. Test cases were created. Documentation was written. Everything is ready to go. All this, and I don't even know what the underlying architecture is.

There was a well written README.md file that provided a high-level details, shown here.

This is the diagram it generated in SVG format. Cline (via the Claude Opus LLM) exceeded my expectations in the design of the cloud architecture. It decided on:

• Object Storage to hold all frontend static files
• API Gateway as a proxy to the backend web services
• OCI Functions to host the webservers
• Container Registry to host the container artifacts
• Autonomous Database, since I requested all data to be stored in it
• OCI Email Service, since I requested it to be used
• All VCN/networking and IAM Policy setup

It also delivered a ~/docs subfolder which included even more documentation. Now to get this application deployed, I just need to go through the 01, 02, and 03 documents.

9. Testing the Application Locally

Cline started up application locally, with the frontend running on http://localhost:3000 and the backend Flask application running on http://localhost:8080. Here, you can see that it started both the HTTP server and the Flask server. But where's the database on my localhost?

But the images weren't rendering correctly, so Cline spent some time troubleshooting to try to figure out why that was so. Here is an example of one of the troubleshooting steps (opening the file locally first).

Cline stated that the root cause was that Python's built-in http.server on Windows serves SVG files with an incorrect MIME type (due to Windows registry MIME mappings), causing browsers to reject them. Anyway, it fixed it.

I manually ran the test cases using pytest, as indicated in the documentation, but I received an error indicating that the command was not recognized (see the first line in the following screenshot).

Cline executed the command to install pytest, ran through the test cases (21 passed, 2 failed), then proceeded to fix the code related to the two failed test cases.

9. Manually Running Terraform

I had originally requested Cline to use Terraform for infrastructure provisioning. It created all the Terraform .tf scripts for me, but I won't be able to run them unless I perform the following:

1. Install Terraform, openssl, and the OCI client on my host machine (i.e., my laptop).
2. Populate certain cloud credentials in the terraform.tfvars files.
3. Generate the public/private key pairs.

Full instructions were included in the readme files that were generated, but the execution wasn't flawless. I followed the instructions to create my key pairs:

I ran into issues installing the OCI client and used a combination of Google and Cline to figure it out. One of the issues was some Window execution policy thingie.

The 02-TERRAFORM-CONFIG.md file provided me all instructions and mentioned what values it needed from the OCI console:

But I ran into more issues running Terraform where I had to prompt Cline multiple times for assistance. Here are some of my prompts:

1. The command Cline provided to install Terraform didn't work.

When the command "choco install terraform" in Windows, I got this error: "choco : The term 'choco' is not recognized as the name of a cmdlet, function,"

2. Creating the API Gateway failed.

I received this error when running "terraform apply": <<<oci_apigateway_deployment.comic_api: Creating...
╷
│ Error: 400-InvalidParameter, Invalid specification.routes[0].backend.functionId: should be an ocid of type fnfunc
│ Suggestion: Please update the parameter(s) in the Terraform config as per error message Invalid specification.routes[0].backend.functionId: should be an ocid of type fnfunc
│ Documentation: https://registry.terraform.io/providers/oracle/oci/latest/docs/resources/apigateway_deployment
│ API Reference:
│ Request Target: POST https://apigateway.us-ashburn-1.oci.oraclecloud.com/20190501/deployments
│ Provider version: 8.4.0, released on 2026-03-04.
│ Service: Apigateway Deployment
│ Operation Name: CreateDeployment
│ OPC request ID: 4ff0aad05a433a0933724dd6659936c4/7C0155C4A9B1B2C22297AB694941449E/EC5637563A0E838E979FEB6C3D7C0DD0>>>

3. It seems that there is a minor bug in the Terraform script to create the Autonomous Database. It fixed it automatically and asked me to try again.

When I ran the command "terraform apply" I received the following error: <<< Error: Unsupported attribute
│
│ on adb.tf line 26, in resource "oci_database_autonomous_database" "comic_adb":
│ 26: data_storage_size_in_gbs,
│
│ This object has no argument, nested block, or exported attribute named
│ "data_storage_size_in_gbs". Did you mean "data_storage_size_in_gb"? >>>

4. Another problem create the OCI Function.

When I ran the command "terraform apply" I received the following error: <<< oci_functions_function.comic_function: Creating...
╷
│ Error: 400-InvalidParameter, Invalid Image us-ashburn-1.ocir.io/raastechinc/comic-collection/comic-api:0.0.1 does not exist or you do not have access to use it
│ Suggestion: Please update the parameter(s) in the Terraform config as per error message Invalid Image us-ashburn-1.ocir.io/raastechinc/comic-collection/comic-api:0.0.1 does not exist or you do not have access to use it
│ Documentation: https://registry.terraform.io/providers/oracle/oci/latest/docs/resources/functions_function
│ API Reference: https://docs.oracle.com/iaas/api/#/en/functions/20181201/Function/CreateFunction
│ Request Target: POST https://functions.us-ashburn-1.oci.oraclecloud.com/20181201/functions
│ Provider version: 8.4.0, released on 2026-03-04.
│ Service: Functions Function
│ Operation Name: CreateFunction
│ OPC request ID: 6b999f5955c10285ce291326a706f9fc/2D395F47FE488AA6FA98AB69494144DA/0A4140C3F31DBA7E83041640FB9E214C
│
│
│ with oci_functions_function.comic_function,
│ on functions.tf line 32, in resource "oci_functions_function" "comic_function":
│ 32: resource "oci_functions_function" "comic_function" { >>>

Cline responded with resolutions to each and every one of these and I was successful in creating the entire infrastructure.

10. Deploy the Container

I ran into a number of errors when following the instructions in 03-DEPLOYMENT.md to deploy all the code. Here's a stripped down version of that deployment guide:

First, I asked it Cline to do the following:

Can you update "03-DEPLOYMENT.md" and update Step 3 to make it using Microsoft Windows commands, not Linux commands?

Steps 2.a and 2.b went fine which were all the Terraform stuff. Now that all the OCI services were provisioned, I ran a script to populate the database with sample data. I also ran into authentication issues, and after 15 minutes of back-and-forth with the AI agent, we were able to resolve it (something to do with password complexity).

I was able to confirm on the OCI console that the data was there:

As I approached Step 3.b, which is deploying the OCI function, I ran into multiple issues:

When I ran "fn use context oci-context" I received the following error <<< Fn: error replacing file with tempfile >>> Also, which directory am I supposed to be in when I run this command?

When I ran the "docker" command I received the following error <<< WARNING! Using --password via the CLI is insecure. Use --password-stdin.
error during connect: in the default daemon configuration on Windows, the docker client must be run with elevated privileges to connect: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.24/auth": open //./pipe/docker_engine: The system cannot find the file specified. >>>

I started the Docker Desktop successfully. Running "docker info" just hangs indefinitely (I waited for at least 5 minutes). And the "docker login" command also hangs indefinitely (I waited for at least 5 minutes).

The Cline AI agent took over from here. The agent tried deploying unsuccessfully (remember, I gave it auto-approve permissions to execute any command it wants to), it observed the error, analyzed what the root cause could be, fixed it (sometimes successfully, sometimes unsuccessfully), and on failed fixes it would continue troubleshooting until it got it right. There were a lot of issues, but Cline figured it all out.

After the OCI Function was deployed, it took the OCID on its own, updated the Terraform scripts with the value of the OCID, and applied the change via Terraform to update the API Gateway... all automatically on its own!

All along the way, it continued fixing the documentation, code, and Terraform scripts as needed.

11. Testing the Deployed Application

Now that the application was deployed successfully on the cloud, Cline gave me the public URL. Here are a couple of screenshots of the application.

All the functionality was working, from navigation, to adding to the cart, to checking out.

12. Testing the Deployed Application

I asked Cline the following aftewards:

Export this entire chat into an HTML file(s) maintaining all formatting and images.

Unfortunately, it did not do as I expected. I wanted a word-for-word export of the entire chat history, maintaining all formatting. Instead, it created a fully comprehensive (and impressive) HTML file with an organized version of what took place.

But from this writeup, this was one of the key information that I was looking for:

Across 4 sessions, the total engagement time was ~5 hours with a total cost of $32.35.

OWASP is best known for the OWASP Top 10, a regularly updated list of the most critical web application security risks.

So I recently published my third book title DevSecOps in Oracle Cloud. This is a huge book hitting 640 pages in length. A lot of topics were covered, namely DevSecOps concepts, open-source tools, and obviously Oracle Cloud services that enable DevSecOps. It was through my book research and subsequent conference presentations that I came across and learned about the OWASP DevSecOps Maturity Model (DSOMM).

(On a side note, here's another blog post of mine that describes the differences between DevSecOps and SecDevOps.)

From On-Prem to DevSecOps

Every organization is at a different stage in their DevSecOps journey. Here's a diagram I created that shows the typical long-term evolution an organization may go through as it matures towards DevSecOps.

If you're still in the early phases of your cloud journey, DevSecOps will likely not be on your mind. You have enough on your plate establishing your cloud standards, best practices, and governance. But as you continue to mature, you start introducing DevOps, hopefully followed by DevSecOps.

I used this diagram in several of my presentations on the topic, and I feel it is a self-explanatory way of depicting the challenges, needs, and enablers of each phase of the journey.

Introducing DSOMM

I came across the DevSecOps Maturity Model (DSOMM) in 2025, but it was originally introduced by OWASP in 2017.

The DSOMM is a framework designed to integrate security into DevOps practices effectively. It provides a structured approach to assess and enhance security measures across the software development lifecycle, ensuring that security is not overlooked during the implementation of DevOps strategies.

I love the graphical depiction of the model. Here, it provides a visual representation of your DevSecOps maturity level in an easy to understand color-coded diagram. The greener, the better. The darker the green, the more mature you are. More greens in the outer layers, the higher your mature level is.

DSOMM includes 6 core dimensions:

• Build & Deployment
• Culture & Organization
• Implementation
• Information Gathering
• Test & Verification

Each dimension includes multiple sub-dimensions, shown in the figure above.

An interactive model where you can build your own representation can be found at dsomm.owasp.org. When clicking on a cell that represents the subdimension and maturity level, you are presented with a lifecycle toggle.

For example, the following diagram shows how when clicking on the cell (see #1 in the diagram) representing the Deployment subdimension at Maturity Level 5, you are presented with a deployment initiative (see #2), in this case, Blue/Green Deployment, and you can use toggle to indicate where you are in the lifecycle of this effort. Based on the whether you just started or if its fully implemented, the shade of green will change.

What next?

The following figure shows where you ideally want to be, which is seeing dark green on every sub-dimension in the outermost layer. Though practically impossible to achieve, the goal is to at least aim for it.

But what are you supposed to do with this model?

Go online and you'll read that it's a "framework" or a "roadmap" or an "assessment" or a "benchmark." None of these are necessarily wrong, as the OWASP DSOMM ultimately aims to help your organization incrementally improve security within DevOps practices.

But here is a simple actionable plan I suggest:

1. Assess your current environment (don't overthink it), and use dsomm.owasp.org to create a visual snapshot of your current state (creating a radar diagram like the above).
2. Use it to identify major gaps across various dimensions, and prioritize high-impact security activities that should be focused on.
3. Repeat every 6 months, and compare to previous snapshots over time.

I keep using the word "journey" when it comes to DevSecOps, because it truly is. Startups shouldn't aim for Maturity Level 4 across the board. DSOMM is initially most effective when you pick Maturity Level 1 for everything and only Maturity Level 3 for your highest-risk areas.

One last note, you might find in some DSOMM documentation that Maturity Levels are described between 1 and 4 and in others between 1 and 5, the latter being the more recent one. But don't sweat it too much.

Other common synonyms for "AI code generation" in use today are:

• Vibe coding - Coined by Andrej Karpathy, but my least favorite term. Describes a high-level approach where a developer provides natural language "vibes" or intent, and the AI handles the implementation without the user needing to touch the syntax.
• Agentic development - Refers to using autonomous AI agents that don't just write snippets, but can plan, execute, test, and debug multi-file changes across an entire repository independently.
• AI-assisted programming - A broad, professional term for a collaborative workflow where a human developer remains the primary pilot while using AI to accelerate routine tasks like boilerplate or refactoring.
• Prompt-to-code - Not a commonly used term but recently referred to as NLP-Dev (Natural Language Programming-Development). Describes the specific technical act of translating a human-language description directly into executable source code.
• Autonomous coding - My specific area of interest. Minimal to zero human intervention needed here.

I may use many of these terms interchangeably, but in the end, they all mean the same thing, which is to leverage natural language prompting to assist in code creation with little to no human intervention.

Below you'll get a simple and generic overview of AI code generation, but my initial intent of this post was to highlight some of the risks (and possible mitigations) of over-reliance on AI code generation. Read on...

Why use AI code generation?

If not obvious already, some of the benefits of AI code generation include:

• Enables developers to generate code faster
• Accelerates debugging and troubleshooting
• Boosts developer productivity
• Rapid experimentation
• Quickly and efficiently test and debug code
• Reduces the work of manually writing lines of code
• Alleviates developer’s mental load and reduces burnout
• Frees developers to focus on higher-value work
• Makes code development accessible to non-developers

Rapid experimentation and accelerating development seem to be the top two benefits often cited.

How does AI code generation work?

The following diagram provides a simple explanation of how AI code generation works.

First, the developer enters a prompt using natural language to a plugin within the IDE. This could be a simple "Create an HTML-based calculator application." The plugin makes an API call to a provider's model (you choose the provider and model), usually at a cost per call. The response is returned by the model. The response could be informational or instruct the plugin to begin manipulating your local code for you (i.e., operating as an "agent").

What are some risks and challenges of AI code generation?

1. Low quality code - Hallucinations, lack of consistency, and poor coding standards can be experienced. Repeated attempts for the agent to fix code can be unsuccessful.
2. Security vulnerabilities - Data poisoning is a real problem. For example, there are over 1 billion repos in GitHub, 278 million of them public. No doubt that a significant number of these repos have malicious code intentionally embedded within them with serious vulnerabilities so that unsuspecting folks are compromised when they download and execute the code. Now imagine GitHub Copilot being trained on this code.
3. Data privacy - Your code and data could be used for model training, particularly if you are not on a paid business or enterprise plan.
4. Licensing & copyright risks - The model could potentially include open-source code without attribution. This is all new territory and implications within the industry are yet to be seen.
5. Cost - The more calls that are made through continuous prompting by the developer, the larger your code set, and the higher quality the model you are using, then expect more $$$ required. Food for thought: If it takes 10 seconds to generate code but 20 minutes to verify it, was it actually faster/cheaper?
6. Speed - Complex tasks on certain models can take considerable time (50+ minutes for a single request) and still be riddled with bugs.
7. Risk of technical debt - Can create long-term maintenance challenges due to poorly structured or inconsistent implementation.
8. Skills atrophy - Coding skills of developers can erode over time.
9. Loss of developer control - Too much developer dependency on AI can contribute to reduced understanding of codebase.

How do you mitigate some of the risks of AI code generation?

Taking each of the risks from the previous section, here are some approaches to mitigate each of those risks.

1. Low quality code –> Always review AI generated code.
2. Security vulnerabilities –> Enforce mandatory scanning of your code with SAST tools within your pipelines.
3. Data privacy –> Consider self-hosted AI coding assistants and/or verify vendor’s policies. Always read the fine print.
4. Licensing & copyright risks –> Run generated code through license scanners and/or verify vendor’s policies. Some vendors (e.g., Microsoft for GitHub Copilot) include indemnification clauses in their upper tiered plans. GitHub Copilot also has an "exclusion" filter to prevent the AI from suggestion code that matches public repositories.
5. Cost –> Consider lower cost models (e.g., Claude Sonnet 4.6 versus Claude Opus 4.6; see my other post on this here).
6. Speed –> Consider models that emphasize speed over quality for non-complex scenarios (e.g., front-end stuff) (see my other post on this here).
7. Risk of technical debt –> If you have bandwidth restrictions to perform code reviews, consider automated static code analysis tools.
8. Skills atrophy - Developers should periodically implement components or modules manually and conduct design reviews.
9. Loss of developer control –> Mandate that AI-generated code be treated as a draft and thus requires developer validation first, ensuring that it aligns with the overarching architecture. This is easier said than done though.

The reality is, there is no single tool that stops AI risk. Leveraging layered defense, implement SAST (for the code), SCA (for the libraries), and a human (for the logic).

One of my fears of modern AI and autonomous code generation is that it may eventually create a generation of Copy-Paste Developers who can't debug the foundations of their own code.

Recently as I was preparing a demo on Visual Studio Code + Cline + Claude Opus for an upcoming conference presentation I will be giving, I ran through a specific use case. This was the first time I used the latest Claude Opus 4.6, and my previous experience had only been with Sonnet. I was shocked that the entire autonomous application generation and deployment took 5 hours and cost $32.35, both higher than I expected. But then again, we were all warned that Opus was more expensive and took longer. In all fairness, the model created a database-driven application with a front-end, backend, Terraform scripts, and "mostly" autonomous deployment to Oracle Cloud Infrastructure.

So I embarked on a mini exercise to try to get some real world experience comparing Sonnet and Opus. I ran two tests detailed below and compared the results.

Test #1: Recreating the R-Type Game

Back in 1988, there was an awesome game I had called R-Type on the Commodore 64. Could modern day AI code assistants recreate it for me?

The Prompt

This was the prompt I used and submitted to both models; Sonnet 4.6 and Opus 4.6. Coming up with the prompt involved a little bit of meta prompting (where you ask the chatbot to help you create a more precise and detailed prompt).

You are an expert JavaScript game developer.

Create a small browser game inspired by the classic side-scrolling shooter **R-Type**, originally released on the **Commodore 64**. This must NOT be a full recreation of the original game. It should only capture the core gameplay idea: a side-scrolling spaceship shooter. The first page should be welcome page, like a placeholder where the user can click on a button and be taken to another page which runs the game.

Requirements:

GAMEPLAY

* The game runs entirely in the browser.
* The player controls a spaceship flying from left to right while the world scrolls right-to-left.
* The ship can:
  * Move up/down/left/right
  * Shoot projectiles forward
* Enemies enter from the right side of the screen.
* Enemies move in simple patterns (sine wave, straight line, or diagonal).
* Enemy ships can be destroyed by the player's shots.
* Collision with enemies reduces player health.
* The level ends after ~60 seconds or when the player reaches the end of the scrolling map.
* Include a small boss or large enemy at the end of the level.

LEVEL DESIGN

* Only ONE short level.
* Automatically scrolling background.
* Parallax background layers to simulate depth.
* The level should contain:
  * 3–5 enemy waves
  * A final boss
* After the boss is defeated, display a "Level Complete" screen.

GRAPHICS STYLE

* This is a **2D game**, but the graphics should be styled to look **pseudo-3D** using:
  * lighting gradients
  * shading
  * highlights
  * soft shadows
  * layered sprites
* Avoid pixel-art Commodore style.
* Instead use smooth vector-style or canvas-rendered shapes that appear modern.
* All rendering should be done using HTML5 Canvas.

TECHNICAL REQUIREMENTS

* Use plain JavaScript (ES6+).
* No heavy frameworks.
* Small libraries are allowed only if necessary.
* Use requestAnimationFrame for the game loop.
* Organize the code cleanly into module.
* The project should run by simply opening `index.html`.
* Generate simple shapes procedurally if possible instead of image files.

VISUAL DETAILS

* Background space with stars
* Moving nebula layer
* Metallic-looking player ship with lighting
* Enemy ships with glowing engines
* Laser shots with glow effects
* Explosions using particles

CONTROLS
Keyboard controls:

* Arrow keys → movement
* Spacebar → shoot

GAME HUD
Display:

* Player health
* Score
* Level progress bar

CODE QUALITY

* Write clear, readable code.
* Include comments explaining the game loop and rendering logic.
* Avoid unnecessary complexity.
* Ensure the game runs at ~60 FPS.

Sonnet Results

The game created by Sonnet was a bit superior to the Opus version. I preferred the look of the welcome page created by Sonnet as you can see here.

And though you can't see it here, the animation of your spacecraft would tilt upwards and downwards at an angle when moved, versus a static shaped craft in the Opus version. Note that I never specified the animation behavior to either model.

Opus Results

The difference in the final result between Sonnet and Opus versions was not significant. Though I preferred the look of the welcome page of the Sonnet version (versus the Opus version below), keep in mind I wasn't explicit in my prompt in regards to the layout, design, or aesthetic preference. Specificity in prompting would have yielded better results, and I could have re-engaged the model to continue tweaking it to my liking, which I did not do in this test.

The gameplay window in the Opus version did not fill the entire browser as you can see below, but the Sonnet version did. Again, with additional re-prompting I could have requested from the model to do so.

Conclusion of Test #1

I am reminded of this tweet.

Generally speaking (and I say this with some hesitancy), the results of your AI generated code is only as good as the quality of your prompt. But by providing more details, specifics, and clarifications during re-prompting can you achieve your desired output.

This table compares the cost, duration, and tools for both. Given that there was no difference in cost or time taken to generate the application, Sonnet wins by a small margin due to better gameplay animations and more pleasing welcome page.

Test #2: The Multidimensional Benchmark Test

I asked ChatGPT to help me come up with a prompt that can measure the performance of each of the two models. It generated a single prompt (below) that I pasted into the Cline plugin in VS Code.

The prompt instructed the model to build a small but meaningful application that tests several dimensions of AI capability:

• algorithmic reasoning
• code architecture decisions
• UI generation
• structured data handling
• documentation clarity
• self-evaluation

This type of multi-dimensional benchmark task is commonly used in LLM evaluation because it tests planning + implementation + explanation, rather than just code generation.

The Prompt

The application to be generated from this prompt is a mini AI evaluation dashboard that includes algorithmic tasks and analysis.

You are an expert software architect and engineer.

Your task is to design and implement a small application that can be used to evaluate the reasoning, coding, architecture, and explanation capabilities of an AI model.

The application must be complex enough to require planning and multiple components, but small enough to be implemented in under ~600 lines of code total.

OBJECTIVE
Create a self-contained application that tests the following capabilities:

1. Algorithmic reasoning
2. Data processing
3. Clean software architecture
4. UI generation
5. Explanation and documentation quality

APPLICATION REQUIREMENTS

Build a browser-based application called:

"AI Reasoning Benchmark"

TECH STACK
Use only:

HTML
CSS
Vanilla JavaScript (no frameworks)

The entire application should run locally in the browser.

FEATURES

1. Problem Generator

Create a module that generates several types of problems:

A. Pathfinding problem
- Generate a random 10x10 grid
- Add obstacles randomly
- Start and goal nodes
- Solve with A* or Dijkstra

B. Scheduling optimization
- Given tasks with durations and dependencies
- Compute optimal schedule order

C. Logic puzzle
- Example: simple constraint satisfaction puzzle

The application should solve these problems and visualize the result.

2. Visualization

Include visual components:

Grid visualization for pathfinding

Dependency graph visualization for scheduling

Simple puzzle explanation output

3. Architecture

The code must be structured clearly:

/app.js
/pathfinding.js
/scheduler.js
/puzzles.js
/ui.js

Explain the design decisions.

4. Benchmark Report

At the end, generate a small report showing:

Number of problems solved
Runtime performance (approximate timing)
Explanation of the solutions
Limitations of the algorithms

5. Self-Evaluation

Add a section where the model writes:

"How well this solution demonstrates AI reasoning capability."

Explain tradeoffs and improvements.

OUTPUT FORMAT

Provide:

1. Project structure
2. Complete source code for each file
3. Setup instructions
4. Short design explanation

IMPORTANT

Do NOT over-engineer.
Do NOT use external libraries.
Keep code readable and modular.

The goal is to measure the model's reasoning, structure, and engineering quality.

Focus on clarity, architecture, and correctness.

Sonnet Results

The key differences between the Sonnet (shown below) and Opus outputs appears to be mostly aesthetic. In the conclusion later on, I highlight some differences between the two outputs.

Opus Results

The tests generated by both the Sonnet and Opus (shown here) models were nearly identical in performance, quality, and output, so the differences were mostly negligible. Again, I have highlighted some differences in the conclusion below.

Conclusion of Test #2

Aside from a different aesthetic look between the Sonnet-generated application and the Opus-generated one, both actually behaved similarly, with a slight edge given to the Sonnet application.

The Sonnet application included a better scheduler that measured in days rather than units and was easier to follow, and its self-evaluation was also better, as it provided scoring and clearer explanations. All the other tests in both models were similar in quality, performance, and output.

As far as the cost and duration, there were also no notable differences. Sonnet is the winner here again due to the reasons mentioned in the previous paragraph.

Final, Final Conclusion

Opus is originally designed to excel over Sonnet in these areas:

• Architecture design - By delivering cleaner modularization
• Algorithm choice - By selecting better heuristics
• Code reliability - By producing better working code
• Explanation depth - By employing deeper reasoning

Sonnet is marketed as a cheaper, faster implementation but delivering simpler solutions. Opus, on the other hand, is marketed as having more advanced reasoning and better architecture. I did not see these tradeoffs in these two tests.

In fact, some benchmarks (like SWE-bench) show Sonnet 4.6 trailing Opus by only a slim margin (e.g., 1.2-2%) while being significantly faster.

In terms of pricing, Sonnet 4.6 is $3 per million input tokens and $15 per million output tokens, while Opus 4.6 is $15 per million input tokens and $75 per million output tokens.

Keep in mind that the tests I ran were not complex. I also did not spent time with the other Sonnet 4.6:1m or Opus 4.6:1m models. Those models increase the context window by about 5x to process larger inputs, and instead of reading projects, they can actually read entire repositories. This is good for parallel and team development, something I don't find necessary in my current work.

For the complex demo I mentioned at the start of this post, I used Opus 4.6. It generated a multi-tiered web application deployed to the cloud. Opus took care of all infrastructure provisioning and most of the deployment. Bug after bug was resolved automatically by Opus and fully detailed and impressive documentation and reasoning were provided.

How would this complex project have fared under Sonnet? I'm not sure. Other blogs seem to recommend Sonnet for UI/UX and Opus for backend/database schema logic. In conclusion, I wish I could provide you with a concrete recommendation on which model to use when, but I may personally lean towards Sonnet.

For those who aim for resiliency, implementing disaster recovery (DR) is one approach that protects against cloud region failures. There are two approaches to implementing DR, but that's for a separate blog post. In this post, however, I'd like to outline some of the real challenges and key areas to watch out for when designing and implementing DR for OIC. Even if you opt for the one-click Oracle-Managed DR turnkey solution, you should be aware of these.

There are too many areas that need to be watched out for, from the network setup complexity to managing credentials to understanding how your integrations will behave in the event of a failover. Some others areas of awareness are mentioned below.

Manual Metadata Synchronization
The single biggest responsibility. If your CI/CD process is not robust and disciplined, your primary and secondary instances will drift, and your DR plan will fail.

Loss of In-Flight Data
There is no built-in mechanism to recover transactions that were actively processing during an outage.

Runtime vs. Design-Time URL
The custom endpoint is for runtime traffic only. Developers and administrators must still use the region-specific URL to access the OIC design console. This can cause confusion if not managed properly.

Post-Failover Cleanup
An emergency failover leaves artifacts running in the original primary region. Manual cleanup and resetting the DR configuration are required before you can fail back, as documented in "Resetting DR Configuration After a Failover".

Component Exclusions
Visual Builder (VB) and Process Automation (OPA) require separate DR handling.

Certificates
SSL certificates must be managed and present in both regions.

OIC provides a robust, enterprise-grade integration platform. The biggest risks when implementing DR are assumptions, drift, and lack of operational rigor.

If you're serious about OIC disaster recovery:

• Automate everything you reasonably can
• Build in recovery, atomicity, and validations in your integrations
• Test annually
• Align business expectations with platform realities

Basically...

• Performance Testing: Goes deeper to analyze bottlenecks, measure response times, and validate scalability.
• Load Testing: Simulates thousands of concurrent users to check system behavior under heavy traffic.

Gatling.io is both a load testing and performance testing tool, functioning as a comprehensive framework to simulate user traffic, identify bottlenecks, and assess system performance under various conditions, with a strong emphasis on developer-friendly, code-based scripting for web apps, APIs, and microservices.

Gatling.io is a popular, open-source load testing platform and offers both a free Community Edition and an advanced Enterprise version.

Brief Comparison to Apache JMeter

I am neither an expert in Gatling.io nor Apache JMeter, but have used both of them for isolated testing. For reference, Apache JMeter was created in 1998 and Gatling.io in 2011.

Check out my next blog post on Installing and running Gatling.io.

This post covers:

• How to download packages with pip
• How to verify their integrity
• Why integrity verification matters

How pip Downloads Packages

The most common way developers install a Python package is by running a command like this:

pip install requests

By default, pip:

1. Resolves dependencies
2. Downloads package files from Python Package Index (PyPI)
3. Installs them into your environment

pip uses HTTPS behind the scenes, which protects against basic man-in-the-middle attacks, but HTTPS alone does not guarantee that the package itself hasn’t been tampered with or replaced upstream (for example, through compromised accounts or malicious uploads).

That’s where integrity verification comes in.

How to Verify Package Integrity with pip

Perhaps the best option is to use hash verification. Here, you tell pip exactly which file is allowed to be installed by giving it a cryptographic fingerprint (hash). If the file is different in any way, pip refuses to install it.

1. Install the package normally (once). This lets pip resolve dependencies and identify the exact version. It may install other dependencies (i.e., additional packages).

pip install requests

2. Generate a requirements file with pinned versions.

pip freeze > requirements.txt

3. View the generated requirements.txt file. This lists all downloaded packages and their versions, but the integrity of the packages is not yet verified. The file may look something like this:

certifi==2023.11.17
charset-normalizer==3.3.2
idna==3.6
requests==2.31.0
urllib3==2.1.0

3. Download all packages in the requirements.txt file to a packages/ subfolder so that you can tell pip which exact files are allowed.

pip download -r requirements.txt -d packages/

4. Get the exact filename of the downloaded package you wish to get the hash for. For example, the command below will return "requests-2.32.5-py3-none-any.whl".

dir packages\requests*

5. Generate the hash for this single package. pip hash can only be run on one file at a time.

pip hash packages/requests-2.32.5-py3-none-any.whl

You will get an output which lists the package name and its hash like this:

c:\Temp>pip hash packages/requests-2.32.5-py3-none-any.whl

packages/requests-2.32.5-py3-none-any.whl:
--hash=sha256:2462f94637a34fd532264295e186976db0f5d453d1cdd31473c85a6a161affb6

5. Update requirements.txt and paste the hash into each line. Now repeat this for every package.

certifi==2023.11.17
charset-normalizer==3.3.2
idna==3.6
requests==2.31.0 \
    --hash=sha256:2462f94637a34fd532264295e186976db0f5d453d1cdd31473c85a6a161affb6
urllib3==2.1.0

6. As you install your packages in your higher up environments, enforce hash checking on all future installations as shown.

pip install --require-hashes -r requirements.txt

pip will now refuse to install anything that doesn’t match the expected version and cryptographic hash. This protects you against tampered packages and dependency confusion.

Why Verifying Package Integrity Is Important

1. Supply chain attacks are increasing

Attackers increasingly target:

• Maintainer accounts
• CI pipelines
• Dependency confusion vulnerabilities

Once malicious code is published, it spreads instantly to thousands of systems via automated installs.

2. Transitive dependencies multiply risk

You may install one package, but pip may install dozens more automatically. If any dependency in the chain is compromised, your application is compromised.

Hash verification locks the entire dependency tree to known-good artifacts.

3. Builds must be reproducible

Without integrity checks, the same build today may not match tomorrow if a package is updated.

What About Virtual Environments and Docker?

Virtual environments and containers do not solve integrity. They only isolate where the code runs. You still need to verify what goes into those environments. So the verification instructions mentioned above is still needed.

Example in Docker:

COPY requirements.txt .
RUN pip install --require-hashes -r requirements.txt

Summary

At minimum, there are two practices you should consider starting doing:

1. Store hash values of your packages in requirements.txt
2. Always use pip install --require-hashes

While pip makes installing software incredibly easy, it also makes it easy to run unverified code in production. With pinned versions in requirements.txt and hash verification during installs, you can reduce risk.

Applications and services interact with buckets using the provided API, command-line interface, SDK, and good old URL. Each method has its own benefits, and one uses them as needed. In my scenario, the application handles uploads and replacements, while Caddy (the lightweight web server) handles the web front and proxies requests to application components.

In this scenario, a Caddy server masks the actual bucket URL, using rewrite rules and configuration variables. Plus, for static content in the bucket, we need to inject the access token or a Pre-Authenticated Request (PAR).

The final request processing steps are:

• Identify a static content request, for example, path matches/images/*.
• Rewrite the request to match the object's URI in the target bucket.
• Forward the new request to the bucket, using the recommended Oracle Object Storage URI.

For a while, Oracle has introduced dedicated object storage endpoints. To see the difference between the traditional and recommended URI, open any object in the bucket.

Following the third factor, the complete URI in the configuration should look like:

https://${OCI_SPACE}.objectstorage.${OCI_REGION}.oci.
customer-oci.com/p/${OCI_PAR}/n/${OCI_SPACE}/b/${OCI_BUCKET}/o/${URI} 

Where variables are:

• OCI_REGION - the target OCI region, in my case: us-ashburn-1.
• OCI_SPACE - the unique identifier, one per tenancy. You may see it in other services that rely on object storage, for example, Container Registry.
• OCI_PAR - The token, required for private bucket access. In my case, the par token works only for objects with names beginning with images/*
• OCI_BUCKET - The name of the bucket, with the site objects.

The configuration file for my application is

app.example.com {
    
    map {$OCI_PAR} {oci_path} {oci_host} { 	
     PUBLIC  /n/{$OCI_SPACE}/b/{$OCI_BUCKET}/o/{uri}        				
     default /p/{$OCI_PAR}/n/{$OCI_SPACE}/b/{$OCI_BUCKET}/o/{uri} ${OCI_SPACE}.objectstorage.${OCI_REGION}.oci.
customer-oci.com
	}

    @asset expression `{uri}.startsWith("/images/")`
    route @asset {
	   rewrite /images/* {oci_path}
	   reverse_proxy https://{oci_host} {
            transport http {
			   tls
	        }	
        } 
    }
	reverse_proxy http://app_host:8080
	encode gzip zstd
}

Some explanation for map and @asset definitions:

• The map structure uses the $OCI_PAR environment variable to calculate Caddy variables oci_path and oci_host. If $OCI_PAR contains public, the object path would not contain the $OCI_PAR token; otherwise (default case), it will start with the /p/ clause. Since the Object Storage host FQDN does not depend on the token value, only the default section declares the value, and it will be the same for all cases.
• The precalculated condition @asset evaluates to True or False for the expression, depending on whether the URI starts with the string "/images/".

The route intercepts requests when the @asset expression is True, then rewrites the request path using the generated object path and sends the result to the bucket over a TLS connection.

I have tested this scenario using OCI CLI, Node.js SDK, and simple cURL calls from the command line. It worked, and my compute instance could access objects, yet the Caddy container has continued to throw the host access error. After a short investigation, I realised that the Caddy container, for some mysterious reason, was unable to resolve the recommended OCI Object Storage URI. Yet, it had no issues resolving the classic Object Storage URL.

After a minor adjustment in the mapping declaration, Caddy was able to serve static requests.

map {$OCI_PAR} {oci_path} {oci_host} { 	
    PUBLIC  /n/{$OCI_SPACE}/b/{$OCI_BUCKET}/o/{uri}        				
    default /p/{$OCI_PAR}/n/{$OCI_SPACE}/b/{$OCI_BUCKET}/o/{uri} objectstorage.${OCI_REGION}.oraclecloud.com
}

Using pip show displays detailed metadata for a specific package, including its version, location, and dependencies.

Example:

pip show requests

Output:

Name: requests
Version: 2.32.3
Summary: Python HTTP for Humans.
Home-page: https://requests.readthedocs.io
Author: Kenneth Reitz
Author-email: me@kennethreitz.org
License: Apache-2.0
Location: C:\Users\ahmed\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.12_qbz5n2kfra8p0\LocalCache\local-packages\Python312\site-packages
Requires: certifi, charset-normalizer, idna, urllib3
Required-by: locust

Using pip list lists all installed packages with their versions in a list format.

Example:

pip list | findstr requests    # Windows
pip list | grep requests       # Linux

Output:

requests           2.32.3

Let's start with the scene:

• I have a templated Virtual Cloud Network with public and private subnets, with all default gateways.
• A single instance in the public subnet is up and accessible from a local terminal application.
• The default security list was updated to allow IPv6 and IPv4 traffic for ports 80 and 443.
• An instance firewall allows HTTP/HTTPS services in the public zone
• Public domain resolves to the public IPv4 address of the instance

Yet, the service on the box is not reachable. Let's start with the necessary preparations.

1. Find your router's IP address. Usually, I've run curl http://ip.me, but on MacOS, it prefers the IPv6 stack, and when it reports IPv4, the result is questionable. To find my public IPv4 address, I used the service htps://ip4only.me and its counterpart - https://ip6only.me.
2. Make sure your firewall ports are open, and you have a listener on the port in question.

[opc@oci-vm ~]$ sudo firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp0s6
  sources: 
  services: dhcpv6-client http https ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
[opc@oci-vm ~]$ mkdir -p /tmp/empty/
[opc@oci-vm ~]$ sudo python -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

Now we have everything we need for the network tests.

1. We start by accessing the Oracle Cloud Infrastructure Console - https://cloud.oracle.com. Make sure your account has sufficient privileges to create IAM policies; otherwise, you should request that account administrators adjust your privileges, as in the next few steps.
2. The network path Analyzer may offer you to create the policy in advance, but you may want to customize the policy rules below to meet your specific security requirements. The generic set of statements is below:

allow any-user to inspect compartments in tenancy where all { request.principal.type = 'vnpa-service' }
allow any-user to read instances in tenancy where all { request.principal.type = 'vnpa-service' }
allow any-user to read virtual-network-family in tenancy where all { request.principal.type = 'vnpa-service' }
allow any-user to read load-balancers in tenancy where all { request.principal.type = 'vnpa-service' }
allow any-user to read network-security-group in tenancy where all { request.principal.type = 'vnpa-service' }

3. Save the polycy body. Fix any errors you may have.
4. Create one more policy that allows account users to use the service. Don't forget to narrow down the privileges listed below.

allow group Administrators to manage vn-path-analyzer-test in tenancy

5. Now, we could create some tests and identify potential issues. Locate the Network Path Analyzer service. From the main navigation menu, it is under Networking/Network Command Center.
6. To create a new test, click the "Create path analysis" button, right above the table in the central area.
7. The form starts with basic definitions, including the test name, the compartment to save the configuration, and the network protocol. Fill out the appropriate values.
8. Next is the source definition. I used my IPv4 address from the preparations, but I suppose any valid "white" IP address will work. Of course, it could be another VCN or an on-premises IP address. Additionally, you may specify a specific source port.
9. For the destination, check the "Find OCI resource" option, then select the destination type. I select "OCI Compute Instance (VNIC)" and specify the compute instance name and the network interface. If drop-downs are empty, adjust compartments for both choices.
10. The final adjustment is to pick an IP address from the drop-down list. I choose the public IP, and specify the port to test.
11. Select if you want to do a bi-directional or a uni-directional test, and click the "Run analysis" button at the bottom of the form.
12. The form will show you the progress of the examination. It could take a few minutes, but you may save the test configuration using the "Save analysis".

The Network Path Analyzer produces a report as shown in the screenshot below.

Analysis suggests that I have issues with some security rules. After close examination (for the fifth time!) I've found the root cause. My IPv4 ports 80 and 443 were listed as source ports instead of destination ports.

I rerun the analysis with the corrected Security List and confirm that my public port is accessible in both directions.

While my minute use case for Network Patch Analyzer seems a little bit excessive, think about:

• Complex, multi-cloud and hybrid environments. Even finding the root cause's vicinity may save you weeks of close examination and cross-team calls.
• Sometimes you have to provide the hard evidence that your network configuration is correct and operable. And nothing is better than a positive report from a trusted source.

To conclude, I should mention that all hyperscalers offer similar functionality. Amazon offers Reachability Analyzer, Google has Connectivity Tests, and Microsoft names it Virtual Network Verifier.

But if you look past the name change, there's something more interesting happening here. Oracle isn't just adding a "vector" data type and calling it a day. They're trying to solve the biggest headache in modern AI development: data gravity.

Data gravity refers to how large collections of data naturally pull in applications, services, and even more data. Just like physical gravity increases with mass, the "pull" grows as the data volume grows. Data lakes and data warehouses are common examples of environments where data gravity occurs.

The following figure (borrowed from here), demonstrates how the larger the data, the more it attracts applications, services, and more data.

Furthermore, of the many advantages that Oracle Database 26ai offers for modern day developers, some include:

• JSON-Relational Duality: Oracle Database 26ai treats vectors, JSON, and relational data as the same thing. You can store data as rows (for the DBAs) but fetch and update them as JSON documents (for the frontend). There is no need for object-relationship mapping anymore.
• Built-in LLM Integration: With 26ai, you can call an LLM directly via SQL. You can literally run a query that says, "Find me the top 5 customers, and summarize their last three support tickets," and the database handles the RAG pipeline internally.
• The "Zero-Upgrade" Upgrade: One thing the AI-generated blogs miss is that 26ai is delivered as a Release Update (RU). If you’re on 23ai, you just patch.

The "Old" Way We Build AI Apps Right Now

As AI developers, most of us have spent the last year building RAG (Retrieval-Augmented Generation) pipelines like this:

1. Export data from our "source of truth" (Oracle Database).
2. Push it through an ETL pipeline.
3. Index it in a separate vector database (Pinecone, Weaviate, etc.).
4. Hope the two stay in sync.

It’s brittle, it’s expensive, and it’s a security nightmare.

Developing with Oracle Database 26ai

Now take a look at the following figure. Oracle is moving reasoning (such as AI agents and vector search) away from the application tier and into the data layer.

This is one of the problems that Oracle is trying to solve for the modern day AI developer... by providing a simplified, unified, and secure platform for AI development.

If you’re still on 19c, skip 23ai and head straight for 26ai. The water's fine, and you can finally stop managing that separate vector database.

I did some code refactoring (a fancy name for a total rewrite of the component), and as a result, my class went completely asynchronous. The new and improved functionality led to the new roadblock. With full asynchronicity, the system tries to read an object before an OCI bucket completes an upload. Unfortunately, I can't control the code usage; all I can do is implement one of the retry strategies.

The good news is that the OCI SDK provides this functionality at the client or at the operation level. TypeScript/JavaScript and Python libraries provide similar mechanisms for defining complex behavioral patterns to handle timeouts, errors, and delays. In my scenario, all I need is a small lag between the moment when objects are uploaded, the method returns a new resource URI, and the time when the OCI bucket makes them available for access. Since I don't want to retry all operations, I will add retry configurations only to "exists" and "read" operations.

The code below shows how to use the retry configuration. For the sake of clarity, I stripped out all surrounding code, the constructor, authentication, and service functions.

async exists(fileName, targetDir) {
  const targetName = 
    buildPath(this.getTargetDir(this.pathPrefix), targetDir, fileName);
  const headOp = {
      objectName: stripLeadingSlash(targetName),
      bucketName: this.bucket,
      namespaceName: this.namespace,
      retryConfiguration: {
        retryCondition:  common.DefaultRetryCondition,
        terminationStrategy: new   
          common.MaxAttemptsTerminationStrategy(this.retryAttempts)
       } 
  }
  return this.build().then(storage => {
    storage.headObject(headOp)
       .then((result) => { 
                return true;
       })
       .catch((err) => {    
         if (err.statusCode === 404) {
            return false;
         } else {
            throw err;
         }
       });
  });
}

I altered the default retry strategy to terminate after a defined number of retry attempts. By default, the client will try eight times before giving up (according to the Python SDK). It seems a bit high to me, so I'll set max retries to three. The termination strategy may be one of the preconfigured options, or you may define a custom one using custom retry configuration and various strategies.

Tests from my local machine demonstrate that the retry configuration works, and on the second retry attempt, my client reads the object from the OCI bucket.

An extra configuration option for the OCI client, or an additional configuration parameter, allows you to save time and effort on implementing custom error handling. SDK offers a comprehensive set of predefined strategies and conditions. I'll give you a hint: the Python documentation is way better than the [Type|Java]Script one, so you may want to read the Python SDK documentation to grasp the overall idea and apply it to the JavaScript code.

One should design test cases with automation in mind. It means that the ideal test suite runs against the target environment and, on the happy path, leaves nothing behind but a report. For my specific example, it's a system adapter for the OCI Buckets. The set of tests that I developed:

• Test Basic Functionality
  • Test all parameters present
  • Test basic methods
• Tests the OCI SDK functionality
  • Test OCI connectivity and access
  • Test bucket access
  • Perform PUT/GET tasks
  • Test FETCH and DELETE

Means that at the end of the case, the target bucket will contain no artefacts, except log entries. However, for some cases, it would be useful to see what objects are in the bucket. My tests were built with Mocha.js. The framework offers excellent flexibility, allowing you to select and test suites and cases, including filtering by description.

# Runs All Tests in Folder
$ _mocha -- tests/*.test.js

# Run Specific Test File
$ _mocha -- tests/BasicFunctions.test.js

# Run only tests, having matching description 
$ _mocha --grep "Storage Adapter" -- tests/*.test.js

But if you want to skip a specific test, you'll need to make some logic changes. I checked a few options and settled on the most universal approach: environment variables. Here is an example of skipping test file deletion.

it('should delete the file from the bucket', async function () {
  if (process.env.KEEP_FILES) 
    this.skip()
  else
     return adapter.delete(pth.basename(testImage.name),
                'save-test').then((result) => {
                assert.ok(result, 'File deletion failed');
            }).catch(err => {
                assert.fail(`File deletion failed with error:
                ${err.message}`);
            });
});

Now, this step checks whether the KEEP_FILES variable is declared, and if so skips the deleteion step.

# Runs All Tests but keeps test files
$ KEEP_FILES=yes _mocha -- tests/*.test.js