She pressed Ctrl + S like she had a hundred times before. A save dialog appeared. She glanced at the format dropdown and, without thinking, selected "Excel Workbook (*.xlsx)". One wrong file extension. In that moment, 420 lines of VBA code — built with AI over weeks — disappeared completely.
She wasn't a developer. She didn't know what a macro was. She certainly didn't know the difference between .xlsm and .xlsx. The only thing she knew was that she had 40 customer quote emails to send by end of day.
And the person who built the tool? He'd already left the company.
After working with Korean manufacturing sales teams on AI automation projects for over a year, I've seen this exact scenario play out more than once. The code vanishes. The new person is stranded. And nobody planned for this.
Why the Macro Existed in the First Place
To understand what was lost, you need to know what was built — and why.
Manager Cha worked on the design sales team at Eagon Industry (a Korean window and building materials manufacturer). His daily grind was painfully repetitive: whenever a client asked for window specs, he'd log into the company's internal system called EPICS, download product test report PDFs one by one, then manually copy and paste product names and store URLs into reply emails. Each request took 3 to 5 minutes. Ten requests a day meant an hour of his time just evaporating.
So he asked an AI to help him build something. The result was an Excel VBA macro file with a clean, simple structure:
- Enter product names in Column A of a spreadsheet
- Click [1. Gather Test Reports] → PDFs auto-copy to a designated folder
- Click [2. Auto-generate Email] → a formatted reply body appears, like: "Recommended: 1. EWS 75 TT PLUS Turn&Tilt / https://..."
The process that took 3–5 minutes now took 10 seconds. On its own, that's a nice efficiency win. But this story isn't about efficiency. It's about what happened next.
The Resignation — and One Fatal Ctrl+S
Manager Cha resigned. His work was handed off to another team member — let's call her Manager Son. She's not a developer. Her Excel skills go as far as formulas. VBA is a term she'd vaguely heard. But she could open the file fine, which seemed like enough.
The problem wasn't opening. It was saving.
Here's the thing most non-developers don't know: .xlsm files store macros. .xlsx files don't. Excel does show a warning — "This workbook contains VBA macro code that will be lost" — but in the middle of a busy workday, most people click past it without reading. Manager Son was no different.
When she reopened the file, the buttons were there. But pressing them did nothing. The shell remained; the code was gone.
What Manager Cha left behind:
- A PowerPoint document with a few macro screenshots showing the workflow
- No record of what prompts he'd used to generate the code with AI
- No
.basexport file, no Git backup, nothing
Fortra, in their 2024 analysis of Excel macro risks, put it plainly:
"Once the macro author leaves, the code becomes meaningless text to the next person. They either waste hours trying to decode it — or start from scratch."
Manager Son didn't even have meaningless text. She had nothing.
Two Hours of Recovery Work
The recovery request came to me through a mutual contact. The situation broke down to four lines:
| Item | Status |
| Original VBA source code | Gone |
| Developer | Departed (resigned) |
| Handover documentation | 1 PowerPoint with workflow screenshots |
| New owner | Non-developer |
There was one lucky break. Excel's .xlsm format is actually a ZIP archive internally. Unzip it, and you'll find XML files. The macro code lives in vbaProject.bin — which was gone — but the cell data survives in sharedStrings.xml. And that file still held 49 product records: product names, store URLs, and categories. That's data, not logic, so the format change hadn't touched it.
Recovery unfolded in four steps:
- Reverse-engineer the workflow from the PowerPoint screenshots
- Analyze filename patterns across 57 actual PDF files in the system
- Re-design the matching logic using the 49 surviving product records
- Rewrite approximately 420 lines of VBA with AI assistance
That took about an hour. I sent the file. Manager Son clicked a button. An error appeared immediately: "Cannot find source folder: https://oeagon-my.sharepoint.com/..."
The Hidden Trap: OneDrive File Paths
When an Excel file is stored in OneDrive or SharePoint, VBA's ThisWorkbook.Path returns an HTTPS URL instead of a local path. VBA's file-copy commands can't handle URLs. Manager Cha had probably worked off his local desktop. Manager Son used OneDrive. Same company, same job, one different PC setting — and the whole thing broke again.
Adding logic to auto-convert the URL to a local sync folder path took another hour. Total recovery time: 2 hours.
Manager Son's first test: 3 PDFs gathered successfully, email body generated correctly, Outlook draft created automatically. Done.
| Stage | Time per Request | Tool State | How It Felt |
| Before automation | 3–5 min | Manual copy-paste | Repetitive fatigue |
| After Cha built it | 10 sec | 2 VBA buttons | Satisfaction |
| After Son inherited it | Broken | Buttons with no response | Panic |
| After recovery | 10 sec | 3 buttons (+ Outlook) | Relief |
What This Incident Actually Costs
This story has a happy ending. But it's a happy ending built on three lucky assumptions: the master data survived inside the Excel file, there were at least some screenshots in a PowerPoint, and there was someone in the network who could help with recovery. Take away any one of those three, and this isn't a 2-hour fix. It's a weeks-long rebuild.
I work in HR development at a Korean manufacturing firm, and I've been running internal AI training programs for employees across multiple departments. What I keep seeing is a widening gap: people are building automation tools faster than ever — and documenting them almost never.
A 2025 survey by ITWorld and MegazoneCloud found that 55.7% of Korean companies are actively using generative AI in their workflows (among IT and AI decision-makers). Right now, across thousands of desks, AI-generated Excel macros, Python scripts, and Google Apps Scripts are running quietly in the background. How many of them exist only inside one person's head?
AI gave us the power to build. It didn't give us the habit of handing things over. Building is the easy part now. The hard part — the part that actually matters when someone leaves — is what you leave behind.
The 7-Point AI Automation Handover Checklist
These are the things the original developer needs to document while they're still on the team. The goal: a non-developer successor can handle basic maintenance on their own.
| # | Item | Why It Matters |
| 1 | Source code as plain text | Survives format accidents. Export as .bas, .py, or .gs and save separately. |
| 2 | Feature spec (one page) | Summarize inputs and outputs for each button or function. |
| 3 | The AI prompts you used | The prompts are the most accurate spec you have — and they make regeneration possible. |
| 4 | Test scenarios | Include the happy path plus common failure cases (like the OneDrive path issue above). |
| 5 | External dependencies | List everything the tool needs: folder structures, Outlook, internal systems, master data. |
| 6 | Maintenance guide | "To add a new product, go to Sheet X, Column Y, and enter Z." That level of detail. |
| 7 | Deployment guide | Step-by-step instructions for setting up on a new PC. |
For teams already using our previous guide on citizen developer risks as a baseline, this checklist fits naturally into your offboarding workflow. And if you're building AI automation for the first time, check out my earlier post on AI automation pitfalls for non-developers before your next project kicks off.
