A graphics programmer explains how he stopped writing and reading code manually, instead using tests, hardware knowledge, timing queries, and AI-generated technical reports to verify correctness and performance.
Adapted from @dangreenheck# Goodbye, VSCode 🍻 Well, I think it's time to finally say goodbye to VSCode 🍻 I'm continually trying to be honest with myself as I work with AI and determine what are old habits/ego vs. useful effort. I haven't written code manually in many months and at this point I've started weaning myself off reading the code for the majority of my development. It wasn't until the latest generation of models that this was actually possible. The problems I work on generate extremely dense, computational functions that were never easy to read to begin with. I've done computational programming for 15 years now and I can tell you implementing algorithms in code SUCKS. It's so easy to miss a parenthesis, substitute in the wrong term, get a sign wrong. When I wrote my OpenFracture—my mesh fracturing library for Unity I wrote 5 years ago—it took me weeks to fix all the indexing and triangle winding issues. I now look back on that like C programmers looked back on writing Assembly— "Thank God I don't have to do that anymore!" Don't get me wrong, I absolutely LOVED coding by hand. I loved the craft, the science and intuition of good vs. bad design, of feeling like the code is an extension of me. But that's not my identity and not the value I provide as an engineer—my value is solving difficult problems. With AI, I can now work on interesting problems that were previously inaccessible to me. "So Dan, if you aren't writing or reading code, how do you know what it's generating is correct?" Good Question! 1. In graphics programming, you still need an understanding of how the hardware is executing the code, memory usage, texture precision, how memory is shared, where the hot paths are. I use my engineering knowledge to ask probing questions and get detailed reports back. My favorite part is I can ask questions on concepts I don't understand until I do. 2. Tests, tests, tests. It's hard to test shaders, but AI makes it easy to create these tests. It's trivial to evaluate sections of shader code, populate buffers with test data, execute the code, read the buffers back and evaluate it. 3. Detailed performance metrics. With WebGPU, I can insert timing queries and get detailed report cards of how each part of the code is performing. I find this invaluable in determining hot spots and where I should focus my energy during optimization. I wrote a blog post on how to do this if you are interested. (https://threejsroadmap.com/blog/profiling-webgpu) 4. Technical reports. This is one of my favorite things to do. Let's say I want to optimize performance in some area or want a better understanding of how a certain part of the code works. I'll prompt the AI to build me an HTML report with diagrams and tables. So instead of trying to parse through code, I have a nice, human-readable document. Now will I miss things that I may have caught otherwise? Possibly. But I'm not a purist and have never claimed to be. I'm a huge advocate against premature-optimization. Just like you could probably squeeze more performance out of a function by writing assembly code instead of C code. I'm sure I'll continue to review code for a while, but I'm going to continually be shifting my energy towards creating tooling and reporting that provides much more useful information, actionable information.
