What Should We Check After App Generation? Reading the 2026 Vibe-Coding Records

When building software by describing the desired behavior to AI—vibe coding—what should we check after a screen is generated? This article revisits nine separate experiments and prerequisite checks from this blog. It adds no new runs or connected production workflow. The year dates the records; it does not measure a market-wide shift or improvement over last year.

If a record survives a page refresh, has it really been saved? In a separately recorded browser demonstration within the storage experiment, three storage spaces inside the browser—sessionStorage, localStorage, and IndexedDB—returned the record after a hard reload. Memory-only storage and a condition that discarded writes (drop-write) were empty. Passing the reload check did not establish server-side storage. The demonstration is supported by a preserved observation record; this synthesis did not separately verify it against raw browser captures. Reloading a page, restarting the server program, and closing and reopening the browser are three different operations.

What these records cover

The experiments and prerequisite checks date from September 5–20, 2026. Their records were cross-checked in the repository on September 27. Verification and editing of this article mean comparison with the preserved records, not rerunning the experiments; the results remain limited to the environments and inputs used then.

The sections on reuse, delegation and acceptance, and interface checks and untested handoff are groupings for reading these records. They are not levels of proficiency or stages of a workflow tested from beginning to end. The records include actual executions, stops during prerequisite checks, and a local rehearsal with no service calls. Adding up their passes would not produce a meaningful success rate.

Observed: reuse

The storage experiment included a local server and SQLite database run, separate from the browser demonstration above. SQLite held the server-side records in that experiment. Requests carried synthetic identity headers—made-up user identifiers instead of a real login. The specified create, update, and delete operations, plus one restart of the server program, agreed with independent SQLite checks. These passes cover the checks that ran; the deployment check did not run.

Opening the app on another device, deploying it to an external server, and closing and reopening the browser were not tested. The interface in a fresh browser profile with no prior data, backups, and login and security for a real public service were also outside the scope. The browser reload result and the database evidence must stay separate because they checked records in different places after different operations.

The reusable-procedure experiment checked whether a copied task-instruction file loaded in a fresh conversation. It did. But successful loading did not establish more accurate answers. All 12 main answers passed the factual checks across ordinary requests, requests with the procedure included in the message, and requests explicitly invoking the tool's skill feature for calling a saved procedure. Two separate implicit-invocation diagnostics are not included in those 12 answers. All passed, so no factual-score advantage was observed; that does not establish equivalence between the approaches or show that the file had no benefit.

The comparison used two synthetic Korean-language cases, run once per condition and executed and scored by AI. It cannot establish long-term memory, a learning effect, or time savings.

My takeaway is to make “it works again” specific. Where was the data found, and after which kind of restart? Did the procedure load in a new conversation, and was any improvement in the answer measured separately?

Observed: delegation and acceptance

In the planted-bug experiment, the set of tests generated from the business rules alone passed only two of five executable checks on a known-correct version of the app. That made the set ineligible for defect scoring; it is not a score of “zero bugs found.”

The suite generated with access to both the rules and the app code passed all eight clean-baseline checks and detected three defects planted by the experimenter and hidden from the generating model. Those were actual detections. Each condition involved only one generation, however, so the comparison establishes neither a superior condition nor that code access caused the detections.

Reusing the code-aware set of tests after a feature addition exposed a different limit. The same five of eight checks failed on both the correctly updated app and the version containing a new defect. The checks required the result to have exactly the old structure, so they rejected a legitimately added note field too. Those failures did not establish that the suite could distinguish a regression—a defect introduced by a later change—from a correct update.

A separate check against the expected behavior did distinguish the note-lifecycle defect—a removed item's note remaining when it should disappear—but the generated suite cannot take credit for that result. Its initial detection of the three planted defects still stands.

The record on scheduled agents—AI set up to run tasks on a timetable—supplies a different kind of evidence. It was a local rehearsal that replayed predefined cases, with no real scheduling or AI model calls. A verification program rejected a draft report bound to the wrong data snapshot and set it aside (quarantined it). The rejection came from a verifier applying fixed rules. This was not an observation of AI recognizing incorrect input or of a live scheduling service working reliably.

In both records, producing a result and establishing grounds to accept it were separate operations. My reading is that a test set first needs checking against a known-correct app, and “Did the test fail?” needs a follow-up: “Did it distinguish a correct change from an incorrect one?” For a report, the corresponding questions are which input produced it and who accepted it against which criteria.

Observed: interface checks and untested handoff

The conversational-app experiment displayed an app within a chat interface in the official local reference host on the test computer. It responded to the tested Korean and English inputs, and the total changed from 90 to 100. Stored values also returned when a new view opened within the same running local process and session. These were successful interactions, but they did not establish storage that survives a server restart or transfers to another device.

An unsupported language code produced an actual failure. The server fell back to English with a warning, while the interface fell back to Korean without one. That mismatch belongs alongside the successful input and restoration checks. Three other checks had invalid procedures, and six were not tested. Neither category counts as an app failure. The results also do not establish behavior inside a commercial chat service or prove that the model actually received the content the app attempted to send to it.

The generative-design experiment used one run from a text specification and one from a wireframe drawn and annotated directly on a digital canvas. The wireframe was an experimental input made of shapes and text on a canvas. It did not test a drawing on paper or a novice's experience of making one. Both outputs met the predefined checks for three screens, two navigation paths, and three edits. Text ran first, and the outputs used different selection controls and some different checks for empty input. The pair cannot rank one input method above the other.

The edits also used different mechanisms. The first changed an element directly; the next two regenerated parts of the relevant screens. The final instruction required changing a button's destination while retaining its label. The result followed that instruction, leaving the Korean label 공간 목록으로—“To the space list”—at odds with where the button actually led. The mismatch followed the experiment's instruction; it was not a failure to carry out the requested edit. This does not establish whether the tool noticed the semantic conflict.

For me, the useful question here is how following an instruction relates to what a screen communicates. Even when an edit matches the request, the label and destination can be checked separately. Export was not performed, so transferable code and production readiness were not established. Interaction was observed in the reference host and in the design canvas, but no tested process connected those two cases through deployment or transfer to a phone.

Three records that stopped before execution

The following records did not observe products failing during use. Each stopped while checking a different prerequisite for starting its experiment.

Shut-down simulators listed in the phone inventory are not evidence of a physical-phone run. One route had unproven prerequisites; another was ineligible in that environment. This does not mean no route exists in any environment.

These stops support no verdict on the products' safety or availability, in either direction. The conversational app's language mismatch, by contrast, was a failure observed during execution. Keeping “unknown” separate from “failed” is part of explaining this synthesis accurately.

My judgment: questions to attach to the next request

These records covered reusable procedures, storage, checks on results, and interface behavior. Handoff or deployment connecting the cases was not tested. Reading them together is an editorial interpretation, not evidence of a market transformation or a complete, validated operating workflow.

The records suggest these questions for a subsequent task:

• After which operation, and in which storage location, was the result checked?
• Does the set of tests pass a known-correct version of the app?
• After a feature change, does the check distinguish a correct update from a faulty one?
• Which input and criteria does the person or program accepting the result compare?
• After an edit, does clicking the button lead where its label says?
• Were the intended environment and handoff tested?
• Were stops caused by unmet prerequisites kept separate from product failures?

These are editorial suggestions drawn from the records. Their effectiveness at preventing real-world problems was not measured.

The map pairs each retained observation with what was not tested. Links lead to the earlier published articles for further reading, not raw evidence or verification of current product capabilities. The observations this synthesis relies on, and their limits, are in this article's text and table, not in the links.

AI was used to assist with research and drafting. The author independently verified and edited the final article.