Jay watched the terminal with the focus of a man watching two chess players simultaneously, each on their own board, each unaware of the other, each working toward the same victory.
On the left side of his split terminal: Claude. Generating the HTTP handler for a REST API, method by method, writing Go code that was clean and idiomatic and occasionally surprising in its elegance. It was building the request parsing layer, handling headers, validating input schemas, returning properly formatted error responses.
On the right side: Codex. Generating the database layer. A PostgreSQL client with connection pooling, prepared statements, transaction management. The code was different in style from Claude's—more terse, more functional, fewer comments—but equally correct.
They were running in parallel. Two agents, two independent tasks, no shared state between them. The sprint plan had marked these tasks as independent: the HTTP handler didn't depend on the database layer, and vice versa. Agate had read the dependency graph and determined that they could run simultaneously.
"What happens when there's a dependency?" Jay asked.
Justin was watching the same terminal from across the room, his coffee going cold. "Sequential execution. If task B depends on task A, Agate runs A first, waits for completion, then starts B. The sprint plan's dependency graph determines the execution strategy."
"So it's a scheduler."
"It's a scheduler that reads markdown. The sprint plan is the job spec. Independent tasks fan out in parallel. Dependent tasks chain sequentially. The system maximizes throughput without violating dependencies."
Jay watched Claude finish the HTTP handler. A few seconds later, Codex finished the database layer. Then the next task began—the integration layer that wired the handler to the database. This one ran on a single agent, Claude, because it depended on both previous outputs and required a coherent view of the combined codebase.
The integration was clean. Claude had read both the handler and the database layer, understood their interfaces, and produced a bridge that connected them without unnecessary abstraction. The wiring was straightforward: the handler called the database client through a thin service layer. No framework. No dependency injection container. Just functions calling functions.
"Do they ever conflict?" Jay asked. "When they're running in parallel?"
"Not on independent tasks. They're writing to different files, implementing different interfaces. The conflict potential is zero because the sprint plan's dependency analysis ensures they never touch the same code. It's the dependent tasks where you need care—and those run sequentially, so there's no race."
Jay watched the final tests run. The HTTP handler tests passed. The database tests passed. The integration tests passed. The entire sprint had taken forty minutes instead of the three hours it would have taken sequentially.
"It's like having two engineers," Jay said, "who never step on each other's toes because someone planned the work correctly."
Justin smiled. "That's all project management ever was, at its best. Making sure people aren't waiting for each other unnecessarily."
A scheduler that reads markdown. That's either the most cursed or the most beautiful sentence in software engineering. I'm going with beautiful.