Round #177Score 5/5Construction / architecture

I handed a fourth screen to an AI, and it needed no new components

Route: /progress-billing
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

I handed a fourth screen to an AI, and it needed no new components

⁠Build log series⁠: I give an AI that has never seen my design system @gunjo/ui only the public npm package and the gunjo.jp docs, and have it build real screens. For the fourth construction round, the brief was a ⁠progress payment assessment screen for construction managers and cost estimators⁠. The workflow covers accumulated progress for each type of work, the percentage of the contract amount completed, a breakdown of the progress payment request, and the stages of assessment and approval.

Result: 5/5. Almost nothing new had to be built

The progress payment screen passes tsc and works across mobile and desktop.

Each of the previous three construction screens (the site schedule, construction photo log, and safety briefing board) exposed a gap specific to the industry. The fourth screen, a progress payment assessment, was different: ⁠existing components already covered every element at its core, leaving almost nothing new to build.⁠ The only hand-rolled parts were small supporting pieces and the amount calculations themselves.

Existing components handled the three core areas out of the box.

  • ⁠Amount breakdown = AmountBreakdown was originally built for insurance payouts and pay statements, but it mapped cleanly onto a progress payment request: start with the cumulative amount earned, subtract previous billings and the applied advance payment, then add tax to calculate the amount of the current request. The same component also handles "original contract + changes = current contract amount" in the work details, so one component covers two places.
  • ⁠Accumulated progress for each type of work = DataTable + inline Meter + Delta renders the progress rate as a meter inside the cell, and variance against plan shows as a delta next to it. Both fit naturally into the table. DataTable also opens details from a row click and switches to cards on mobile.
  • ⁠Assessment and approval = ApprovalWorkflow + SignedRecord lays out the stages from the site assessment through initial approval, head office approval, and the project owner's assessment, including the reason for sending an item back. Once the project owner's assessment is final, SignedRecord locks the record and permits only appended corrections, so finalized records behaved correctly with no customization.

These components were built for records in insurance, payroll, accounting, and health care. Together, they became the core of construction cost estimation, a distant industry.

The only hand-rolled parts were small pieces and calculations

The uncovered parts were details of the implementation rather than missing components.

  • ⁠Lightweight label/value pairs⁠ would simplify the small two-column layout for "current contract amount," "against plan," "this month," and "cumulative" inside the mobile cards. MetadataList was a little heavy and StatGroup was too dense for that use.
  • ⁠Loading skeletons⁠ use existing building blocks, but there are no prebuilt table or summary skeletons, so I rebuild them on every screen. A loading state in the table component would remove that repeated work.
  • ⁠Amount calculations⁠ belong to the application, not the component. The amount breakdown component is designed to display values without calculating them, which is exactly as intended.

Where the names got confusing

There was almost no confusion. The same by-use-case table led directly to the right components through terms such as "amount derivation," "approval," and "key metrics." The only uncertain choice was how to show progress. Several similar candidates existed, so the agent read the descriptions to confirm which one fit the progress percentage. Adding terms such as "progress percentage" and "percentage complete" to the table would make that path even faster.

Wrapping up

The fourth construction round broke the pattern: unlike the first three, it exposed no industry-specific gap at the core of the screen. Existing components covered amount breakdowns, multistage approvals, and locks after finalization, leaving only application calculations and small supporting layouts. The catalog has reached the point where the agent assembled a business-facing construction workflow without adding a new component.

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指示書パック」、先行登録を受付中です。