3 weeks, 0 Rust, 1 shipped app: what worked with Claude Code for a C++ dev.

Kalin Pezhgorski — Fri, 29 May 2026 06:59:12 +0000

I write C++ full-time. Before this, I had never touched Rust.

Three weeks ago I read an article about offline background removal and started building a desktop photo editor for marketplace sellers — the eBay, Etsy, Amazon FBA crowd. Background removal, lighting fix, 4x upscaling, smart crop to marketplace dimensions. It runs entirely offline on the GPU using ONNX models.

I didn't know what ONNX was when I started. Honestly, even now, don't ask me to explain it.

The stack

Tauri v2 (Rust backend + React/TypeScript frontend)
ONNX Runtime with CUDA, running 4 ML models
All image processing in Rust. The frontend just displays results.

Somewhere along the way we ported the IAT exposure-correction model to ONNX and put it on HuggingFace. As far as I can tell, nobody had published an ONNX export of it before. I had never downloaded anything from HuggingFace before this project, let alone uploaded to it. Claude handled all of it.

Knowing C++ helped — but not how I expected

I assumed my background would help me read Rust. It didn't, much. The borrow checker is its own animal.

What actually helped: I could usually tell when Claude was doing something dumb, and stop it before it dug a hole. I barely understood the Rust it was writing, but I understood bad engineering when I saw it. Wrong abstraction, a function doing five things, copy-pasted logic that should've been shared — that stuff looks the same in any language.

So I spent a lot of energy drilling one rule again and again: single class, single responsibility. Break up the monoliths. Kill the duplication. It made debugging far less painful later.

The one habit that saved me

Ask for a code review after every implementation step, not at the end.

That's it. That's the whole trick. It caught structural problems while they were still cheap to fix. The alternative — building for three weeks and then asking "okay, is this any good?" — would have been a nightmare.

One catch: Claude sometimes gets lazy and decides a reviewer's feedback is "minor" and not worth acting on. Sometimes it's right. Sometimes it isn't. This is exactly where having some coding experience pays off — you can tell whether "minor" actually means minor, or whether it's about to bite you.

The lesson I learned the hard way: don't let it agree with you

This one cost me real time before I figured it out.

If you ask the model a leading question, it tends to confirm your guess instead of checking. The framing leaks into the answer.

The dangerous version isn't a factual question. "Does function X take argument Y?" is leading, but it won't really fool you — there's one right answer and you'll catch it the moment you look. What fools you is a design hunch phrased as a suggestion:

"Maybe the right place for function X is in class Y?"

There's no single fact to check there. It's a judgment call. And the model will happily agree, move the function, restructure around it, and hand you back a confident rewrite built entirely on your half-formed guess. You won't notice until the abstraction feels wrong three steps later.

The fix is to ask what's true, not whether your guess is true:

Bad: "Maybe function X belongs in class Y?"
Good: "Where does function X belong, and why? What are the trade-offs?"

Same thing when you send subagents off to check assumptions. Phrase the task as an open question, not a confirmation, or they'll come back telling you what you wanted to hear. I eventually wrote this into my project instructions so it'd stop happening: when my own prompt is phrased as a confirmation, restate it as an open question first, then answer. Catching the bias before the answer is written saves you from debugging a fantasy later.

What else Claude did

Basically everything outside the core app:

The landing page
SEO
Privacy policy
Hosting and analytics

I'm not an expert in any of that, and I'd never launched anything before. It works. Windows and Linux builds are both running. The site is at listinggems.com, and I just hooked up payments.

For a first-timer who'd never shipped a product, the non-code parts (hosting, analytics, payments provider, the legal boilerplate) were not the small tasks I expected them to be. Worth saying out loud, because nobody warns you about that part.

I could use some beta testers

I want to test on hardware I don't have. Specifically: I haven't benchmarked AMD GPUs on Windows at all. If that's you, I'd love your numbers.

Happy to hand out free keys to anyone willing to test. And I'm glad to answer questions about any of it — the plugins, the workflow, the Tauri/ONNX setup, how I got Claude to behave. Ask away in the comments.