Your agent exports a 3D model, edits a shader, and runs a production build. Every command exits successfully, with not a single error. Yet the screen is empty. The agent concludes "no errors, so the code is right" and goes digging in the wrong place. This post is about the checks that prevent that mistake.
Why can a step produce nothing without raising an error?
A processing step can fail by returning an empty result instead of throwing, so every step needs a check that measures whether its output actually exists — as a count, a pixel ratio, or a marker value — and stops as a failure when it reads zero.
There are three common reasons a tool hands back an empty result as if it were normal:
- The default is conditional. If an option says "include this only when some condition holds," a pipeline that doesn't meet the condition silently drops it
- A layer swallows the error. A library catches the error and emits a single console line, or logs a warning and keeps going
- Overflow is discarded quietly. The browser or runtime reclaims whatever exceeds a limit without raising an error
What does it look like in practice?
In one 3D web project (2026-09), five different tools failed in the same shape:
- Export: a 3D tool's glTF exporter defaults to "include vertex colors only when a material references them." In a pipeline that doesn't use materials, the file came out without vertex colors and without an error (the option is in the exporter manual)
- Compile: passing a dynamic value into one shader function's arguments broke shader compilation on WebGPU, but the library caught it in an error scope and swallowed it, so the screen simply went blank. The same code worked on WebGL2
- Automatic processing: automatic bone weighting on an AI-generated mesh finished with one warning and zero weights. Duplicate vertices were the cause; merging them cut the vertex count to a third
- Resource limits: creating a WebGL canvas for every small preview pushed past the browser's context limit (roughly 16), and the browser silently dropped the oldest one — the main scene (context loss in the WebGL specification)
- Production build: a feature that borrowed a value from the code path that fills a development-only dashboard almost never turned on in production, because there that value was always zero
It goes the other way too. Passing an "empty range" to upload only changed data made the library read it as "no range = everything," so it uploaded the whole buffer every time. No error, nothing wrong on screen — just megabytes of extra transfer. Something that should be empty coming out full belongs to the same family: you only see it when you measure.
Which numbers should you measure?
"The output exists" is measured with a different number at each step. The same idea carries over to product-image conversion in an online store, a blog's static build, or an internal data export.
- Files and data: the count of fields, channels, or rows that must be there. Does the exported 3D file have a vertex-color attribute? Does the converted CSV have more than zero rows?
- Automatic processing: the count of results. Are weighted vertices, generated thumbnails, or classified items greater than zero?
- Screen: drawn pixels. Does the share of non-background pixels on the canvas pass a threshold?
- Production conditions: does the feature actually fire once? Check it in a test run with production settings, not development mode
- Volume: are uploaded bytes or sent requests within the expected range? Catch "too much," not just zero
What does planting a marker value add?
Checking only presence tells you something went missing, but not that it was swapped or transformed. So plant one known value in the input and check for it in the output. Put a constant 0.5 in one vertex-color channel, and simply reading that channel in the loader catches a missing channel, swapped channels, and color-space conversion all at once. For a data export, one known test row at the end does the same job; for an email template, one known placeholder.
Instructions to give your agent
Even when a tool reports success, do not move to the next step until you have confirmed with a number that the output exists.
- For each step, pick one number that measures "the output exists" (field/row/vertex count, drawn-pixel ratio, number of times fired, bytes sent).
- If that number is zero or outside the expected range, stop and report it as a failure. Read warning output as well.
- Where possible, plant a known marker value in the input and confirm it arrives unchanged in the output.
- When the screen is blank, before changing code, find the first step whose number drops to zero.
Checklist
- Every export or conversion step checks that required fields are present
- Every automatic processing step prints its result count and stops on zero
- At least one test measures render output as a pixel ratio
- Features that depend on a development-only path are tested under production settings
- "Too much," like transfer volume, is measured against an expected range
- A marker value planted in the input is traced through to the output