An IDE shell drew the line between mature basics and shaky compositions
/editorCaptured at a 375px viewport. Long pages scroll inside the frame.
The screenshots stay in Japanese. Every round is a real screen for a real Japanese industry, so an English re-render would no longer be the screen the agent actually produced.
Write-up
An IDE shell drew the line between mature basics and shaky compositions
Build log series: I hand a real screen to an AI that has never seen Gunjo (
@gunjo/ui) and let it build. This round covered an IDE-style editor screen.
As before, the agent received only the shipped package and docs, with no source access. The /editor assignment called for a menu bar and toolbar, breadcrumbs, a file tree on the left, tabs and an editor in the center, a panel on the right, and a status bar along the bottom.
Round #15 showed that the base components had stopped producing new classes of defects and that the remaining problems had moved up a layer. This time I set out to make that boundary clearer.
Result: 3/5
tsc and build passed, the page was statically generated at build time, the console stayed clear, and the server and browser output matched with no hydration errors. The cold agent reached the same conclusion as the previous round:
The base components are all here.
Button,Badge,Kbd,Breadcrumb,Menubar,Tabs,CodeBlock, andTooltipworked immediately, with sound accessibility and public types. The instability has moved one layer up, into compositions and higher-level components.
A single screen made the boundary around what was mature unmistakable.
Rough edges: three above the boundary
1. The file tree did not work from the keyboard, the fourth accessibility failure. FileTree and TreeView had the correct role="tree" and treeitem semantics, but neither implemented onKeyDown or roving tabindex. The standard tree controls, the four arrow keys, did nothing. I logged issue #87, following issues #57, #71, and #83.
2. Another name promised more than the component delivered, the fourth case. EditorTemplate had no docs (the link returned 404), no status-bar slot, a fixed width, and no mobile alternative when both side panels disappeared. On a phone, there was no way to reach the file tree. StatusBar also had defaults that did not suit an application shell: it was fixed to the viewport and capped at 640px. I logged issue #90.
3. Package hygiene and generated classes contradicted themselves. The files field in package.json referred to files that did not exist, so the design/ metadata was absent from the package after a migration left stale paths behind. I logged issue #88. Breadcrumb, Menubar, and StatusBar also carried the conflicting classes flex-col flex-row, caused by the design-source conversion. I logged issue #89.
What I fixed this round
- Issue #87, tree accessibility: I implemented the standard tree keyboard controls (the four arrow keys, Home, End, and roving focus).
FileTreedelegates toTreeView, so the fix covered both. It shipped in PR #91, and I verified arrow-key navigation plus expand and collapse behavior in a real browser. - Issue #88, packaging: I updated
filesto point to paths that exist, so the package now includes thedesign/metadata. The same PR carried the fix. - Issue #90, overpromising names: I grouped
EditorTemplateandStatusBarwith issues #74, #80, and #85 for the beta gate. - Issue #89, conflicting classes: I removed the cause in the generator. The fix shipped in PR #92. Pencil (the design tool this system is drawn in) omits the direction when a row is horizontal by default, and the converter had misread that omission and generated
flex-col. The.pensource was already correct, so I changed the converter and left the design file alone.
What I took away: maturity shows up as a boundary between layers
Base components (Button, Badge, Tabs, CodeBlock): mature
Compositions and higher-level components (EditorTemplate, FileTree, StatusBar, NotificationCenter): not yet
Accessibility: still producing distinct failures (issues #57, #71, #83, and #87)
Package and installation hygiene: a new area of work (issues #79, #84, and #88)
Rounds #15 and #16 produced the same stable boundary. I no longer needed to question the base components. The remaining beta work was concrete: make compositions and higher-level components genuinely data-driven, finish accessibility, and clean up packaging. The lower score was the honest one.
Next up: build log #17
- An error page, search results, or a profile, with the focus staying above that boundary.
The run
- gunjo.jp / npm
@gunjo/ui/ GitHub - Earlier rounds: #1 through #15
- Overview: Gunjo (
@gunjo/ui) / Why it exists: Design systems in the age of AI - GunjoUI by UIXHERO
Gunjo was still in early alpha at the time; issues are welcome.
This series is co-created with AI (Claude and Codex). A human designs the experiments, makes the calls, and fact-checks before publishing; the AI does the hands-on work and drafting.
Components from @gunjo/ui
The components this screen's source imports directly.
The code the agent actually wrote
Click a file to expand its source.