How my homepage grew beyond the brief

I use coding agents for much of the implementation work on this site. I describe what a page needs to do, review the result, and decide what to change. That approach lets me move quickly, but it also means my review has to account for the whole page, not just the latest diff.

The initial homepage brief was modest. I wanted a hero section that suggested working AI systems without falling back on a stock illustration. A headline and a short index of projects were enough to make a first version.

The hero picked up one addition at a time. A panel acquired a console-style label. Then came a scanning line, a pulsing dot, orbiting nodes, a monogram, and a glow behind the panel. Each change made some sense when I looked only at the feature in front of me. The panel became the reason for the next piece of polish.

I had approved those changes, so the drift was mine to correct. Looking at the whole homepage after several sessions, I could see that the visual language had become familiar in the wrong way. The motion and console cues were drawing attention to themselves while the actual projects had to compete for space.

I could have kept the panel and simplified it. Slowing the scan and removing a few nodes would have preserved the work already done. I was reluctant to throw that work away, which was a poor reason to keep a component that no longer helped the page.

I asked two models to critique the design from different perspectives and compared their objections with what I saw in the rendered page. Their review helped me make the cut, but I had to decide what the page was for. I removed the console panel, the floating chat launcher, several decorative strips, and other effects that had gathered around the original idea.

That decision discarded several sessions of work, including time I had spent reviewing and refining it. The simpler page also felt quieter. I had become used to the movement, and for a while its absence made the page feel unfinished to me.

I added a build check for the old CSS keyframes and several of the removed selectors. It is useful for catching a familiar pattern if it returns, but the check has a narrow scope. It says nothing about whether a new visual element helps a visitor understand the work. I still have to judge that by looking at the page.

The site has changed again since I first wrote this note. The console panel is gone, while the current homepage uses particle motion and a particle-based assistant. My earlier claim that the site had no continuous animation was too broad for the design I eventually chose. The build check still rejects CSS keyframes from that older treatment; the particle motion runs in JavaScript.

For future changes, I want the brief to say what a visual element should help a visitor understand. I then need to review the rendered page after several changes, when individually reasonable additions have had time to accumulate. The code check can keep the old console treatment from slipping back in. Keeping the page focused, especially when I decide to add motion, remains my responsibility.

The agent explainer describes the harness and model loop behind this kind of work. In this case the important boundary was my own review: the agent could propose and implement additions, while I had to decide whether the page they created still served the original brief.