Project Manager| AWR Development (BD) Ltd. Cox's Bazer , Bangladesh
Hi everyone!
As non-IT project leaders, many of us are now using AI to write Python scripts and automate workflows without writing code from scratch ourselves. It feels like a superpower—but it also comes with real risk.
In civil engineering, we would never build without verifying calculations. Yet, with AI, it’s easy to blindly run code that looks right, even if it hides critical bugs, flawed logic, or data risk underneath.
How are you verifying AI-generated tools and scripts before trusting them with live project operations?
Golam
Saving Changes...
Sort By:
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
An important concern. The real risk may be less that non-coders are using AI to generate scripts and more that organizations allow code to enter live operations without assurance proportional to its impact. A script should not be trusted because it runs or because its output looks plausible. It should be tested against known cases, reviewed for data access and failure modes, executed first in a controlled environment, and independently reviewed when it can materially affect decisions, finances, safety, or customer data. Perhaps the key principle is simple: the greater the authority given to the automation, the stronger the evidence required before trusting it.
...
1 reply by Md. Golam Rob Talukdar
Jul 26, 2026 12:25 PM
Md. Golam Rob Talukdar
...
Dear Luis I have created several automations for my own needs, written quite a few large Python scripts by the AI, and have many libraries installed on my computer. In fact, I am doing these scripts tasks blindly. day by day .
At first it may seem true, but when I go to check this script with another model, it catches many errors.
Project Manager| AWR Development (BD) Ltd. Cox's Bazer , Bangladesh
Jul 26, 2026 2:59 AM
Replying to Luis Branco
...
An important concern. The real risk may be less that non-coders are using AI to generate scripts and more that organizations allow code to enter live operations without assurance proportional to its impact. A script should not be trusted because it runs or because its output looks plausible. It should be tested against known cases, reviewed for data access and failure modes, executed first in a controlled environment, and independently reviewed when it can materially affect decisions, finances, safety, or customer data. Perhaps the key principle is simple: the greater the authority given to the automation, the stronger the evidence required before trusting it.
Dear Luis I have created several automations for my own needs, written quite a few large Python scripts by the AI, and have many libraries installed on my computer. In fact, I am doing these scripts tasks blindly. day by day .
At first it may seem true, but when I go to check this script with another model, it catches many errors. Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Dear Md. Golan
Thank you for sharing that so openly.
Using a second model to review the code is a useful additional check, but I would not treat it as independent validation, since both models can miss the same issue or introduce different ones.
The immediate priority may be to separate low-risk personal scripts from anything that can alter real data, affect decisions, access sensitive information, or create operational dependency. For the latter, I would use test cases with known results, run the code in an isolated environment, review permissions and libraries, keep version control and rollback capability, and seek competent human technical review before relying on it.
AI can help generate and inspect code, but the evidence that makes an automation trustworthy still has to come from testing, control, and accountable human review. Saving Changes...