Long-running AI coding agents have a recurring problem: architectural drift. Every time the agent picks up where it left off, it has to re-derive your project’s structure, conventions, invariants, and wiring from the raw repository. There’s no persistent architectural memory.
One developer on the OpenAI community forum is proposing a different pipeline structure to address this.
The Current Pattern vs. the Proposed Pattern
Most AI coding workflows today look like a single loop: LLM reads the repo and outputs code. The agent keeps rediscovering context it already figured out two sessions ago.
The proposed alternative introduces a middle layer:
- A first LLM works at the architectural level, producing an Architecture Graph or DSL
- That representation goes through formal validation
- A deterministic generator materializes it into a complete project scaffold
- A second LLM then works inside that generated project, focused purely on business logic
The key idea: move everything deterministic out of the LLM’s hands entirely. Project structure, HTTP and gRPC and Kafka wiring, CI configuration, Docker setup, telemetry, runtime integration, and repetitive infrastructure all go into the generator. The LLM never has to re-infer them.
What the Generator Handles
- Project structure
- HTTP, gRPC, and Kafka wiring
- CI pipelines
- Docker configuration
- Telemetry setup
- Runtime integration
- Configuration management
- Repetitive infrastructure patterns

The Open Question
The developer is asking a direct question: will future coding agents get good enough that an intermediate architectural representation becomes unnecessary, or does an Architecture → Validation → Generation layer actually earn its place in the stack?
They also note a gap in the current tooling landscape: despite how mature the streaming and distributed systems ecosystem is, they haven’t found a good architecture-first designer for distributed event-driven systems that also generates production-ready projects.
Their own experiment in this direction is called GoRunDebug Service Architect, which they’ve been building for several months.
If you’re building agents that touch multi-service or event-driven architectures, this framing is worth sitting with. The drift problem is real, and whether the fix is a smarter agent or a constrained generator is still an open question.
