A carousel revealed 28 copies of the same provider bug
/carouselCaptured 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
A carousel revealed 28 copies of the same provider bug
Build log series: I hand a real screen to an AI that has never seen Gunjo (
@gunjo/ui) and let it build. Each article also serves as a practical Gunjo guide. After #1, a settings screen, and #2, a modal announcement, this round covered a carousel.
The conditions stayed the same. I gave the agent only the public npm package @gunjo/ui (alpha.2) and the gunjo.jp docs. It could not see the source. Starting from a blank Next.js app (React 19 and Tailwind v4), it had to reach a passing npm run build on its own.
The assignment
Build the carousel that appears so often on landing pages and in media lists: multiple slides with an image and heading, previous and next buttons, and dot indicators. This round covered the Display category (Carousel, Card, Img, and Badge).
Result: 4/5. It worked
npm run build passed, /carousel rendered statically, and I confirmed zero console errors on a real device. Autoplay, looping, dots, the "Slide N of N" counter, and keyboard arrow controls all worked.
Again, having every typed component available from one place made the difference. The agent found Carousel immediately. It liked the composition: controls={{ navigation: true, dots: true }} produced both navigation buttons and dots. Img also stood out because it handles aspect ratio, object fit, a skeleton, and a quiet fallback for image errors.
<Carousel className="w-full" opts={{ loop: true }} autoPlay
controls={{ navigation: true, dots: true }} setApi={setApi}>
<CarouselContent>
{slides.map((s) => (
<CarouselItem key={s.title}>
<Card className="overflow-hidden">
<Img src={s.poster} aspectRatio="video" objectFit="cover" />
<CardContent>{/* ... */}</CardContent>
</Card>
</CarouselItem>
))}
</CarouselContent>
</Carousel>
The real finding: this was only the tip of the iceberg
The first build failed with a very familiar error.
Error: `Tooltip` must be used within `TooltipProvider`
It was the same server-side rendering (SSR) crash that Banner triggered in #2. The carousel's previous and next buttons (TooltipButton) and dots (Tooltip) did not provide the TooltipProvider they require. After #2, I had fixed Banner in issue #49. I thought the bug was gone.
I audited the source for every component that uses Tooltip without providing TooltipProvider. There were 28. They included Carousel, TooltipButton, Calendar, DatePicker, Combobox, Command, DataTable, Accordion, and Avatar. Only Banner and Toast had a provider.
Issue #49 was only the tip of the iceberg. I had fixed one bug while leaving its shared cause intact.
This was the moment the cold test found a pattern, not a single bug. Fixing the components one by one could have hidden the common defect for months. The third innocent assignment, "build a carousel," exposed it. The design decision changed too: make Gunjo's Tooltip wrapper self-contained and repair all 28 consumers together. I recorded that work in issue #52, and the fix landed in PR#54.
Other rough edges surfaced too:
- The docs' code examples did not appear in fetched content. Issue issue #50 from round two was not deployed yet, so the agent reconstructed the composition from TypeScript types.
- Passing an object to
controlsunexpectedly turns every unspecified default off, and the docs did not say so. Carouseldefaulted to a fixedw-[640px], whileImgdefaulted toh-[256px] w-[256px]. Neither filled its container out of the box, so both needed overrides. That was the same family of defect as issue #47.
What I took away: prove the guarantee after testing it
Have the AI use it | Find the rough edges | Fix every source consistently (SSOT) | Run it again
The biggest result from round three was learning through my own test that Gunjo did not yet cover the hardest 20 percent of real screens reliably. Claiming otherwise while 28 components could crash would have been false. The build log series exists to catch that problem before I publish the claim. No embellishment and no hiding. Every defect becomes an issue and gets fixed.
Next up: build log #4
- A dashboard using charts, stats, and a table. Gunjo's charts are built from HTML and CSS layout components. The agent will test whether they survive arbitrary data, which is central to what makes them different.
The run
- gunjo.jp / npm
@gunjo/ui/ GitHub - Previous rounds: #1, settings / #2, modal announcement
- 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.
