After a month with WorkBuddy, I cleaned up my file entry points first

I came across a post saying that after mid-2026, don't recommend No-Code platforms to beginners anymore; just have an agent write code from scratch and find a server to deploy. Sounds reasonable, but I'm a backend dev, and I don't need anyone to write code for me. What really eats my time every day are the unglamorous chores: a bunch of spreadsheets from different sources, each with its own format, ultimately needing to be merged into one presentable thing.

I also listened to the podcast episode about OpenCode—5K token compression rate, 95% cost savings, quite aggressive. That's for people who write code. The logic in office work is different: if code is wrong, the compiler yells at you; if a spreadsheet is wrong, no one yells, and by the time you find out it's already been sent to your boss.

I used WorkBuddy for about a month, and it handles the latter.

The place these tools most easily go wrong is that they want too much to plan for you. The version that runs stably for me is treating it as an executor, not an advisor.

Specifically how. Step one isn't in WorkBuddy; it's in the file system. Create a new folder, say wb-inbox-0927, and throw all the files to be processed this round into it—no more, no less. Standardize names into a format like date-department-type, e.g. 0925-marketing-reimbursement.xlsx. This step takes five minutes and saves half an hour later. The reason is simple: WorkBuddy reads context; whatever is in the directory is what it consumes. If you throw in a bunch of old files with messy names, it can only guess.

Step two: open WorkBuddy and create a task. Choose Ask mode—ask first, don't act. Enter "List all files in the current directory, group by type, and tell me the column names and row counts of each file." It will give you a list. This step is validating the data entry point; dirty data can be spotted here, e.g. some sheet has headers on row three, some sheet has merged cells. If something looks wrong, exit and fix the file; don't expect it to fix itself.

Once the list is fine, switch mode to Craft and write the execution instruction. Hard-code the output format in the instruction: which column names, dates unified as YYYY-MM-DD, amounts kept to two decimal places, empty values filled as NA, output filename summary-0927.xlsx. Don't write things like "organize it a bit"; it can't understand your aesthetics.

Permissions deserve a separate mention. When creating a task there's a data access scope, and the default may be fairly broad. My habit is to manually narrow it: check only that wb-inbox folder, don't check the Downloads directory, don't check the entire disk. Office files contain everything—salary sheets, contracts, customer lists. If the scope is too broad, when something goes wrong you can't say clearly whether it read them or not. This setting only needs to be done once; the template remembers it.

After the first run, don't rush to use it. Open the output sheet and spot-check five to ten rows, focusing on dates and amounts. The pitfall I hit was that the amount column mixed in "about" and "yuan"; it processed them as text, the whole column became strings, and sorting went haywire. Later I added a line in the instruction: "The amount column should keep only numbers, remove units and text," and it was fine. There's no universal solution for this kind of problem; you can only go through it yourself and then write the patch back into the instruction.

A handy practice is to save it as a template. After a task runs successfully there's an entry to save as template; name it monthly-summary-v1. Next time a similar task comes up, call it directly and only change the input directory and output filename. My current process is to run it once every Friday afternoon: first Ask to check the entry point, then Craft to execute. Twenty minutes total. Previously manual merging took about an afternoon.

One reminder: don't treat templates as universal. Last month I switched to data from a different department, and the header structure was completely different; the template's direct output was unusable. My approach is to create a new template, not overwrite the old one. Templates—one template corresponds to one structure; don't be greedy.

On collaboration, mine is relatively simple: templates and instructions are stored in a fixed directory on the shared drive; colleagues who need them copy one and change the path. Permissions are only granted at the execution layer; others aren't allowed to modify the template itself. If it gets broken, no one knows which version caused the problem.