Hands-on report: GPT-6 ran two rounds of fixes on a live knowledge-network blog

A mature project as the test case

One of the first detailed hands-on accounts of GPT-6 being used for real development work has appeared on dev.to. The author, posting as perrinyong, describes getting access to the model and putting it to work on See the Forest (见林), a personal knowledge blog that had already launched and been through several rounds of design and iteration.

The blog is unusual: its main navigation is an interactive "star map" of the author's notes, with 558 public nodes and 846 relationships at the time of the test, and it is built to be readable by software agents as well as humans. The stated question was not whether the model could build something from scratch, but whether it could find genuine improvements in a mature project without flattening the qualities that made the project distinctive.

The author is open about a second motive — borrowing the attention around GPT-6 to introduce the project — which is worth knowing when weighing the account. It is also a single, self-reported story with no independent verification of the model's access or behavior.

Round one: denser search, readable mobile

According to the post, the first round deliberately left the star map's visual style alone and concentrated on reading and search. On the search page, GPT-6 gave result titles a uniform font size, shrank the oversized heading area, and dropped snippets that exactly repeated their titles. Ranking was left untouched and no content was rewritten. The practical effect was that a second row of results fit on the first screen in a 1440 × 900 window.

On mobile, the table of contents had been desktop-only, forcing readers to scroll back and forth to find sections. GPT-6 added an expandable, collapsed-by-default table of contents that works even with JavaScript disabled, and fixed a bug where a note beginning with a level-two heading had its first section omitted from the contents. It also added a retry button for failed searches, topic links on empty result pages, and fixed a fade-in delay that still ran for users with reduced motion enabled.

Round two: sharper stars, one rejected experiment

The second round targeted the star map's visuals. One experiment — a cleaner image that made topic nodes harder to recognize — was discarded rather than kept. The changes that survived sharpened the edges of the stars and the fine connecting lines, and when a node is selected, main connection paths now render more strongly than secondary ones, making the hierarchy of relationships easier to read. Colors stayed the same and no nodes were rearranged.

How it handled failing checks

The most instructive part of the report is how the model dealt with failure. Round-one browser checks surfaced two API errors and a drag-settling failure. The API errors turned out to be a test bug — comparing the production site's address against a local preview address — and were fixed in the tests rather than the product. For the settling failure, the post says the model re-ran the same operations on the old version, reproduced the failures there, and ruled out loading delays from optional ad requests, separating pre-existing product issues from anything its own changes introduced.

Round two's verification went further: ten sets of state comparisons across screen sizes, pixel densities and light and dark themes, with node counts, relationship counts, camera positions and label positions unchanged; interaction checks covering 180 selections, 36 drags and six navigation round trips; 180 Atlas unit tests and 108 blog unit tests passing, plus browser checks over 25 page views. Two Atlas dynamics checks still failed, involving motion-trajectory comparisons and the visibility of drag propagation. Per the post, the model did not loosen the acceptance criteria and left both issues documented in the report, reasoning that the same failure exists in the old version, so the new changes cannot simply be blamed.

Why it matters

Benchmark scores say little about how a model behaves inside a real, messy codebase. What stands out in this account, taken at face value, is judgment: preserving an existing visual identity, rejecting one of its own experiments, diagnosing whether failures predate its changes, and refusing to weaken tests to make them pass. If the report holds up, it suggests where AI-assisted development is heading — less about generating code from a blank page, more about careful maintenance of projects that already work. It is also a useful reminder to read early-access reports with the author's incentives in mind.