Member-only story
Three Go Patterns I Deleted After AI Started Writing My Code
Some architectural patterns that made sense when every line was human-written become liabilities when 60% of your service is AI-generated.
syarif8 min read·1 hour ago--
Last month I deleted Interface Segregation, the Builder Pattern, and a significant chunk of our Dependency Injection abstraction from a production Go service. By every classical software engineering metric, this was a bad decision. The code became more tightly coupled. Less “elegant.” Harder to test in isolation. And yet: bugs decreased by 34%, deploy time dropped 23%, and onboarding time went from 8 weeks to 4.
The service was 60% written by Claude.
That number matters. It’s not “AI helped us write some glue code.” It’s not a copilot completing one-liners. It’s the majority of function bodies, service logic, and utility layers coming from an LLM with a prompt and a context window. And the patterns I’d spent years refining for human development were quietly undermining everything.
Why These Patterns Existed (And Why They Made Sense)
I want to be fair here, because this isn’t a story about bad ideas. These patterns existed because they solved real problems — for humans writing…
