Jay noticed it on a Thursday. He'd been doing his usual review of agent output—not reviewing the code, because they didn't do that, but reading it out of curiosity, the way you might read a colleague's work to understand their thinking. And the agents didn't think, not exactly, but they produced code that looked like the product of thinking.
Clean separation of concerns. Every module with a clear boundary. Error handling that followed a consistent pattern: check, wrap, propagate. Not the pattern Jay would have chosen. Not the pattern anyone on the team would have chosen. But a pattern. Consistent. Deliberate-looking.
"Navan," Jay said. "Come look at this."
Navan wheeled his chair over. Jay had three files open side by side. Different modules, different functionality, different weeks of agent output. The same architectural style in all three.
"That's a hexagonal architecture," Navan said, squinting. "Ports and adapters. But we didn't specify hexagonal architecture anywhere."
"We didn't specify any architecture."
They both stared at the code for a moment.
"The NLSpec for Attractor has structural guidelines," Navan said slowly. "But nothing this specific. Nothing that says 'use ports and adapters' or 'wrap errors at boundary crossings.' The agents are doing this on their own."
"Not on their own," Jay corrected. "From the scenarios. Look." He pulled up a scenario file. "This scenario tests an integration boundary. The agent has to make the Okta twin talk to the Slack twin through the application layer. If you're going to satisfy this scenario reliably, you almost have to separate your concerns cleanly. A tangled architecture would fail the satisfaction metric."
Navan leaned back. "So the scenarios are implicitly selecting for good architecture."
"The scenarios are a fitness landscape. The agents are hill-climbing. And clean architecture is at the top of the hill."
They brought it to Justin the next morning. Justin was unsurprised in the way that meant he'd been thinking about this for months.
"In Software 1.0," Justin said, "you had to specify architecture up front. You drew diagrams. You wrote ADRs. You had architecture reviews. All of it was a human trying to impose structure before the code existed." He paused. "In the factory, the structure emerges from the constraints. The scenarios are the constraints. The architecture is an emergent property."
"Like how flocking behavior emerges from three simple rules," Navan said. He'd been reading about this. Of course he had.
"Exactly like that. Each agent follows simple rules: satisfy the scenario, meet the spec, keep satisfaction high. The architecture nobody planned just falls out of the process."
Jay went back to his desk and kept reading. The more he looked, the more patterns he found. Consistent logging formats. Idiomatic error types. Interface contracts that were never specified but were always honored. The agents had converged on a style. Not because someone told them to. Because the scenarios demanded it.
He opened his notebook—a digital one, unlike Navan's paper—and wrote: The best architecture is the one nobody designed.
He thought about it for a second, then deleted it. It sounded too much like a fortune cookie. But it was also true.
The idea that scenarios implicitly select for good architecture is genuinely interesting. It's like evolutionary pressure but for code structure. I want to see the actual agent output now.