The 10-point checklist for fixing AI-generated Python scripts

AI can write a script in 90 seconds, but the gap between a prototype and a distributable tool is where engineering happens. A developer's checklist offers a rubric.

An AI generates a functional Python script in ninety seconds. It runs once, successfully. Then it gets duplicated as script_v2_FINAL.py, hard-coded paths and all, waiting to fail silently on a teammate's machine.

That gap between "runs on my machine" and "I'd let someone else run this" is the actual engineering work. A developer writing on Dev.to provides a ten-point checklist to bridge that gap, turning a fragile prototype into a distributable tool.

The "runs on my machine" problem

The author presents a common scenario: a simple expense reporting script. It reads a CSV, aggregates totals, and flags large expenses. The initial version works, but contains multiple systemic flaws. A hardcoded input path (/Users/me/Downloads/expenses.csv) ensures it only runs for the original author.

The script uses a bare except: block, a practice that swallows all errors indiscriminately. This could hide a legitimate bug in the code itself and lead the script to continue running with an empty dataset. Columns are accessed by position (row[1], row[2]), which is brittle. If the CSV schema changes, the script will crash with an unhelpful IndexError. This is the baseline quality often produced by generative AI when given a simple prompt.

Hardening the script with a checklist

The proposed fix is a manual checklist applied before sharing any code. The first items focus on resilience and configuration.

For error handling, the failure is a raw traceback or a silent error. The fix is to wrap I/O and parsing logic in specific exceptions. Instead of a generic except:, the code should catch FileNotFoundError or csv.Error. Failures must produce actionable error messages for the user and exit with a non-zero status code to signal failure to other programs.

Separating code from configuration

The second checklist item targets hardcoded values. Secrets, API keys, and user-specific file paths do not belong in source code. The fix is to move this configuration to command-line arguments or environment variables.

The author suggests a simple, effective check: grep the code for terms like api_key =, password =, token =, and absolute home directory paths before any commit. This prevents credentials from leaking and makes the tool adaptable to different environments without code changes. The script should also validate its inputs, checking that files exist and data is well-formed before processing begins.

WHAT WE'D CHANGE

The checklist is a strong starting point for a solo developer, but it relies entirely on manual discipline. This does not scale. A modern engineering practice would automate the enforcement of these rules, not just list them.

The first addition should be automated tooling. Static analysis tools like flake8 for style, black for formatting, and mypy for type checking can catch many of these issues before the code is ever run. These checks should be integrated into a pre-commit hook or a continuous integration pipeline, making them a required gate for all code changes. This transforms a personal checklist into a team-wide, enforceable standard.

The author mentions pytest but does not build it into the checklist. This is a critical omission. A script is not shippable without an automated test suite. Tests should cover the primary success path, but more importantly, they must verify the script's behavior with malformed data, missing files, and other edge cases. The checklist addresses error handling in the code; tests prove it works.

LANDING

This process is not about writing perfect code on the first try. It is about establishing a system to harden a functional prototype into a reliable tool. AI can accelerate the creation of that first draft, but it rarely performs the engineering work of considering failure modes, configuration, or usability for others. That remains the developer's responsibility. A checklist provides the rubric, but automation provides the leverage.

The investor read

This checklist is a proxy for engineering discipline. For investors evaluating early-stage technical teams, particularly those heavily reliant on AI for code generation, the ability to articulate these principles is a de-risking signal. A team that ships prototypes is standard; a team that has a system for hardening those prototypes into reliable tools will have lower operational debt and a more scalable codebase. This signals technical maturity beyond just a working demo. A pre-seed founder who can explain their process for error handling, configuration management, and input validation is a stronger bet than one who cannot. It indicates they can build a product, not just a feature.

Pull quote: “That gap between "runs on my machine" and "I'd let someone else run this" is the actual engineering work.”