Round #3Score 4/5Foundation / generic UI

A carousel revealed 28 copies of the same provider bug

Route: /carousel
Desktop preview
Mobile preview

Captured 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 , and , 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.

Carousel

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 . The carousel's previous and next buttons (TooltipButton) and dots (Tooltip) did not provide the TooltipProvider they require. After , 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 from round two was not deployed yet, so the agent reconstructed the composition from TypeScript types.
  • Passing an object to controls unexpectedly turns every unspecified default off, and the docs did not say so.
  • Carousel defaulted to a fixed w-[640px], while Img defaulted to h-[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

  • ⁠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: /
  • 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.

業界別「AI指示書パック」、先行登録を受付中です。