I'm a sysadmin who also develops and maintains reliable internal tools with Python and Flask. Our COO, who has little technical or coding experience, recently used an AI tool to generate a full dashboard as one enormous HTML file. It contains thousands of lines of poorly structured JavaScript, unpinned libraries loaded from external CDNs, unclear data sources, and no obvious security, testing, deployment, or support model.
He asked me to review it and mentioned plans to expand it. I'm concerned about security, licensing, data exposure, correctness, maintainability, and the risk that I'll become responsible for supporting an application I didn't design. I also don't want to respond in a way that alienates an executive or makes me look uncooperative.
How would you handle this conversation professionally? Should I treat the file as a prototype and rebuild it properly, recommend an existing dashboard platform, establish strict boundaries, or refuse responsibility unless the company provides time and budget?
4 Answers
Treat it as a prototype and requirements document, not a production application. Start by asking what business problem and metrics he wants, then explain that the current implementation needs a proper architecture, approved data sources, authentication, testing, deployment, and an ownership model. Offer a few options: use an existing BI platform, rebuild it as a supported internal application, or keep it as an isolated experiment. Put the estimated effort, risks, tradeoffs, and impact on your existing work in writing so he can choose knowingly.
Be direct without calling his work garbage. Say something like: “The concept is useful, but I can’t approve this for production in its current form. I found concerns around third-party dependencies, data access, security, accuracy, and long-term support. If this becomes a company system, we’ll need dedicated time, a budget, and a documented support owner.” Then ask him to prioritize it against your current responsibilities. Never casually accept ownership of an undocumented system just because it came from an executive.
Use business language rather than code-quality insults: risk, cost, availability, compliance, recovery, and opportunity cost are more persuasive than explaining how ugly the JavaScript is.
You can use an AI code-review tool as one input, but don’t make it the authority or present its output as proof. Perform your own review and document specific findings: unsupported dependencies, unverifiable calculations, exposed data, lack of tests, fragile data imports, and unclear ownership. The strongest position is not “I refuse because AI wrote it”; it’s “I can help turn this into a supported project, but I won’t silently inherit an unreviewed production system.”
Before running or hosting it, inspect where the data comes from, what credentials it uses, what external libraries it loads, and whether any company information was submitted to an AI service. Keep it in a sandbox with sample data until security and legal concerns are resolved. Require pinned dependencies, read-only access where possible, approved hosting, authentication, logging, backups, and a rollback plan. If your organization has a security or change-management process, send it through that process like any other application.
This also gives him credit for defining the desired dashboard while making it clear that turning a visual prototype into a reliable service is a separate project.