The Shift from Implementation to Specification

Dominik Tornow argues that the future of software engineering lies in moving away from general-purpose libraries and frameworks toward bespoke implementations generated on demand. In this model, the "product" is no longer the code implementation, but the abstract specification. By treating the prompt as the platform, developers can derive multiple, target-specific implementations from a single, minimal protocol. This approach allows for the creation of systems that are tailor-made for existing infrastructure with minimal dependencies.

The Agentic Engineering Workflow

Directly asking an agent to jump from an abstract specification to a concrete, production-ready implementation often fails because the gap is too wide for the agent to handle concurrency, network failures, and edge cases. Tornow proposes a multi-stage process to bridge this gap:

  1. Abstract Specification: Define the system without assuming concrete database schemas, consistency models, or storage primitives.
  2. Executable Design (Simulation): Use a deterministic simulation environment to discover the correct algorithms under partial order and partial failure. The agent acts as the driver here, iterating on the design.
  3. Concrete Specification: Once the algorithm is verified in simulation, derive a concrete specification that makes target-specific decisions (e.g., SQL queries, indices) explicit.
  4. Concrete Implementation: Generate the final production code from the verified concrete specification.

Leveraging Deterministic Simulation for Debugging

Agents struggle with distributed systems because they lack visibility into why a specific failure occurred. Tornow’s approach uses deterministic simulation to provide the agent with "forbidden" information—facts that the production code cannot see, such as whether a read was fresh or stale, or what the actual latest value was in the system.

By exposing these hidden facts to the agent, the agent can perform causal analysis. It learns not just that an invariant failed, but why it failed (e.g., the algorithm made a decision based on a stale view of the world). This feedback loop allows the agent to repair the algorithm against specific execution traces, effectively turning the agent into a design partner rather than just a code generator.