Pierre-Antoine Bannier
486 posts
@el_PA_B
ML for Biology. Previously at @OwkinScience . Education @Polytechnique and @HECParis.
tissue biopsy slides are the most common biological samples in oncology. they're used as the gold standard for diagnosing cancer. this is why @SophontAI builds foundation models trained on tissue slides these models will facilitate better understanding & treatment of cancer!
For my work, I need to visualize cell segmentation and tissue annotations on whole slide images. These are massive pathology scans, multi-gigabyte files with millions of cells. Problem: my data format wasn't compatible with any existing WSI viewer out there. So I figured why not just vibe-code my own pathology viewer that supports my exact format? I genuinely had no idea how long a project like this would take me. I decided to go with C++, mainly for performance reasons, but also because I'm familiar with the language and knew I'd need every bit of speed I could get. I set myself one rule: I wouldn't write a single line of code. Claude would do it all. I used @doodlestein's methodology, which breaks down like this: Step 1: Write a ridiculously detailed plan I drafted a comprehensive implementation plan and had it reviewed by multiple agents: Opus 4.5 (ultra thinking mode), Codex 5.2 (extra thinking), and Gemini. Then I let Claude Code synthesize all three perspectives into one coherent plan. It felt a bit like assembling a council of war advisors before a medieval siege. Step 2: Break it into atomic beads I created a series of small, sequential tasks that followed the implementation plan from step 1. Roughly speaking: GUI → canvas → opening a slide → rendering cells → rendering tiles. Each bead was self-contained and clearly scoped. Step 3: Quality control throughout During the process, I regularly checked in on Claude to make sure it was following professional C++ design patterns, the kind you'd expect from a world-class C++ programmer. At one point, I started referencing the book C++ Software Design: Design Principles and Patterns for High-Quality Software by Klaus Iglberger. This seemed to activate some deeper part of Claude's internal knowledge. The code quality noticeably improved. The part that surprised me the most: Multiple times, Claude's first solution wasn't optimal. For instance, it couldn't efficiently render 1M+ cell polygons on the first try. The initial version was slow, jittery, borderline unusable. So I told it to think deeply about the hot path. To use time-efficient data structures (e.g. building a spatial index) for the problem at hand. To multi-thread the rendering loop so it could determine what's visible to the user versus what's off-screen. And surprisingly, it almost always one-shot the optimized solution. Once I pointed it in the right direction, it figured out the implementation with minimal back-and-forth. Things that helped along the way: Writing lots of tests. For the more difficult beads, I asked Claude to use a test-driven development approach. This gave it a clear objective to optimize against: make the test pass. It worked remarkably well. Isolation before optimization. For performance-critical prompts, I learned to explicitly say: "First, isolate the part of the code we're trying to optimize before diving into the implementation." This prevented Claude from making sweeping changes when surgical precision was needed. The viewer works. It's fast. It handles my weird data format perfectly. And I still haven't written a single line of C++.
@Zoomerjeet True
