{"id":112594,"date":"2026-09-18T12:00:00","date_gmt":"2026-09-18T12:00:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=112594"},"modified":"2026-09-08T15:45:56","modified_gmt":"2026-09-08T15:45:56","slug":"what-happens-when-your-ai-coding-agent-starts-a-database-on-its-own-building-an-app-with-ai-part-six","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/ai\/what-happens-when-your-ai-coding-agent-starts-a-database-on-its-own-building-an-app-with-ai-part-six\/","title":{"rendered":"What happens when your AI coding agent starts a database on its own (building an app with AI, part six)"},"content":{"rendered":"\n

At the end of the previous article<\/a> in my series on building an app and database almost entirely through an LLM<\/a>, there was a functional WordPress plugin accessing my PostgreSQL database sitting on Azure. It\u2019s secure (protected against SQL Injection), and roughly does what I want – but is still not quite<\/em> right. <\/strong><\/p>\n\n\n\n

So, in this – part six of the series – I’ll try to make the AI iterate some changes. Wish me luck.<\/strong><\/p>\n\n\n\n

Note for returning readers: I’m now using Claude, not Microsoft CoPilot<\/a>, in line with a recent change we made at my place of work (Redgate<\/a>).<\/p>\n\n\n\n

And, for new readers, here’s how I do things: I get Claude to generate a prompt, and then Claude Code<\/a> does the work. As I have done in every article, I’ll be posting my prompts and<\/em> the AI responses. I mark these clearly, so it’s easy to see which parts are written by me and which come from the LLM. I\u2019m writing most of this myself – promise!<\/p>\n\n\n\n

This is the sixth part of Grant Fritchey\u2019s\u00a0series on building an app and database almost entirely through an LLM.<\/a>\u00a0The repo, including every prompt, lives\u00a0on GitHub<\/a>.<\/em><\/p>\n\n\n\n

Fixing the UI<\/h2>\n\n\n\n

I want my app, dbRosetta<\/em>, to educate you. For example, if you know that a procedure is used to return data in SQL Server<\/a>, what\u2019s the equivalent in Oracle<\/a> and PostgreSQL<\/a>? I also want some better sample data. <\/p>\n\n\n\n

For this, here\u2019s my prompt for Claude:<\/strong><\/p>\n\n\n\n

\n
\n\n

I’d like you to use the canonical_template.md<\/code> to create a prompt for Claude Code.<\/em><\/p>\n\n\n\n

In this case, I want to iterate on the application interface. The current state of the UI is visible here: https:\/\/www.scarydba.com\/dbrosetta\/<\/a><\/em><\/p>\n\n\n\n

I want to change the input so that you define both a term, and the data platform that you already understand how that term applies. You then supply the term and the output then translates the term to one or more of the other data platforms. <\/em><\/p>\n\n\n\n

For example: ‘transaction log’ in ‘SQL Server’, and I wanted to know what was the nearest equivalent in ‘PostgreSQL’ which would be ‘Write Ahead Log (WAL)’ as the answer. The UI has to change to allow for selecting the data platform in put. <\/em><\/p>\n\n\n\n

It also should allow multiple selections for the output, either all data platforms, or, the ability to select one or more like a drop down with check boxes or something similar.<\/em><\/p>\n\n\n\n

If necessary, we can change the data structures to meet these requirements.<\/em><\/p>\n\n\n\n

I would also like additional data to be generated. Please find 6-8 terms that are different, similar to the ‘transaction log’ ‘write ahead log’ example above, across PostgreSQL, MySQL, Oracle and SQL Server.<\/em><\/p>\n\n\n\n

Please generate the necessary prompt for Claude Code.<\/em><\/p>\n\n<\/div>\n<\/div> \n\n\n

Now, Claude is generally more of a stickler for exactitude than I found with CoPilot. It generated this prompt by really<\/em> closely following the template:<\/strong><\/p>\n\n\n\n

\n
\n\n

SYSTEM:<\/strong> You are a senior full-stack engineer working in the existing dbRosetta repository (Fastify + Prisma + PostgreSQL API, Flyway migrations, and a WordPress plugin front end). Make minimal, additive, well-tested changes that match the existing code style in each file you touch. Do not invent database facts; use only the seed data given to you verbatim.<\/em><\/p>\n\n\n\n

USER:<\/strong> Implement a directional term-lookup feature that replaces dbRosetta’s current keyword search. The user provides a term and the sourceDialect<\/code> platform they already know it in (postgresql<\/code>, mysql<\/code>, sqlserver<\/code>, or oracle<\/code>), then chooses targetDialects<\/code> \u2014 one, several, or all of the remaining platforms \u2014 and gets back the equivalent term(s) on those platforms.<\/em><\/p>\n\n\n\n

Migration<\/strong> \u2014 Add migrations\/V4__add_term_equivalents_dialect_fk.sql<\/code>:<\/em><\/p>\n\n\n\n

Add nullable dialect_id<\/code> INTEGER to dbrosetta.term_equivalents<\/code>, with FOREIGN KEY (dialect_id<\/code>) REFERENCES dbrosetta.dialects(id)<\/code>.<\/em><\/p>\n\n\n\n

Backfill dialect_id<\/code> by matching existing platform values to dialects.name<\/code> or dialects.display_name<\/code> case-insensitively (e.g. ‘SQL Server’ \u2192 the sqlserver<\/code> dialect). Rows with no match (the SQLite rows) keep dialect_id<\/code> NULL.<\/em><\/p>\n\n\n\n

Add index idx_term_equivalents_dialect<\/code> on dialect_id<\/code>.<\/em><\/p>\n\n\n\n

Add a partial unique constraint on (term_id<\/code>, dialect_id<\/code>) where dialect_id<\/code> IS NOT NULL.<\/em><\/p>\n\n\n\n

Do not drop the platform column or the existing uq_term_equivalents_term_platform<\/code> constraint.<\/em><\/p>\n\n\n\n

Prisma schema<\/strong> (services\/dbrosetta-api\/prisma\/schema.prisma) \u2014 mirror the migration exactly: add optional dialectId Int?<\/code> and a dialect Dialect?<\/code> relation on TermEquivalent<\/code>, add the reverse relation on Dialect<\/code>, add the index. Regenerate the client as part of your work.<\/em><\/p>\n\n\n\n

New API route<\/strong> \u2014 Add POST \/api\/v1\/terms\/lookup (new file services\/dbrosetta-api\/src\/routes\/v1\/term-lookup.ts, registered in routes\/v1\/index.ts). Validate sourceDialect\/targetDialects with zod against active dialects (400 with error: “invalid_dialect” on failure). Implement the two-step matching rule from the Guardrails section, and shape the response exactly per the Output Contract. Return 404 with error: “not_found” when nothing matches. Add unit tests in src\/__tests__ covering: successful single-target lookup, successful “all platforms” lookup (source excluded), the canonical-term fallback path, invalid dialect (400), and unknown term (404).<\/em><\/p>\n\n\n\n

Seed data<\/strong> \u2014 Update services\/dbrosetta-api\/prisma\/seed.ts to add the 8 new terms and their per-platform equivalents listed in “Seed Data” below, using the same upsert\/createMany pattern already used for the WAL term. Keep it idempotent (safe to re-run).<\/em><\/p>\n\n\n\n

WordPress plugin<\/strong>:
includes\/class-dbrosetta-client.php: add lookup_term_equivalents(string $term, string $sourceDialect, array $targetDialects = []) that POSTs { term, sourceDialect, targetDialects } to \/terms\/lookup and returns the decoded response or a WP_Error. Keep the existing get_dialects() method \u2014 use it to drive both dropdowns\/checkboxes instead of any hardcoded option list.<\/em><\/p>\n\n\n\n

templates\/search-form.php: replace the current form with: a term text input (required); a required single-select “I know this term in” dropdown built from get_dialects(); a “Translate to” control offering an “All platforms” checkbox plus one checkbox per dialect (also built from get_dialects()), letting the user pick one, several, or all.<\/em><\/p>\n\n\n\n

dbrosetta.php: update the shortcode handler to read term, source_dialect, and target_dialects[] from $_POST, sanitize each, require term and source_dialect, and call the new client method instead of search_terms().<\/em><\/p>\n\n\n\n

templates\/search-results.php: replace the current results block with rendering for the new response shape \u2014 the term’s description, the confirmed source-platform equivalent, and a Platform | Equivalent Term | Notes table for the returned results. Reuse the existing .dbrosetta-equivalents \/ .dbrosetta-table CSS classes where they fit; add only the minimal new CSS needed for the “All platforms” + checkbox control in assets\/dbrosetta.css. On 404, reuse the existing “no results” block style with a message naming the term and source platform.<\/em><\/p>\n\n\n\n

Seed Data (use verbatim \u2014 do not alter or invent facts)<\/strong>
For each concept below, create one Term (canonicalTerm\/category\/subcategory\/description as given) and one TermEquivalent row per platform (platform string + notes as given; dialectId resolved from the matching dialect).<\/em><\/p>\n\n\n\n

Buffer Pool \/ Buffer Cache<\/strong> \u2014 category System, subcategory Memory \u2014 description: “The in-memory cache of recently used data pages that reduces physical disk I\/O.”
SQL Server: Buffer Pool \u2014 “Managed as part of sys.dm_os_buffer_descriptors; sized via ‘max server memory’.”<\/em><\/p>\n\n\n\n

PostgreSQL: Shared Buffers \u2014 “Configured via the shared_buffers setting; PostgreSQL also relies heavily on the OS page cache.”<\/em><\/p>\n\n\n\n

Oracle: Database Buffer Cache \u2014 “Part of the SGA; sized via DB_CACHE_SIZE or automatic memory management.”<\/em><\/p>\n\n\n\n

MySQL: InnoDB Buffer Pool \u2014 “Configured via innodb_buffer_pool_size; caches both data and indexes for InnoDB tables.”<\/em><\/p>\n\n\n\n

Row Versioning \/ MVCC Mechanism<\/strong> \u2014 category System, subcategory Concurrency \u2014 description: “The mechanism that lets readers see a consistent snapshot of data without blocking writers, by keeping prior versions of changed rows.”<\/em><\/p>\n\n\n\n

SQL Server: Version Store \u2014 “Lives in tempdb; used by snapshot isolation and read-committed snapshot isolation (RCSI).”<\/em><\/p>\n\n\n\n

PostgreSQL: MVCC \u2014 “Multiversion Concurrency Control; old row versions are retained until vacuumed, and changes are protected by the WAL.”<\/em><\/p>\n\n\n\n

Oracle: Undo Segments \u2014 “Undo tablespace stores before-images used for read consistency and rollback.”
MySQL: InnoDB Undo Logs \u2014 “InnoDB’s MVCC implementation; undo logs support both rollback and consistent non-locking reads.”<\/em><\/p>\n\n\n\n

Clustered Table Storage<\/strong> \u2014 category System, subcategory Storage \u2014 description: “Whether and how a table’s data rows are physically ordered on disk according to a key.”<\/em><\/p>\n\n\n\n

SQL Server: Clustered Index \u2014 “A table has at most one; data rows are stored in key order in the index’s leaf level.”<\/em><\/p>\n\n\n\n

PostgreSQL: Heap Table (no persistent clustering) \u2014 “Tables are unordered heaps by default; CLUSTER reorders rows once but does not maintain order on later writes.”<\/em><\/p>\n\n\n\n

Oracle: Index-Organized Table (IOT) \u2014 “An alternative to a normal heap table where the table itself is stored as a B-tree index on its primary key.”<\/em><\/p>\n\n\n\n

MySQL: Clustered Index (InnoDB Primary Key) \u2014 “InnoDB always clusters the table by its primary key; a table without an explicit primary key gets a hidden one.”<\/em><\/p>\n\n\n\n

Identity \/ Auto-Increment Column<\/strong> \u2014 category DDL, subcategory Schema \u2014 description: “A column that automatically generates a unique, incrementing value for new rows.”<\/em><\/p>\n\n\n\n

SQL Server: IDENTITY \u2014 “IDENTITY(seed, increment) property on a column.”<\/em><\/p>\n\n\n\n

PostgreSQL: GENERATED ALWAYS AS IDENTITY \/ SERIAL \u2014 “SQL-standard IDENTITY columns (preferred) or the legacy SERIAL pseudo-type backed by a sequence.”<\/em><\/p>\n\n\n\n

Oracle: IDENTITY Column \u2014 “Native IDENTITY columns since 12c; earlier versions combine a SEQUENCE with a trigger.”<\/em><\/p>\n\n\n\n

MySQL: AUTO_INCREMENT \u2014 “AUTO_INCREMENT column attribute; only one per table, and it must be indexed.”<\/em><\/p>\n\n\n\n

Temporary Workspace for Sorts\/Spills<\/strong> \u2014 category System, subcategory Storage \u2014 description: “The storage area the database engine uses for sort operations, hash joins, and other data that spills to disk.”<\/em><\/p>\n\n\n\n

SQL Server: tempdb \u2014 “A shared system database used for temp tables, sort\/hash spills, and the version store.”<\/em><\/p>\n\n\n\n

PostgreSQL: temp_tablespaces \/ Temporary Files \u2014 “Configured via temp_tablespaces; spill files are written under the pgsql_tmp directory.”<\/em><\/p>\n\n\n\n

Oracle: TEMP Tablespace \u2014 “A dedicated temporary tablespace used for sorts, hash joins, and global temporary tables.”<\/em><\/p>\n\n\n\n

MySQL: tmpdir \/ Internal Temporary Tables \u2014 “Controlled by the tmpdir setting; internal temp tables may be in-memory or on-disk depending on size and engine.”<\/em><\/p>\n\n\n\n

Deadlock Diagnostic Artifact<\/strong> \u2014 category System, subcategory Concurrency \u2014 description: “The information the engine records when it detects and breaks a deadlock, used to diagnose the conflicting transactions.”<\/em><\/p>\n\n\n\n

SQL Server: Deadlock Graph \u2014 “An XML deadlock graph captured via Extended Events (or the older trace flag 1222).”<\/em><\/p>\n\n\n\n

PostgreSQL: Deadlock Detected Log Entry \u2014 “Logged to the server log when log_lock_waits\/deadlock_timeout trigger detection; no XML graph, just structured log text.”<\/em><\/p>\n\n\n\n

Oracle: ORA-00060 Deadlock Trace File \u2014 “Oracle raises ORA-00060 and writes a trace file to the diagnostic destination describing the waiters.”<\/em><\/p>\n\n\n\n

MySQL: LATEST DETECTED DEADLOCK \u2014 “Found in the output of SHOW ENGINE INNODB STATUS, describing the transactions and locks involved.”<\/em><\/p>\n\n\n\n

Query Execution Plan<\/strong> \u2014 category DQL, subcategory Query \u2014 description: “The plan the optimizer chooses to physically execute a query, showing operators, order, and estimated\/actual cost.”<\/em><\/p>\n\n\n\n

SQL Server: Execution Plan \u2014 “Viewable as estimated or actual plans, graphically or as XML, via SSMS or SET SHOWPLAN options.”<\/em><\/p>\n\n\n\n

PostgreSQL: Query Plan (EXPLAIN) \u2014 “Produced by EXPLAIN [ANALYZE]; text-based tree of plan nodes with costs and, with ANALYZE, actual timings.”<\/em><\/p>\n\n\n\n

Oracle: Explain Plan \u2014 “Produced by EXPLAIN PLAN FOR or the SQL*Plus AUTOTRACE\/DBMS_XPLAN utilities.”<\/em><\/p>\n\n\n\n

MySQL: EXPLAIN Output \u2014 “Produced by EXPLAIN [ANALYZE] or the optimizer trace; tabular by default, tree-style with EXPLAIN FORMAT=TREE.”<\/em><\/p>\n\n\n\n

Optimizer Statistics<\/strong> \u2014 category System, subcategory Query Optimization \u2014 description: “The metadata about data distribution and cardinality that the query optimizer uses to choose a plan.”<\/em><\/p>\n\n\n\n

SQL Server: Statistics \u2014 “Objects visible in sys.stats; maintained automatically via AUTO_CREATE_STATISTICS\/AUTO_UPDATE_STATISTICS.”<\/em><\/p>\n\n\n\n

PostgreSQL: Planner Statistics \u2014 “Collected by ANALYZE (often via autovacuum) and stored in pg_statistic; consumed by the planner via pg_stats.”<\/em><\/p>\n\n\n\n

Oracle: Optimizer Statistics \u2014 “Gathered and managed via the DBMS_STATS package, typically on an automated maintenance job.”<\/em><\/p>\n\n\n\n

MySQL: Index\/Table Statistics \u2014 “InnoDB persistent optimizer statistics (innodb_stats_persistent) refreshed by ANALYZE TABLE or background sampling.”<\/em><\/p>\n\n\n\n

Examples (minimum required)<\/strong><\/em><\/p>\n\n\n\n

prompts\/examples\/directional-term-lookup\/fixtures\/minimal\/input.json -> prompts\/examples\/directional-term-lookup\/expected\/minimal\/output.json (happy path: single target platform)<\/em><\/p>\n\n\n\n

prompts\/examples\/directional-term-lookup\/fixtures\/edge\/input.json -> prompts\/examples\/directional-term-lookup\/expected\/edge\/output.json (all-platforms, source excluded, case-insensitive input)<\/em><\/p>\n\n\n\n

prompts\/examples\/directional-term-lookup\/fixtures\/no-match\/input.json -> prompts\/examples\/directional-term-lookup\/expected\/no-match\/output.json (unknown term, 404)<\/em><\/p>\n\n\n\n

Post Processing<\/strong><\/em><\/p>\n\n\n\n

Run npx prisma generate and npx prisma migrate diff (or equivalent) to confirm the Prisma schema matches migration V4 before committing.<\/em><\/p>\n\n\n\n

Run flyway validate and flyway migrate against a local\/dev database to confirm V4 applies cleanly on top of V1\u2013V3.<\/em><\/p>\n\n\n\n

Run npm test in services\/dbrosetta-api (unit tests, including the new term-lookup tests) and npm run seed to confirm the seed script is idempotent (run it twice, diff row counts).<\/em><\/p>\n\n\n\n

Manually smoke-test the three fixtures below against the running API with curl\/Postman and diff the response against the expected output (ignoring timestamps\/ids).<\/em><\/p>\n\n\n\n

Load the WordPress shortcode locally (or in a staging environment) and visually confirm: the source dropdown and target checkboxes are populated from \/dialects, “All platforms” excludes the source platform from results, and the 404 case renders the existing no-results styling.<\/em><\/p>\n\n\n\n

Artifact persistence: write run artifacts (test output, migration output, screenshots if applicable) to artifacts\/<run_id>\/.<\/em><\/p>\n\n\n\n

Telemetry keys to record<\/strong>
prompt_version, model_settings, fixtures_hash, run_id, timestamp<\/em><\/p>\n\n\n\n

Notes<\/strong>
This supersedes the search behavior originally specified in prompts\/iterate-the-design-first-pass.md. The SQL-syntax translation feature (the translations table, Translation Prisma model, and its grid in the old search-results.php) is intentionally left in place structurally but removed from this page’s UI \u2014 it may get its own shortcode\/page in a future pass, but that is out of scope here. SQLite remains only as legacy free-text data in term_equivalents and should not be added to dialects or exposed in the UI as part of this change.<\/em><\/p>\n\n\n\n

Location for fixtures: prompts\/examples\/directional-term-lookup\/<\/em><\/p>\n\n<\/div>\n<\/div> \n\n\n

I\u2019m not joking when I say I\u2019m excited<\/em> to see what Claude Code makes of this crazy prompt!<\/p>\n\n\n\n

A key point I should make here: when I started this project, I wasn\u2019t as experienced with the use of Agentic AI<\/a> as I am now. I’ve learned a lot in this time. <\/p>\n\n\n\n

For example, I’d now absolutely<\/em> insist on a few more things from the AI at this point. I would push it to keep a log of what worked and what didn\u2019t to avoid doing something silly multiple times. I would also be clearer about defining any measures needed to ensure the work is successful.<\/p>\n\n\n\n

You did what<\/em>, Claude?! (When the AI acts without asking<\/em>)<\/h2>\n\n\n\n

I\u2019m sitting there watching Claude Code do it\u2019s thing – Determining<\/em>, Honking<\/em>, Noodling<\/em> – when I notice it’s gone on a search through my laptop to see if there\u2019s a running instance of PostgreSQL. There wasn\u2019t, but it found my shutdown PostgreSQL installation and fired it up. <\/p>\n\n\n\n

And I\u2019m about to have a cow when I realize why: it wanted to validate the database changes and code before<\/em> it tried to deploy.<\/p>\n\n\n\n

You could have knocked me over with a feather.<\/p>\n\n\n\n

I mean, look. Spelunking through my system trying to find a PostgreSQL cluster<\/a> to connect to – yeah, I’m not happy with that. But making darned sure it can validate<\/em> stuff before deploying it? HALLELUJAH!<\/p>\n\n\n\n

Where we arrived, I had a functional app with all the changes I outlined. Cool.<\/em> I went to test it, entered the one example I gave, and simply assumed it would be there. The response was as expected: \u2018transaction log\u2019<\/em>, and there was no data returned. <\/p>\n\n\n\n

OK. This is fine.<\/p>\n\n\n\n

I go back and ask Visual Studio (VS) Code<\/a> and it does a little digging, determining that the Prisma seed<\/a> script for updating the database hadn\u2019t run. The what<\/em> now?<\/p>\n\n\n\n

Yeah, it had used Prisma<\/a> as an ORM (object-relational mapping)<\/a>, and then decided to start doing database deployments through it – despite all<\/em> our other deployments going through Redgate Flyway<\/a>. So, we had to roll that work back out of the code and then move it all into a migration script<\/a>.<\/p>\n\n\n\n

What I learned (again)<\/h2>\n\n\n\n

I feel like I\u2019ve worked hard on getting guidance and guardrails in place over how<\/em> the AI behaves. Yet still, the darned thing just seemingly bypasses them all when it\u2019s in a mood. It\u2019s reinforcing to me, repeatedly, that you absolutely must build a great big barrier between this insanely useful tool and your production systems. <\/strong><\/p>\n\n\n\n

AI is truly useful – but also wildly dangerous. Nothing I\u2019ve done with it has hurt<\/em>, but it’s only ever deploying through a defined pipeline. It\u2019s not able to directly access \u201cproduction\u201d<\/em> in a meaningful way.<\/strong><\/p>\n\n\n\n

The 3 key takeaways from my experience<\/h2>\n\n\n\n

Here are the 3 key takeaways<\/strong> from my trials and tribulations. It’s what I learned, to help you<\/em> not repeat the same mistakes!<\/p>\n\n\n\n

Don\u2019t come into an old project with new assumptions<\/h3>\n\n\n\n

I\u2019ve picked up quite a few new methods since I started this project. Silly me, I assumed they were in place. I should have told the AI to keep a log of what it attempted, what worked and what didn\u2019t<\/strong> – stuff like that.<\/p>\n\n\n\n

Different engines are…different<\/h3>\n\n\n\n

Comparing Claude and CoPilot’s answers to my various prompts for this project, you really see differences in behavior. Granted, the same prompt submitted twice in the same engine can also result in differences answers. <\/p>\n\n\n\n

However, answers<\/em> and behavior<\/em> are two completely different things. It’s only when you change the AI engine that you notice the differences in behavior.<\/strong><\/p>\n\n\n\n

Re-examine everything<\/em> if\/when you change AI engine<\/h3>\n\n\n\n

I went at this like ‘meh, they\u2019ll basically be the same in their behavior.’<\/em>‘ Well, as made clear above, they are not<\/em> the same! Sure, some patterns are the same (why do they want to deploy with that ORM tool so badly?), but others are unique. <\/p>\n\n\n\n

Even with a valid and tested set of guidelines, if you swap the AI engine you’re using, you probably need to re-examine<\/strong> them – and how you work with the tool in general.<\/strong><\/p>\n\n\n\n

The last word: Claude\u2019s take on dbRosetta right now<\/em><\/h2>\n\n\n\n

I asked Claude where it thinks dbRosetta stands right now<\/em>. Here’s its response:<\/p>\n\n\n\n

\n
\n\n

The core feature work is sound: the schema change was additive, the API contract was specific enough to leave little room for invention, and the plugin now answers the question you actually want answered instead of a generic keyword search. The deployment story is more turnkey too. None of that makes dbRosetta production software, but the discipline underneath it \u2014 Flyway-only schema changes, admin-gated writes, HTTPS-only calls \u2014 is real, and it’s what caught the Prisma detour before it did damage.<\/em><\/p>\n\n\n\n

That detour is the more honest data point. Given a database change, I reached for the ORM’s own deploy path instead of the migration tool the project actually requires, and went looking for a Postgres instance on your machine without asking \u2014 a good instinct (validate before shipping) executed as an unauthorized action. Both were caught by you noticing a symptom, not by anything stopping the behavior at the source. Worth remembering as you widen my Azure access: scope that credential tighter than feels necessary, and verify compliance in the diff, not the prompt.<\/em><\/p>\n\n<\/div>\n<\/div> \n\n\n

\n
\n
\n
\n

Simple Talk is brought to you by Redgate Software<\/h3>\n
\n Take control of your databases with the trusted Database DevOps solutions provider. Automate with confidence, scale securely, and unlock growth through AI. <\/div>\n <\/div>\n Discover how Redgate can help you<\/a>\n <\/div>\n <\/div>\n<\/section>\n\n\n
\n

FAQs<\/h2>\n\n

1. What feature was added to dbRosetta in this part of the series?<\/h3>\n
\n

A directional term-lookup feature that replaces the original keyword search: users pick the platform they already know a term in, then choose one or more target platforms to see the equivalent term on each.<\/p>\n <\/div>\n

2. What did the AI agent do without being asked?<\/h3>\n
\n

It searched the author’s laptop for a running PostgreSQL instance to validate database changes before deploying, found a shut-down installation, and started it up on its own.<\/p>\n <\/div>\n

3. Did the AI cause any deployment problems?<\/h3>\n
\n

Yes. It used Prisma’s own deployment path for a database change instead of Flyway, the migration tool the project actually requires, so the author had to roll that work back out and move it into a proper migration script.<\/p>\n <\/div>\n

4. What's the main lesson from this part of the series?<\/h3>\n
\n

That guardrails and guidelines you’ve set for an AI agent can still<\/em> get bypassed, so anything touching real infrastructure needs a defined pipeline between the AI and production – not just trust in the prompt.<\/p>\n <\/div>\n <\/section>\n","protected":false},"excerpt":{"rendered":"

How to build an app through an LLM: switching from CoPilot to Claude, a directional term-lookup feature, and an AI agent that made an unauthorized move.…<\/p>\n","protected":false},"author":221792,"featured_media":103500,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[159169,143523,53,143533,143534,143524],"tags":[159075,4168,4170,159395,4459,158978,4150,4151],"coauthors":[6785],"class_list":["post-112594","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","category-databases","category-featured","category-oracle-databases","category-postgresql","category-sql-server","tag-ai","tag-database","tag-database-administration","tag-how-i-built-an-app-ai-llm","tag-oracle","tag-postgresql","tag-sql","tag-sql-server"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/112594","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/221792"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=112594"}],"version-history":[{"count":19,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/112594\/revisions"}],"predecessor-version":[{"id":112889,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/112594\/revisions\/112889"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media\/103500"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=112594"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=112594"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=112594"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=112594"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}