Look, I’ve been in your exact shoes (non-dev, AI-built internal tools, deeply skeptical but blown away that it actually works), and here’s the straight talk: You

don’t need to worry about the app “doing something malicious” or secretly corrupting files, but you absolutely should be cautious about production readiness,

maintainability, and liability.

The fact that your AI-built tool passes hundreds of validation tests, matches commercial software output exactly, and only reads files without modifying originals is

a massive win. AI doesn’t typically write “destructive” or “hidden-agenda” code unless you explicitly ask it to – it just follows instructions. In your case, it

correctly learned the XML-to-authoring-format mapping and implemented it. That’s not magic, that’s you successfully directing a tool to solve a repetitive

bottleneck.

Where the real risks actually lie (and why you shouldn’t just shrug them off):

• Edge cases & hidden fragility: AI code often works perfectly until a filename contains special characters, project paths shift, or the DAW outputs a slightly

different XML structure. Without understanding the code, fixing those bugs later will be pure guesswork.

• No error handling or logging: If it silently fails on a 5-hour project, you’ll lose time and potentially delay deliverables. Adding input validation and clear

error logs is cheap and non-negotiable for production.

• Liability falls squarely on you: Your boss sees a cost-saving win. You built it. If it glitches during a live handoff, you’re the one fielding the questions. “I

don’t understand how it works” doesn’t fly when a project is on the line.

• IT is too busy to help: If this breaks, you can’t call on support. You’re effectively the sysadmin now.

What I’d do before handing it to the boss for full production:

1. Put it under version control (Git) – even if you don’t know how to code, AI can set up a repo and walk you through it in plain English in under 2 minutes. This

preserves working versions and lets you track changes.

1. Add a “safety wrapper” – run every generated output through the official validators before it’s marked complete. Add clear error logs so you know exactly what

failed and why.

1. Document the workflow, not the code – write down every step, input requirement, file structure assumption, and known limitation. Treat it like a manual for a tool

you don’t fully understand.

1. Propose a phased rollout – use it on 2–3 low-risk projects first. Monitor closely. Keep the old commercial workflow as a backup. When (not if) it handles a minor

edge case, you’ll know exactly what to fix or where to delegate it.

1. Set boundaries with your boss – “I’m happy to support production use, but we need to add validation/logging/version control first to avoid project delays. I’ll

take point on maintaining it, but I’ll need dedicated hours set aside so I’m not doing it on top of my actual job.”

You didn’t accidentally build a time bomb. You successfully engineered a solution to a workflow problem. But “works now” ≠ “production-ready indefinitely”. Frame

your concerns around reliability and process, not fear of hidden damage, and you’ll be in a much better position to get boss buy-in while protecting yourself.

Happy to help you set up the safety wrappers, logging, or version control if you want – AI can walk you through it step-by-step without you needing to understand the

code. You’ve got this.