I’m very bullish on AI code assistants. It’s actually the second biggest reason I stepped down from being a director and went back to IC life. I’ll write more about that decision another time, but today I want to share how I’m using AI day-to-day—and, maybe more importantly, when it doesn’t quite fit.
My toolkit is pretty simple: VSCode, GitHub Copilot, Claude Sonnet, and occasionally KiloCode.
The hardest part of working with AI so far has been the waiting. When I’m in “agentic” mode—fire off a big prompt and wait—it kills my flow. If I don’t get an answer in five seconds, my brain is already somewhere else, usually for twice as long as the model took to respond. Because of that, I’ve built my routine around minimizing that problem:
“This is a temporary fix. I’ll come back for it later” – Famous last words that every developer has uttered at least once.
We’ve all been there. You’re staring down a deadline, your PM is breathing down your neck, and you need to ship something that works. So you write a quick hack, slap a // TODO: refactor this ugly mess comment on top, and move on with your life.
Concurrency is one of Go’s greatest strengths, but managing goroutines effectively at scale can be challenging. When you have millions of tasks to process, spawning a goroutine for each one can quickly overwhelm your system with excessive memory usage and context switching overhead. This is where worker pools come to the rescue.
A few years ago, I created bigopool, a lightweight Go library that implements high-performance worker pools with elegant error and result handling. Today, I have finally decided to write about it.
