(Python_backup tool) From AI-Generated Draft Code to an Internal Backup Tool People Actually Use

Overview

We set out to automate a task our team kept doing manually — backing up local folders to network storage — by building a desktop program from scratch. We started with a requirements document and a rough draft of code generated by an AI coding tool.

Why We Chose This

To run directly on internal PCs with no separate install process or server infrastructure, we decided on a single executable built on Python's standard GUI library, tkinter.
The AI-generated draft only handled basic file copying, so we judged that putting it into real use would require adding a substantial amount of safety and usability work.

What We Added Beyond the Draft

| Item | Draft code | This implementation | |------|-----------|-----------| | Saved settings | None (re-entered every time) | Connection info auto-saved to and loaded from a file (with light obfuscation to avoid storing it in plain text) | | Network browsing | None (paths typed manually) | Tree-view folder browser UI | | Progress | Based on file count (inaccurate) | Real-time percentage based on bytes copied in chunks | | Thread safety | Background thread touched the UI directly (risky) | Main thread polls a queue for status updates on an interval | | Connection management | Connect only | Connect, disconnect, reconnect, plus timeout handling | | Disk space | No check | Checks free space on the destination before copying starts | | Error handling | Single catch-all exception | Distinct handling per case — permission errors, path errors, etc. | | Logging | None | Logs written to both a file and the on-screen log panel | | Shutdown handling | None | Confirmation prompt on exit during an active task, plus a safe disconnect |

Key Architectural Decisions

1. Single-file structure

For ease of distribution and execution, we kept everything as a single executable rather than splitting it into multiple modules, while still logically separating responsibilities into classes internally (settings management, connection management, browser UI, main app).

2. Queue-based UI updates

tkinter can only be safely driven from a single thread, so having a background thread that copies files touch UI widgets directly risks unpredictable errors.

background_worker_thread:
    copy progresses → push status message to progress_queue

main_thread (polls on an interval):
    pop messages from progress_queue → update progress bar and label if present

This pattern let us reflect progress safely without ever freezing the UI.

3. Chunked copying

Instead of copying an entire file in one go, we copy it in fixed-size chunks and calculate exact progress based on the number of bytes copied so far.

4. How connection info is stored

Rather than bringing in a full encryption library, we went with lightweight obfuscation that just avoids storing plain text, with no added dependencies. This prioritized "usable with zero install overhead" over security strength.

Retrospective

AI-generated drafts make a great starting point, but we reconfirmed that getting to real-world use requires separately filling in "productization" concerns — exception handling, thread safety, usability.
Deliberately noting up front what we were leaving unfinished for this version (a cancel feature, a log panel, etc.) made it much easier to decide what to prioritize in later versions.