|
|
|
|
|
by mrothroc
88 days ago
|
|
I do this across several different codebases, all event-driven microservices. Some greenfield some brownfield. My strategy is to have a central spec, typically protobuf or openapi, and every service has a make target to generate code from that. The dependencies stop being in someone's head and start being in the spec. I had this pattern long before coding agents because it helps human devs, too. The benefit is that my CI process can deterministically check if a) someone changed the spec or b) the service code doesn't compile or lint when built against the freshly generated code. This is a hard, enforced gate. If it fails, either it needs manual review or it gets sent back to the coding agent to fix automatically, so humans don't waste time looking at trivial issues. The agents can move as fast as they want within a single service. The spec gate catches cross-service breakage before it deploys. |
|