Like most of you, I’ve been using AI large language models (LLMs) at work and at hobby level for a couple of years now. Snippets of code, the odd data conversion, a small database for a presentation.

What I hadn’t done — and what kept nagging at me — was build an entire application, end-to-end, through AI. Nothing more, nothing less. So that’s what this series is about. I’m building a real, small, useful application called dbRosetta, and I’m doing as much of it as possible by talking to an LLM.

The premise is deliberately tiny. Different databases give different names to similar concepts. A SQL Server stored procedure isn’t quite a PostgreSQL function, but the family resemblance is obvious. dbRosetta is a Rosetta Stone for that. Pick a source database, pick a target, type a term, get the equivalent — plus a link to the docs and a short description. That’s it. Nothing clever.

So, the app is not the interesting part – it’s how the app actually gets built. Let’s get into it.

Before we begin: establishing the rules

Throughout this series, I’ll post the prompts and the responses. Anywhere the AI wrote text or code, I’ll mark it. The repo lives on my public GitHub, under Apache-2.0. The app will run at scarydba.com — I have the most control there, and if I do something silly I won’t be breaking Redgate. The database is PostgreSQL on Azure Flexible Server.

For the LLM, I’m using Microsoft Copilot (work pays for it, which is reason enough), with GitHub CoPilot inside vsCode for code generation, completion and validation. Whenever it hallucinates or wanders off down a rabbit hole, I’ll step in. Otherwise, the rule is: let the AI drive as much as it sensibly can. Here’s my first prompt, and the response it gave me:

So, the current tool list is:

That’s the setup. Where things got interesting is what happened the moment I tried to use it.

“The AI picked database first”

I’d assumed I knew how this would start. I’d write a prompt outlining what dbRosetta needed to do, the AI would suggest a stack, and we’d start coding. The first decision I expected to make — and was quietly looking forward to making — was whether to build code-first or database-first. As a DBA, you can probably guess where I fell on that.

I never got to make the call. I asked Copilot to recommend an approach, and it came back with a hybrid: start database-first for the canonical examples, build the tooling code-first around it. The relevant bit of its response:

Short recommendation — Hybrid, start database-first for examples, support code-first for tooling

Start with a database-first approach for the canonical reproducible examples: author baseline schemas and migrations as SQL artifacts that are authoritative. This keeps examples portable, platform-focused, and easy to run in CI using Dockerized DBs.

Build tooling (generators, validators, orchestration) as code-first modules so contributors can extend transformations programmatically.

Now, in fairness to Copilot, it almost certainly picked up on my preferences from context. I talk databases at it a lot. But the point stands: the AI made the architectural call before I did, and the call was a reasonable one. I went with it.

I wasn’t so lucky next time around.

When AI runs away with itself

My next prompt took things seriously off the rails. Silly me.

I asked Copilot to give me the structure of the prompts I’d need to actually design the database. That’s all I wanted – just a template, or an outline.

What I got back was Copilot deciding we were ready to start coding. I pushed back. It pushed forward. I pushed back again. It kept producing scaffolding, file structures, schema migrations – things I’d never asked for and didn’t want yet. After a few rounds, I gave up trying to nudge and did this:

No. Forget all of the previous conversation.

Allow me to first define the project: dbRosetta is an example project created in order to write a series of articles, illustrating how a person could use an LLM to create a complete application and database. The core behavior of dbRosetta is simple enough in its first iteration. A person selects the database to translate from, and the database to translate to, for example FROM: PostgreSQL TO: Microsoft SQL Server.

They then provide a term, for example ‘Function’. Then that term is translated from the PostgreSQL term to the equivalent SQL Server term, ‘Procedure’. In addition, a link to the appropriate documentation and a short description of the term are provided.

The application will run on WordPress. The database will be hosted on Azure PostgreSQL. The app will be built within vsCode using GitHub Copilot driven by inputs constructed here using you.

Is that an adequate starting point?

It mostly was…

But it also immediately tried to turn that definition into article #1, which I had to head off as well — I’m writing the articles, not it.

Finally, after a couple more rounds of redirection, we finally landed in the same place: a milestone-mapped series, with each article paired to a reproducible artifact in the repo. Project scope, prompt design, database design, deployment, front end, MVP, testing, iteration. That’s the rough plan.

Lesson one of this experiment, written down properly: an LLM is like a puppy who knows you have treats. It’s desperately, sincerely eager to please you. It will absolutely run away with itself if you let it — and once a concept is in the conversation, getting it back out is genuinely hard.

For example, it still keeps trying to slip schema migrations into our discussion – I never asked for schema migrations. I did, however, mention ‘translation’ a lot. I bet the vector distance between ‘translation’ and ‘migration’ in the context of databases is small enough that the model can’t quite let go. That’s what these things do.

The prompt template

Once the scope was nailed down, I asked for a canonical prompt template — a single file structure we’d use for every prompt in the project. I didn’t specify just the template, though, so Copilot promptly started redefining behaviors I’d already locked down. What followed was another round of “no, just the template.”

Eventually we landed somewhere useful. Every prompt in the project lives at prompts/templates/<slug>.md and follows the same shape: frontmatter (version, author, model settings), then Intent, Context, Input Contract, Output Contract, Acceptance Criteria, Guardrails, the literal template prompt itself, worked examples for both the happy path and an edge case, post-processing checks, and telemetry to record.

The acceptance criteria are the load-bearing part: each one is a testable sentence that maps to a CI assertion. The guardrails matter almost as much.“Do not fabricate authoritative URLs” is the one I care about most, given the whole point of the app is to link people to real documentation.

I’ll publish the full template alongside the repo when we get to the database design article. The point worth flagging now is that I made the template before writing a single line of schema or code. That feels backwards if you’re used to writing prompts ad-hoc — but if every prompt is going to produce an artifact you have to verify, you want the verification rules nailed down before the AI ever generates anything.

What I’d tell you to do differently in week one

A few things stand out, looking back at the first stretch of this:

What’s next

The next article in the series is the one I’ve been looking forward to writing: actually designing the database. I’m going to do something slightly mischievous with it — I’ll write a prompt for the schema, and I’ll let Copilot generate one of its own, and we’ll see which produces something I’d be happier to deploy. Place your bets.