I recently got access to GPT-6 and put it to work on two rounds of improvements to my already-live See the Forest blog.
The blog had been through several rounds of design, development, and iteration. It had its own product direction and visual style. I wanted to see: What could it still find worth improving in a fairly mature project, and could it do so while preserving what made that project distinctive?
(The homepage before the improvements, with 558 public nodes and 846 relationships at the time. The star map itself was already an existing feature.)
After two rounds, more search results fit on the first screen, mobile articles had an expandable table of contents, and the stars and connections looked sharper. But not every experiment was worth keeping, and not every check passed. Here’s what changed, and what happened along the way.
Of course, I also have a slightly self-interested reason for writing this: to ride a little of the interest in GPT-6 and introduce See the Forest, or 见林, the project I’ve been building. Someone has to get the word out about my own project. It might as well be me.
Why I Built See the Forest
I covered the origins of See the Forest in my previous launch article. The short version is this: Knowledge is fundamentally a network, with its parts connected to one another, much like neurons in the brain.
Ideas can corroborate one another, but they can also qualify or contradict one another. Knowledge from different fields may share patterns at some level. But surface similarities don’t necessarily mean they are fundamentally the same. The network formed by these connections is itself part of our knowledge. Connecting what we know into a coherent understanding helps us put that knowledge to better use.
That’s why I want to connect the notes I’ve accumulated and keep maintaining them with the help of an agent, letting knowledge “ferment” through these exchanges and produce new “sparks.” Which insights are worth keeping is still for me to decide.
As this knowledge network began to take shape, another thought occurred to me: This network should be something we can see. Being able to see the overall structure and relationships first, then step into a particular piece of content, would be really cool. That’s how this blog came about.
This network is a field of stars made of knowledge. Each node is a topic or an article. The stars connect to one another, and those connections appear stronger or weaker according to the strength of the relationships. You can drag them with your mouse, or click a node to open its topic or article.
The knowledge network isn’t decoration. It’s the main way into the blog. And humans are no longer the internet’s only readers: the blog also allows agents to read the same content and the same knowledge network.
The name See the Forest comes from the idea of seeing both the trees and the forest.
Round One: Start with Reading and Search
In the first round, it kept the star map’s visual style and focused its changes on reading and search.
Take the search page first. The original “Search” heading was large, with plenty of empty space around it, and higher-ranked results used larger text too. Some snippets simply repeated their titles. The page looked imposing, but when you actually wanted to find something, that meant fewer results on the first screen and less room to compare them.
(Before: searching for “软件,” meaning “software.”)
It gave the result titles a consistent font size, reduced the space occupied by the heading area, and omitted snippets that exactly repeated their titles. The search ranking stayed the same, and the original content wasn’t rewritten.
(The same search for “软件,” in the same 1440 × 900 window. A second row of results is now visible on the first screen.)
Next, articles on a phone. If you were halfway through a note and wanted to find a particular section, you had to scroll back and forth: the table of contents was visible on desktop but completely hidden on mobile. It also found that when a note began directly with a level-two heading, its first section was omitted from the table of contents.
(The same article in the same 390 × 900 window. Before on the left, after on the right. The right image shows the new table of contents expanded; it is collapsed by default.)
There is now an expandable table of contents on mobile, with links that jump to each section. The missing first section was fixed at the same time. The table of contents works even with JavaScript disabled.
It also added a retry button when search fails, links to topics when there are no results, and fixed a fade-in delay that was still present with reduced motion enabled.
These aren’t particularly conspicuous changes, but they’re useful. The star map may draw people in, but once they open an article, reading it should be comfortable too.
Round Two: Further Visual Refinements to the Star Map
After the first round, I asked it to make some further refinements to the star map’s visuals.
One experiment made the image cleaner but also made the topic nodes harder to recognize, so it wasn’t kept. The changes we kept focused on sharper stars and fine lines, and a clearer visual hierarchy of relationships when a node was selected.
First, the default view.
(The same network, window, and display conditions. Before above, after below. Open the full-size images to compare the edges of the stars and the fine lines.)
The smaller stars and some of the fine lines used to look a little blurry. After the changes, the edges are sharper and the fine lines are easier to make out. The colors are still the same, and the nodes haven’t been rearranged, but the image does look more refined.
Now look at what happens when a node is selected.
(The same node, “游戏图形与运行时”—“Game Graphics and Runtime”—selected from the same viewpoint. Before above, after below.)
The gold connections used to look fairly similar in thickness. Now the main paths stand out more, while the others are lighter, making the hierarchy of relationships easier to see. The champagne gold, selection ring, and content panel on the right are all still there. These relationships already existed; this round simply made them clearer visually.
Beyond the Screenshots: How It Handled Problems
The pages had been updated, but had the changes affected the existing interactions? That called for checks beyond the screenshots.
The first round’s full browser checks turned up two API errors and a failure in the check for settling after a drag. The API errors came from tests incorrectly comparing the production site’s address against the local preview address. Correcting the tests cleared those errors, but the settling issue remained.
Rather than immediately blaming the changes, it repeated the same operations on the old version. Across the two rounds of investigation, the corresponding failures could also be reproduced there. One comparison also ruled out loading delays caused by optional ad requests. This helped distinguish problems in the tests, external interference, and existing product issues, rather than treating every error as a reason to change the code.
Round two’s verification went beyond a few clicks: 10 sets of state comparisons covered different screen sizes, pixel densities, and light and dark themes, with node counts, relationship counts, camera positions, and label positions unchanged. Repeated-interaction checks passed 180 selections, 36 drags, and 6 navigation round trips. All 180 Atlas unit tests and 108 blog unit tests passed, along with the blog’s browser checks covering 25 page views.
Still, two Atlas dynamics checks failed, involving motion-trajectory comparisons and the visibility of drag propagation. It didn’t loosen the criteria; it left those issues in the report. Finding the same problem in the old version means we can’t simply blame the new changes. It doesn’t mean the problem has been solved. That is more trustworthy than “it should be fine.”
These were the results at the end of the two rounds on September 5, 2026. Round two had been committed locally and a signed preview was ready, but it had not yet been pushed or deployed. The after screenshots come from the local version. Test counts aren’t user-experience scores, nor do they show that everything is faster on every device.
A Few Closing Thoughts
Looking back, these two rounds didn’t turn the blog into something else, but they did improve specific parts of the experience. For a project that had already been through many iterations, I think that’s worthwhile: it could continue within the existing product direction and find problems I hadn’t specifically pointed out. As for how well the changes worked, the before-and-after comparisons are here for you to judge for yourself.
This experience doesn’t answer “How much better is GPT-6 than other models?” I didn’t compare models under the same conditions, and it had existing project materials and Codex tools to work with. The result can’t be attributed entirely to the model itself. Deciding which changes to keep is still my responsibility.
That brings me back to why I built See the Forest. By making work more efficient, LLM agents make things feasible that used to be difficult to sustain over time. Maintaining notes, organizing their relationships, and presenting the knowledge network publicly used to involve a great deal of work. Now, with the help of an agent, I have a chance to bring these ideas to life, step by step.
As for what kind of knowledge network I want to build, and which parts of my understanding I want to share, those choices are still my own.
If you’d like to explore See the Forest, visit my blog at pystone.net. Pick a topic you recognize, drag it around, and click through. I’d also be happy to hear what you think, or what doesn’t work so well for you.
See the trees. See the forest.
石心 Yong