Building an API with AI is fast, but it’s not hands-off. In this article, Grant Fritchey uses Microsoft CoPilot and GitHub Copilot to generate a secure REST API for his built-by-AI application, dbRosetta, by connecting a PostgreSQL database to a future WordPress front end via Azure. Learn the full process, and discover exactly what worked – and what didn’t.

I don’t want to burden our support team (they’re awesome, but busy), so decided to initially host dbRosetta at ScaryDBA.com — a site I control fully, where an accidental mistake won’t take down Redgate. Before developing the next prompt, I discussed the project with Microsoft CoPilot – one of my LLMs of choice for this project – and we agreed to split the next phase into two parts. First up: building an API (application programming interface.)

This is the fourth part of Grant Fritchey’s series on building an app and database almost entirely through an LLM. The repo, including every prompt, lives on GitHub.

Why an API? CoPilot explains it well:

An API provides a secure, consistent way to expose dbRosetta’s database so applications and websites can interact with it without direct access to the underlying system. By adding this layer, we separate the database from the front-end, making it easier to build interactive features while keeping the data protected and portable.

If you’re just joining us, this is Part 4 of a series where I’m building a database and application using LLMs — writing everything myself, except where I explicitly call out the AI.

Generating an API prompt with Microsoft CoPilot

As a general rule, in this series I write prompts to the CoPilot LLM, which then generates a prompt for GitHub Copilot. Here’s the exchange for this step:

The full prompt I gave Microsoft CoPilot

Let’s get started on the API for dbRosetta. I’d like you to generate a prompt for GitHub Copilot within VS Code using the agreed-upon structure. This prompt will define the steps needed to create an API within Azure that accesses our PostgreSQL database for dbRosetta.

It will be a secure API to protect database access, providing mechanisms to query the stored information. The API will be designed to support a WordPress web page we’ll build later.

We’ll need to incorporate the API and its code into our existing GitHub repository, with deployment handled via our existing GitHub Actions pipeline. We’ll also need a full test suite to validate the API is working correctly.

How Microsoft CoPilot responded to my prompt

Project: dbRosetta Secure API — Implementation Plan and Tasks

Context: You are an expert backend engineer and DevOps automation assistant. Implement a secure, production-ready REST API for dbRosetta that runs in Azure, accesses our PostgreSQL database, and is consumable by a WordPress front end. All code must be TypeScript, follow best practices, include a full test suite, and integrate into the existing GitHub repository and GitHub Actions pipeline.

High-level Goals:


(1) Create a secure, well-documented REST API exposing read and query endpoints for dbRosetta PostgreSQL data.


(2) Use Azure-managed services and security best practices (Managed Identity, Key Vault, private endpoints, firewall rules).


(3) Integrate into the existing GitHub repo with a clear branch/PR workflow and CI/CD via existing GitHub Actions.


(4) Provide unit, integration, and end-to-end tests, plus a Postman collection and contract tests.


(5) Produce OpenAPI (Swagger) documentation and example client usage for WordPress. (Full prompt details in the GitHub repo).

My verdict? I’ll be honest: I’m now outside my comfort zone

I have no idea if the approach we’re following is entirely correct, and I’m fairly dependent on both AIs to get this right. I’m thinking more carefully about my own prompts and trying to be more prescriptive. The output looks right to me — so, over to Visual Studio (VS) Code.

Building the API with Microsoft CoPilot

After creating the markdown file for the prompt and pasting it into the VS Code chat window, GitHub Copilot didn’t waste time on discussion — it immediately started generating files, folders, and a lot of code. Within about two minutes, it claimed to be 70% complete and asked:

What would you like to do next?

I chose to test first, so I could understand where things stood. Helpfully, CoPilot told me exactly what to run:

Which was great — until my first error. Node.js wasn’t installed locally, and the AI had never asked. No big deal; I told it the situation, and it simply walked me through the install.

Then npm install gave me pause:

Deprecated versions, deprecated functions. Honestly, I expected this kind of thing. I took the output to CoPilot, which explained that VS Code didn’t intentionally pick deprecated code — the warnings come from transitive dependencies in the toolchain that haven’t yet been updated. You can upgrade or override the offending dependencies, wait for upstream fixes, or suppress the risk with continuous integration (CI) checks.

Fair enough. And it’s a good reminder: this is exactly why I don’t think we need to worry about our jobs. We’re still very much necessary. The process is just a lot faster now.

There was plenty more back and forth as we ran tests and uncovered coding errors and configuration problems — most generated by the LLM, but most also fixed by the LLM.

In the middle of all this, I also had to switch Azure subscriptions (long story). Thanks to the testing scaffolding already in place, the migration was surprisingly simple — if a bit long-winded.

Conclusion: can an AI LLM build an API?

I keep being reminded that the AI is like a brilliantly fast but very junior developer on the team. It generates code at lightning speed, and most of the time it works. But it makes silly mistakes, and someone steady needs to be in the loop to guide it toward a good result.

At one point, I forgot to update the IP address in the Azure PostgreSQL firewall — and when the tests failed, the AI was determined to do deep troubleshooting to find out why. I had to force it to reset once I’d fixed the actual problem. It also kept trying to bypass Redgate Flyway – my tool of choice for this project – in favor of an internal tool, but I got my way in the end.

In summary: what I learned from building an API with AI

Once you leave your comfort zone, your dependency on the AI increases — and that’s worth knowing upfront.
The API work pushed into unfamiliar territory. The less you can independently verify the output, the more important it is to have tests that can do it for you.

AI-generated code will use deprecated dependencies.
Not because it’s careless, but because transitive dependencies in the toolchain haven’t been updated. It’s not a disaster, but it’s noise you need to be ready for — and it won’t warn you before you run the install.

The AI won’t ask about things you didn’t mention.
Node.js wasn’t installed locally. The AI never asked, never flagged it, and never factored it in. It just generated instructions that silently assumed it was there. Gaps in your environment are your problem to surface.

Let it troubleshoot — it’s good at it.
Most of the coding errors and configuration problems that surfaced during testing were generated by the AI and fixed by the AI. Feed it the error, it finds the cause. That loop is genuinely useful.

It will try to bypass your chosen tools if you don’t hold the line.
CoPilot made repeated attempts to use an internal migration tool instead of my tool of choice, Redgate Flyway. No dramatic argument — just quiet persistence. You have to be equally persistent in pushing back.

Leaving branches intact is worth it.
Deleting them hides the real shape of the work — the back-and-forth, the fixes, the iterations. Keeping them gives anyone following along a much more honest picture of how AI-assisted development actually works.

The last word: CoPilot’s assessment of where dbRosetta is at the end of part 4

By completing this stage, we’ve established a secure and reliable bridge between dbRosetta’s PostgreSQL foundation and the broader ecosystem it will support. The API not only enforces best practices around authentication, input validation, and deployment hygiene, but also sets the stage for reproducible integrations with other platforms.

With this layer in place, contributors and downstream applications can query the database confidently, knowing that access is protected and performance is monitored. This milestone transforms dbRosetta from a static repository of translations into a living service, ready to be consumed by the WordPress interface we’ll build next.