We’ve all seen it. You open a repository for a seemingly straightforward web application, and instead of a clean, cohesive architecture, you are greeted by a Frankenstein’s monster. The core business logic is housed in Python backend services, the Google Ad Manager (GAM) integration is inexplicably carved out into a standalone Golang microservice, and the frontend is a sprawling TypeScript.
Welcome to the aftermath of CV-Driven Development (CVDD)—the destructive industry practice where engineers choose hype over logic just to pad their resumes.
Instead of choosing a unified stack, someone wanted “Microservices in Go” and “Polyglot Architecture” under their LinkedIn skills section. Now they work at Google, and you are left maintaining their mess. Cosy mess, one I love to work with. Jumping between Go, Python, and TypeScript is a cognitive nightmare.
According to research from Gloria Mark at the University of California, Irvine, it takes an average of 23 minutes and 15 seconds to regain deep focus after an interruption or context switch. When your tech stack is the context switch, productivity tanks.
This was my reality until I integrated Anthropic’s Claude into my daily workflow. A recent McKinsey study found that software developers using generative AI can complete complex tasks up to 45% faster. But here’s the catch: I didn’t use Anthropic to write code. Using AI to generate more boilerplate in a broken system just creates faster garbage. Instead, I used Claude as an architectural sounding board to untangle the CVDD mess. Here is how Anthropic provided the deep insights I needed to fix the system’s design flaws.
Demystifying the Golang / GAM BottlenecK
The previous developer used Go for the Google Ad Manager (GAM) integration, presumably because Go is “fast.” The problem? They blasted the notoriously archaic, SOAP-heavy GAM API with hundreds of goroutines. Overcomplex, not fit for purpose, close to impossible to understand. As if AI generated them :D.
My Anthropic Prompt: “Act as a staff-level systems architect. Our Golang microservice handles Google Ad Manager (GAM) API requests. Instead of writing code, explain the architectural flaw here. How does GAM actually expect to be queried, and what design pattern should we wrap around our Go service?”
The Insight: Claude didn’t dump a massive Go file on me. Instead, it explained that GAM’s API. It pointed out that the “CV-driven” decision to use Go’s raw speed was wrong (go 🙂 Claude!). Claude advised me to stop treating GAM like a modern REST API and suggested implementing a different pattern.
Untangling TypeScript Frontend Waterfall
Because our data was split between Python (Salesforce) and Go (ad data and targeting), the TypeScript frontend was a mess of chained promises.
My Anthropic Prompt: “Our TypeScript frontend needs to load an ad profile data from the Python backend, and then use that data to save ad placements to the Golang GAM service. The page data points code is terrible because of this dependency. Conceptually, how should we restructure our data fetching strategy to avoid this waterfall loading, considering the separation of these backend services?”
The Insight: Claude diagnosed a classic “waterfall dependency” and offered a brilliant strategic pivot. Instead of trying to write clever TypeScript Promise chains, it suggested a Backend-For-Frontend (BFF) pattern. I am yet to implement one.
Decoupling the Python Backend Services
Our core Python services handled Salesforce.
My Anthropic Prompt: “Our Python backend makes synchronous REST to Salesforce. How could I improve it?”
The Insight: Claude immediately identified the synchronous REST call as a catastrophic anti-pattern for this architecture. It described the system in detail I would have spent hours on working through. Claude even broke down the pros (resilience, decoupling) and cons (eventual consistency, managing dead-letter queues) so I could make an informed pitch to my rewrite.
The Bottom Line
AI isn’t an excuse for bad architecture. A codebase artificially fractured into Go, TypeScript, and Python for a simple web app is still a monument to CV-driven hubris. However, when you are stuck maintaining someone else’s resume-padding vanity project, Anthropic acts as the ultimate senior engineering mentor.
By offloading the heavy mental lifting of cross-domain system design to Claude, I wasn’t just generating code—I was actually solving the underlying architectural rot. It proves that the best cure for bad engineering isn’t just complaining about the stack; it’s using AI to gain the insights necessary to finally clean up the mess.
Still at this point, after a week it can’t tell me why my dev calls to APIGW on AWS fail. I guess everything has it’s limits.
To hell with CVDD.
As per usual – the choice is yours!
Leave a comment