One Month with WorkBuddy: Not a Game Dev Harness, but an SSR Entry Point for Planning

After using WorkBuddy for a month, it feels more like the SSR entry point for daily game design tasks

At 3 AM, I was still tweaking my design docs when I came across an intro to KayingCodex. It’s described as an Agent Harness deeply optimized for game development, linking project context, assets, runtime, and publishing into one pipeline. The Agent can drive development, checks, playtesting, and even push releases.

I didn’t worry about it replacing designers first; instead, I wondered if WorkBuddy, which I’ve been using for about a month, could build a similar workspace for my scattered daily tasks.

As a game designer, my biggest headache is that design docs, asset tables, Unity config files, ops emails, version meetings, and ad-hoc requests are all over the place. Whether the gameplay is "chuunibyou" or not comes second.

Skills are useful, but what determines whether WorkBuddy fits into my daily workflow is its ability to organize information into states that are checkable, traceable, and reversible. AI without state and boundaries is like a teammate who just learned how to cast skills—flashy in theory, but causing accidents in practice.

I placed WorkBuddy at the entry point of my daily design doc workflow

After using WorkBuddy for about a month, I positioned it as the daily entry point for design docs. Every day, I aggregate Unity export changes, new documentation, email feedback, and meeting conclusions into a checkable daily version report. I only connected Feishu Docs last week, started using Feishu Sheets recently, and have been running scheduled tasks for about a month. These tools are just entry points; the ultimate test is whether they can consistently produce checkable daily version reports.

The process isn't complex, but it's very real. What's complex are the fields and states. The same resource has different names depending on the source: asset_type in Unity exports, "category" in design docs, and sometimes just a string of filenames in ops sheets. If WorkBuddy is only responsible for understanding, it tends to over-interpret, filling empty fields with unfounded details (like VFX specs) and marking "pending confirmation" as "completed."

For design docs, these errors are more fatal than slow generation. So I care more about whether WorkBuddy can break tasks down into clear states: successful generation, missing fields, unreadable source files, or empty output. After using scheduled tasks for a month, my stance is clear: don't chase full automation. The scariest thing about WorkBuddy running scheduled tasks is silent failure. Permissions aren't granted, sheets aren't synced, tasks show no activity—it looks like it's running automatically, but produces nothing.

Letting it do one thing at a time works better: extract fields first, align enums next, and finally generate a checklist. The results are actually stable. It hasn't completely freed me up, but at least it handles the most tedious aggregation work, leaving me time to monitor anomalies.

The difference between WorkBuddy and KayingCodex lies in verification methods

KayingCodex feels like a dedicated Harness for game development. It puts conversations, projects, assets, local runs, TapTap Maker, and publishing flows into the same workspace. You define goals, playtest, and make decisions; it maps every conversation to project files, dev actions, and verifiable results.

You define goals, playtest, and make decisions; the Harness maps every conversation to project files, dev actions, and verifiable results.

This sentence hits WorkBuddy's weak spot.

WorkBuddy is a workplace AI agent workspace capable of handling docs, sheets, emails, PPTs, data analysis, and file organization. Its core is organizing office info into something checkable; it doesn't run games. KayingCodex cares if the game gets built; WorkBuddy cares if the design doc is written clearly, if tables are aligned, and if meeting conclusions become tasks.

If I had to judge, KayingCodex is more like the game dev Harness needed by programmers, TAs, and producers. WorkBuddy is more like the general office Harness needed by designers, ops, admin, and content teams. They target different workspaces.

What I envy about KayingCodex is that it makes verification part of the workspace. Conversations, project files, and executable next steps are always visible. This design is mature. Agent products fear losing context the most. Mid-chat, it forgets who the current project is for, where the files are, or if that field was already confirmed.

WorkBuddy has this issue too. It handles many office tasks, but they still feel like independent sessions. Over this past month, whenever input sources multiply, it starts relying on gut feeling. Connecting Feishu Docs last week, starting Feishu Sheets recently, plus emails and Unity exports—if these aren't bound into a single project context, WorkBuddy easily mixes today's requirements with yesterday's version.

I don't like the hype of "generate a Demo in one sentence." For designers, one-sentence generations aren't trustworthy. Generating pretty pages isn't hard; the trouble is whether every change is traceable, checkable, and acceptable to the team. A playable Demo that can't explain which field changed, why, and who confirmed it is more like video footage than a production asset—it lacks the check.

So the main difference between WorkBuddy and KayingCodex falls on verification methods. One leans toward game dev workflows, the other toward office info workflows. The former verifies gameplay; the latter verifies task status.

It needs to add project context and checkpoints

These days I'm testing Notion, and I've just started using Feishu Sheets. Honestly, both are still in the "can we use them?" phase, not deep usage yet. I've clearly felt that sheets and docs carry task states; display is secondary. Notion page structures, Feishu Sheet fields, and WorkBuddy automations—if any checkpoint is missing, everything turns into beautiful garbage.

WorkBuddy's strengths are obvious. It's versatile, connecting docs, sheets, emails, PPTs, and data analysis. It suits workflows without standard answers: storyboards today, ops feedback tomorrow, Unity config changes into version logs the day after. For many teams, this versatility is more daily than vertical game dev Harnesses.

But WorkBuddy's weaknesses are direct. It hasn't turned office tasks into a workspace with states, boundaries, and verification. Right now, it's more like a helpful assistant. Give it inputs, and it tries to deliver, but it doesn't inherently know the delivery standards. Those standards must be written by humans.

So my positioning for WorkBuddy is clear: it serves as a general office workspace, linking assets, docs, sheets, emails, and task states. For designers, it's more like the SSR entry point for daily tasks—it doesn't make your game, but it converges scattered requirements into a checkable, traceable, and reversible workspace.

I hope it adds clearer project context later. It doesn't need to become KayingCodex, nor does it need local runtime or game publishing management. Under a version package, it should bind Feishu Docs, Unity exports, email threads, Feishu Sheets, Notion pages, and checkpoint states. Each task should know which version, requirement, and change it serves. Output should ideally be clickable, reversible, and accountable objects—a single report isn't enough.