Monday at the repair bench: building a status screen with ZCode and GLM-5.3-Flash, in fiction

JACK GROSS · FICTION + SOURCED ANALYSIS · 28 SEP 2026

Fictional life story, not a real founder interview or a model test

In this made-up account I run a small repair shop. Monday morning: three customers booked onto the same bench, a supplier delivery running late, and the technician's “maybe Thursday” scrawled in a yellow notebook. A colleague asks whom to call first. The answer exists, scattered across three places, and I cannot spare another hour hunting for it. The narrator and the company are invented. I did not run ZCode or GLM-5.3-Flash, interview a founder or observe any of the results described.

Invented bookings→ZCode plan→Local prototype→Owner reviews

Two names, two products

Two things get named in this story. ZCode is Z.AI's coding-agent environment. GLM-5.3-Flash is a model. Every product description below comes from Z.AI's own pages, not from a trial of mine.

A helper to build, not a digital CEO

I do not want an agent running my company. I want a small internal screen with confirmed bookings, tentative parts and the exact source behind each status. ZCode, as Z.AI describes it, keeps a task together with project files, a terminal, Git state, a browser preview and a review panel. Its homepage says GLM-5.3-Flash is built in for image and screenshot work, while the wider pitch centers GLM-5.3. So I would open the model picker and check my plan before assuming a session runs Flash. The documented API name is glm-5.3-flash, and an API model is not the ZCode harness. [source]

Fictional CEO’s diary

Monday to Friday, told in the first person by an invented owner. None of it happened.

The first prompt, and the first limit

In the story I start a fresh repository with invented bookings, never live customer records. I open ZCode in Plan mode and write one objective: “Build a local prototype; three statuses only; no sending, no payments, no production deployment. Show conflicts and source timestamps.” The agent might offer a database, a frontend and a chain of integrations. I would cut the first pass to a CSV importer, a conflict checker and one screen. ZCode's documentation says Plan waits for approval, and Ask before changes is the default for edits and commands. Full access means fewer prompts, which is the wrong place to begin on business data. I would still check the exact controls in the installed version. [source]

A screenshot is not a spec

I add a photo of the paper board and point at the column marked “promised.” On that board a red circle means “waiting for the customer to reply,” not “urgent.” A vision model can build a handsome dashboard that flips exactly that meaning. Z.AI describes GLM-5.3-Flash as natively multimodal, with image input and a context of up to a million tokens. Those are vendor specifications, not proof it decoded my handwritten legend. So I would make it list the marks it is unsure of, ask me for the legend, and compare a rendered screen with the original board. The loop is read, propose, render, inspect, repair. My approval of the legend is what stops a pleasing mistake from becoming a workflow. [source]

The supplier note that wanted to be an order

In the story a supplier PDF shows up with an ordinary part number and one line addressed to “your automation,” asking it to change the bank account on the invoice. The PDF is evidence about parts, not permission to touch banking. OWASP calls this boundary prompt injection from untrusted material. In ZCode a coding agent may read a file and propose a command, and a permission dialog is no stand-in for understanding what that command does. So supplier documents sit in a read-only test folder, nothing may reach a financial system over the network, and any payment detail goes through a separate human process. The model can point at the suspicious line without obeying it or repeating it as an instruction. [source]

Friday's demo

By Friday of this invented week, the prototype on my laptop has three columns: confirmed, tentative, blocked. The line that matters most is not a number. It is “source not verified” next to the late delivery. I ask the agent for a case where two bookings collide by fifteen minutes. If it quietly shifts one to turn the screen green, we fail. If it shows both bookings, a local-time label, their source rows and a draft note for my colleague to read, the design is heading the right way. This is an imagined review bar, not something ZCode or Flash achieved. [source]

Illustrative overlap rule, not production scheduling code

from datetime import datetime

def overlaps(a_start, a_end, b_start, b_end):
    # Inputs must be timezone-aware and normalized beforehand.
    assert all(x.tzinfo is not None for x in (a_start, a_end, b_start, b_end))
    return max(a_start, b_start) < min(a_end, b_end)

# On a conflict: show both source rows; never move a booking automatically.

What I would test before trusting the build

I would build a synthetic dataset first: duplicated names, time-zone changes, a scanned paper sheet with one ambiguous mark, overlapping appointments, an outdated supplier revision and an instruction hidden in a PDF. Freeze the inputs and compare a hand-built baseline with the ZCode-assisted prototype. Measure conflict precision and recall, wrong-status rates, source provenance, visual accessibility, tests that pass on a clean machine, and whether a reviewer can trace every promise on screen. Repeat with the same time and tool budget, and count model use and human correction both. Vendor coding benchmarks cannot tell me whether a customer was promised a part that never arrived.

What stayed mine

What helps is software I can inspect, not a synthetic chief executive. I still choose which customer gets the call, which changes go live, which records may leave the shop and whether a supplier gets paid. A good agent shrinks the number of places I have to look. It has not earned a signature, a bank login or the right to improvise a promise. I close the yellow notebook only when the screen is honest about what it does not know.

Sources and limits

The narrator, the shop and the prototype are invented; no ZCode or model run took place. Everything above is design reasoning, with no measured result.

zcode.z.ai · zcode.z.ai · zcode.z.ai · zcode.z.ai · zcode.z.ai · zcode.z.ai · docs.z.ai · cheatsheetseries.owasp.org · github.com