Last week, with my buddy Claude Code, I built a small Golang service to process cloud recordings from Zoom meetings. The code felt clean, and the unit and local integration tests Claude helped build provided decent coverage. The service performed as expected, in production, across several requests.
Then a larger job came in and silently stopped partway through. The code was fine, but the architecture was wrong.
Claude’s design was to ACK the “webhook” call from Zoom and then fire off a goroutine to process the “cloud recording completed” event. This pattern is okay on a traditional server, or for a task that can be processed very fast. But on Google Cloud Run, where this service is deployed, there are two problems:
- CPU is throttled to near-zero between requests, which will slow down the background processing even more. You can set CPU allocation to “always on” to avoid this.
- Instances can be reaped since they won’t be kept idle for more than 15 minutes. Setting –-min-instances=1 avoids this from happening.
Both settings come at a cost 🙂
So what? Understandably, the “background” goroutine is not considered part of the request processing lifecycle. CPU was throttled, and the instance was reaped while the work was being performed.
“By default, Cloud Run instances are only allocated CPU during request processing as well as during container startup and shutdown as per the instance lifecycle.”
To arrive at this conclusion, Claude Code analyzed the logs and deployment configuration. Based on that analysis, it suggested the right pattern was Cloud Tasks: enqueue the work and let a separate invocation process each event. Afterwards, I asked it to ground the analysis in real information sources. Never forget to do that – training data is always stale! It’s a different architecture and execution model, but fortunately the code does not have to change much… That’s a topic for the next article 🙂
What this continues to reinforce for me:
- AI coding agents can write good code. But they can still make confident-sounding claims that aren’t right, or pick a pattern that works in general but is wrong for the specific runtime. Architectural judgment (i.e. matching the pattern to the workload and the platform), is where experience still earns its keep in spades. I should have first spent more time up front learning different architectural patterns on Google Cloud.
- AI coding agents are good at researching options. But you can’t rely on answers solely produced by what it was trained on. You need to ground them in current, and ideally verified, resources – e.g. curated documents, blog posts, and real code examples. The exact answer was lurking in documentation, if only it found it before initially proposing an architecture.
- AI lets you ship code faster than you can review; A solid test suite is critical. The tests have to cover the real operating envelope, in an environment as close to production as possible, not just the happy path. Never go too far without being able to run reliable tests. In this case, my integration tests run the server locally, so this problem would never get caught. The issue only surfaced in production.
Claude wrote good code, but it also made a real mistake. The “engineer in the loop” still owns what the code is doing on the platform it actually runs on.