DEV Community: Leo Liu

3,026 Queries to 16: What We Checked Before Calling a Dashboard Faster

Leo Liu — Tue, 15 Sep 2026 05:04:37 +0000

Our internal operations dashboard had become slow. Before buying more server capacity, we looked at what one list request was doing.

The September 11 engineering report from our project recorded 3,026 database queries in an isolated test using a copy of real data. Related records were being fetched one row at a time, and the initial response carried roughly 1.5 MB before anyone opened a detail view.

Change what the page asks for

The changes were straightforward to describe, but not trivial to validate:

Return paginated summaries, not complete records, in the list.
Batch related-record lookups instead of repeating them for each row.
Fetch details when a user opens them.
Keep ordering deterministic and measure both response size and latency.

Under the reported test conditions, the main list query count fell to 16, plus two read-only transaction-control statements. Median request time fell from 343 ms to 13 ms; at ten concurrent requests, p95 fell from 3,303 ms to 230 ms. The response fell to roughly 60 KB before compression, or 10.6 KB compressed.

These are figures from our isolated comparison, not a promise of the same improvement on every dataset or a measurement of long-term production reliability.

A faster response can still be the wrong response

For our team, speed was only half the acceptance question. The other half was whether the same people could still see and act on the same records.

The comparison needed to cover permissions, filters, recent-activity rules, pagination, cross-page selection, bulk assignment, and login behavior. A changed sort order or a missing permission check would make a fast dashboard worse, not better.

That is the part I would bring to another team: write down the behavior that must remain unchanged before asking an AI coding agent to optimize the implementation. Then compare the old and new versions against that checklist, alongside the timing results.

A benchmark supports a performance claim within its test conditions. Production operation needs its own checks. Keeping those two conclusions separate makes the result much more useful than a single impressive speedup number.

From Prompt to WeChat Dev Build in One Day: Tests and Evidence Boundaries

Leo Liu — Mon, 07 Sep 2026 10:16:57 +0000

I recently used AI as the primary development interface for a small WeChat mini game called Weiguang Xinyu.

The one-day result was a working ten-level Canvas2D puzzle, an original background track, a passing local test suite, and a successfully uploaded development build. The public release followed later.

This post focuses on the technical workflow and the evidence boundary between those two stages.

Product scope

The mechanic is compact: rotate path segments to connect a light source to a destination.

The build includes:

ten puzzle levels
level selection and unlocking
undo and restart
one free hint per level
local progress persistence
an original looping background track
a music toggle with stored preference

The first version did not depend on a cloud environment, external server, personal-data API, advertising, or payments. That kept the test surface controlled enough for a one-day experiment.

The working loop

I used voice as the primary interface and treated AI as a coordinated implementation system rather than a one-shot code generator.

requirement
  -> implementation
  -> local test
  -> visual inspection
  -> packaging check
  -> development upload
  -> remote source readback

Each loop ended with an observable artifact. A plausible answer in a chat window did not count as completion.

Architecture

The game uses Canvas2D for rendering and separates the core puzzle state from platform-specific behavior.

game state + level data
        |
        +-- input and rotation logic
        +-- path connectivity checks
        +-- progress persistence
        +-- renderer
        +-- audio controller
                |
                +-- browser adapter
                +-- WeChat adapter

This separation mattered because local browser previews and the WeChat runtime do not expose identical audio APIs or lifecycle behavior.

The music starts only after the first user interaction, loops when enabled, pauses in the background or during interruptions, and stores the user's preference. Audio failure does not block gameplay.

Testing and readback

The final local suite reported 13/13 tests passing. The checks covered the original puzzle behavior together with the music controller and platform adapters.

The upload alone was not treated as proof that the intended source had reached the platform. After the official development-build upload succeeded, the remote source map was read back. Thirteen remote source files matched the local source files.

That is useful evidence, but it has limits. It does not replace real-device testing, prove every binary asset is byte-identical, or mean the build is already public at that moment.

The four-state model

State	Evidence
Local prototype	The project runs locally and the core interaction works
Tested build	Defined tests pass and the relevant UI is inspected
Uploaded development build	The platform accepts the build and the result is read back where possible
Public release	Review is approved and ordinary users can access the production version

The process screenshot captured the tested-and-uploaded stage. The project later reached public release.

What AI was good at

AI was especially effective at keeping related changes synchronized:

updating implementation and tests together
aligning the product name across the UI, project metadata, and review copy
generating repeatable checks instead of relying only on manual inspection
documenting the current state after each meaningful transition

The speed came from many small verified loops, not from a single giant prompt.

What still required human judgment

The hardest decisions were not syntax decisions. They were questions such as:

Is the mechanic understandable without explanation?
Is a level difficult for the right reason?
Does the visual and audio mood support the product idea?
What evidence is strong enough for the next claim?
Which platform step changes the truthful status of the project?

AI reduced implementation cost. It did not remove product judgment or release responsibility.

Takeaway

Yes, AI can help one person build a small game in a day.

