Claude Sonnet 5 and GPT-5.6 Sol Build a Filter Panel
Claude Sonnet 5 and GPT-5.6 Sol, one React brief
The interesting part of an AI-generated component is not the screenshot. It is what happens when you press Escape, clear the search, or pass an empty array. That is where a convincing demo either becomes application code or becomes another afternoon in your editor.
Here is a worked, illustrative comparison of two implementation approaches for the same frontend task. These are hypothetical drafts for reviewing tradeoffs, not outputs from a measured model run. The verdict applies to the drafts described below, not to either model’s overall capability.
The assignment: build a searchable project picker in React and TypeScript. It needs a trigger button, a search field, selectable results, a selected-project indicator, and an empty state. Use existing CSS utilities, add no dependencies, and keep selection controlled by the parent.
The project picker contract before either draft
I would put the requirements in a repository file rather than drip-feed them through chat. Both attempts should start from the same commit, receive the same component types, and see the same surrounding styles. Otherwise, you are comparing context quality as much as generated code.
- The parent supplies projects, the selected identifier, and a selection callback.
- Searching matches project names without changing the original input array.
- Keyboard users can open, navigate, select, dismiss, and recover focus.
- Empty results and missing selections must produce explicit, readable states.
- The implementation must pass existing checks without adding package dependencies.
Keep the first response untouched until both drafts exist. Then run the same checks and allow one repair pass with equivalent feedback. Unlimited conversational polishing makes the comparison impossible to interpret.
The Sonnet-side draft: smaller state, simpler review
In the illustrative Claude Sonnet 5 draft, the picker uses native buttons for results. Local state holds only the open flag and search query; the selected project comes directly from props. Filtering is derived during rendering rather than synchronized through an effect.
That makes the diff easy to understand. There is no second copy of the selected identifier waiting to drift out of sync. A parent update immediately changes the trigger label, and clearing the query restores the full project list.
The weakness is interaction polish. Tab reaches each result, but arrow-key navigation is absent. Dismissal also needs an explicit focus-restoration path. This is a straightforward implementation, not yet a finished searchable combobox.
The GPT-side draft: richer interaction, more moving parts
In the illustrative GPT-5.6 Sol draft, the picker tracks an active result and handles arrow keys, Enter, and Escape. It includes an empty-state message and separates filtering from selection. The first keyboard walkthrough feels closer to the requested interaction.
The review problem is duplicated selection state. Copying the incoming identifier into local state introduces synchronization work that the component contract never required. Another edge case appears when filtering shrinks the result set: the active index must remain valid before Enter can select anything.
These are fixable issues, but they add reasoning overhead. More event handlers do not automatically mean better accessibility; roles, focus behavior, and keyboard conventions still need to form one coherent pattern.
Running the same comparison through Fluxo
Fluxo makes the transport setup less distracting: one key and one base URL, https://api.fluxorelay.com, cover Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok, and more. It works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK. Keep the repository context and prompt identical when switching models.
Billing follows real tokens, including cache reads and writes, with no monthly fee. Compare the whole attempt, including repairs, rather than just the first response. Users also earn a referral share when people they invite pay. If you want to try this workflow, you can create a Fluxo account.
The project picker verdict: take the smaller correct foundation
For these two illustrative drafts, I would keep the Sonnet-side implementation and finish its keyboard behavior before shipping. Controlled selection and minimal state provide the cleaner foundation; the GPT-side draft offers useful interaction ideas but needs unnecessary synchronization removed.
That is a draft-level verdict, not evidence that one model consistently wins. In a real run, choose the implementation that satisfies the contract with fewer correctness repairs. Save both diffs and test results: the winner should survive the terminal, not merely look persuasive in chat.