I’m building a side project — an offline-first PWA called Starchive where teams track appreciation with stars and hearts. Stars are admin-given points (gold, cashable). Hearts are anyone-to-anyone permanent thank-yous (pink, never cashed out).
I’m doing this with opencode and opencode-go, using DeepSeek V4 Flash as my main model. It’s fast and cheap — ideal for the 700+ message sessions where I’m iterating on code, and it helps me stay under my monthly usage limits.
But here’s the thing. DeepSeek V4 Flash is fast and cheap, and the UI it produces reflects that. It works, but it doesn’t think much about how a human will interact with it.
The Problem
I asked it to implement a hearts feature alongside the existing stars system. The UI worked, but had obvious usability issues:
The person card jumbled the heart icon right in with the star controls — same row, same size, same rounded shape. For non-admins, the disabled star controls stayed visible and looked tappable, making the app feel broken. And the send-hearts modal showed an empty dark photo thumbnail even when nothing was attached.
The implementation works. But it doesn’t feel right.
The Two-Model Pattern: Compose with Cheap, Review with Slightly Less Cheap
I wanted a fresh pair of eyes on the UI — a model that would look at the screenshots cold, without knowing the code behind them. The cheap model I was building with (DeepSeek V4 Flash) was great for implementation, but I wanted a stronger visual model for the review. So I designed a two-model workflow on purpose.
Here’s the pattern:
- Stay in the cheap model to compose the prompt. DeepSeek V4 Flash already had full context of the codebase from the 700+ message session. I asked it to write a prompt I could hand to another agent for a UI review. My first ask was simple:
“Please give me a prompt I can use to ask another agent to review the UI implementation and look for confusing UI elements or button arrangements, include enough context about the feature for the agent.”
It came back with a good draft, but I had to correct it — it was including implementation details that would bias the reviewer, and it wasn’t pointing the reviewer at the actual screenshots. Two rounds of tweaks:
“Tell it where to find the report and screenshots. It should not review code, just screenshots.”
“Don’t include details about what the UI does right now. DO include details about what actions the user should be able to take, and what info they should be able to see easily.”
The final prompt was tight — clear rules (“Do NOT read any code”), a structured deliverable format, and enough feature context without leaking implementation bias.
- Start a new session with a more capable model. Paste that prompt verbatim. Include the screenshots. Let it look with fresh eyes.
I used Qwen 3.7 Plus for this — a tier up from Flash, but run through opencode-go so it’s still way cheaper than the big-name providers.
- Let it critique first, then design. Don’t ask for solutions right away. Let the model do a purely visual pass.
The Review
The review model read each screenshot and came back with 8 issues across 4 severity levels. Its CRITICAL finding was spot-on:
“Disabled star controls look tappable to non-admins. The [-] and [+] buttons are greyed out but still fully visible. A non-admin will likely tap them, get no response, and think the app is broken.”
It got visual details I hadn’t noticed — like the heart badge reading “3♥ testuser” (count before name), or the toast “Undo (1)” not saying what it was undoing.
Then It Built Wireframes
Here’s the part that surprised me. After the text critique, I asked:
“Good, please produce wireframe images with suggested layouts for beautiful and intuitive UX.”
The model produced a full HTML page with CSS-rendered wireframes — working mockups of every proposed fix, complete with before/after comparisons and annotation callouts.
Before vs After: Admin card
The fix: a divider separates star controls from the heart action. The heart becomes a labeled pill button. The heart count badge moves next to the name.
Before vs After: Non-admin card
The fix: hide star controls entirely. The heart button becomes the sole action — large, centered, pink glow. Nothing looks broken because nothing is disabled.
The modal (no phantom box)
The wireframe showed the photo attachment as a dashed-border button. The empty thumbnail only appears after you pick a photo. Small details, huge difference in feel.
The Bottom Line
The two-model pattern added a few cents to my usage and saved me probably an hour of back-and-forth. I traded a bit of my monthly token budget for the chance that a stronger visual model would catch UI issues the implementation model might not flag. That bet paid off — the wireframes alone were worth the extra tokens.
I’m still experimenting with how to combine models for the best mix of speed, quality, and cost. This particular combo — Flash to build, Qwen to review — worked well for this feature. Next time it might be a different pairing depending on the task.
Cheap model builds. Slightly less cheap model reviews. Cheap model executes the fixes.