The more useful claim is narrower: AI can compress the path from idea to a tested, uploaded development build when the scope is controlled and every stage ends with evidence. The release can then follow through its own verified steps.

That is already a major change. Just do not call the development upload a launch before the later launch is actually complete.

A Versioned Evidence Schema for Agent Skills: Provenance, Permissions, Task Fit, and Test Status

Leo Liu — Sat, 05 Sep 2026 04:18:27 +0000

AI-assistance disclosure: I used AI to help draft and edit this article. I checked the technical claims and remain responsible for the final text. I also maintain the open-source repository described here, so this is not an independent review.

Agent capabilities are becoming easier to package and discover. But cataloging a Skill, MCP server, or plugin is not the same as proving that it works for a specific task.

I have been exploring a small open-source project called Agent Catalog Seed. Its purpose is not to create another popularity leaderboard. The experiment is to make missing evidence explicit and versioned.

The state machine matters

For an agent capability, these states are different:

cataloged
  -> statically checked
  -> installation observed
  -> runtime observed
  -> task acceptance recorded

Each arrow requires new evidence. A parser accepting SKILL.md does not prove that a host can install it. A tool call returning 200 OK does not prove that the business task is correct. A successful run on one host does not prove compatibility on another.

The catalog should therefore store evidence types rather than flattening them into one score.

A minimal versioned record

The seed currently uses a strict JSON Schema. The example below is simplified, but it shows the separation of concerns:

{
  "schema_version": "0.1.0",
  "id": "urn:agent-catalog-seed:entry:release-note-checklist-demo",
  "kind": "skill",
  "installable": false,
  "provenance": {
    "origin": "ai-assisted-original",
    "synthetic": true,
    "description": "Synthetic catalog example; not a third-party package"
  },
  "requested_permissions": {
    "filesystem_read": [],
    "filesystem_write": [],
    "network": false,
    "network_destinations": [],
    "data_destinations": []
  },
  "compatibility": [{
    "host": "unverified-host",
    "status": "unknown",
    "evidence": []
  }],
  "evaluation": {
    "status": "not_evaluated",
    "independent_review": false,
    "evidence": []
  },
  "conflicts": {
    "maintainer_is_author": true,
    "disclosure": "Maintainer-authored synthetic example"
  }
}

The current seed deliberately makes entries non-installable and unevaluated. It is safer to publish an honest unknown than to convert a roadmap or author claim into a result.

1. Provenance before recommendation

A useful record should identify:

source URL and maintainer;
release, revision, or content digest;
artifacts actually inspected or tested;
license and redistribution basis;
relationship between evaluator and author.

The version identity is essential. When a dependency changes, we need to know which evidence is still applicable.

2. Requested permissions are not enforced permissions

The catalog can record filesystem, network, command execution, credential, and data-destination requirements. But it should not pretend that metadata enforces a sandbox.

The host, user, identity provider, and remote service still control authorization. Static documentation can be wrong or incomplete. Runtime observation may reveal behavior, but it remains scoped to the tested environment.

This is why “security” should not be one Boolean field. At minimum, separate provenance and integrity, requested and granted permissions, static findings, runtime observations, and unresolved risks.

3. Task evidence needs an acceptance contract

Before testing, define the scenario and acceptance criteria. Then record:

host, model, adapter, dependency, and configuration versions;
input boundary and whether the data is synthetic or authorized;
planned attempts, retries, human interventions, and timeouts;
every pass, failure, interruption, and indeterminate result;
time and cost basis;
who accepted the output.

Do not remove a failed run because a retry succeeded. Do not change the acceptance criteria after seeing the output without recording the change.

4. Evidence should expire

A test result needs an invalidation policy. A new release, host update, model snapshot, permission change, or task revision may move a record from observed back to retest_required.

This is where version monitoring becomes more than a notification feed. The useful question is not only “what changed?” but “which prior task evidence may no longer apply?”

What the repository proves today

The public seed contains a versioned Schema, a synthetic example, a validator, boundary tests, evaluation and governance templates, and a real public narrated-video-review Skill.

The Skill passed static format validation. It has not been independently tested in a real video edit or verified across multiple hosts. There is no live marketplace, no automatic evaluation service, no independent certification, no real user rating, and no paying customer.

The repository is useful today as an inspectable proposal, not as a trust badge.

A reproducible feedback request

If your team has a recurring failure caused by a Skill, MCP server, plugin, or dependency update, open a GitHub Issue with a non-sensitive test case:

task and acceptance condition;
capability and version;
host or integration context;
observed failure or maintenance burden.

Do not post secrets, customer data, production credentials, or private files. Synthetic and redacted cases are welcome.

The goal is to learn whether version monitoring, customer-task regression evidence, and team allowlists solve a repeated engineering problem—not to manufacture a large catalog before that problem is validated.

Author disclosure: Leo Liu initiated and maintains Agent Catalog Seed. This article is an AI-assisted, human-reviewed technical note. It is not sponsored and does not represent an independent security assessment.

The AI Products We Build Today Are Not the Endgame

Leo Liu — Fri, 04 Sep 2026 06:06:29 +0000