How Forward Deployed Engineering is done at Factory — Eno Reyes
Factory’s deployed-engineering model treats agent adoption as workflow design: instrument the path from signal to deploy, build validators, and tie autonomy to measurable business outcomes.
Factory frames software delivery as a loop from incoming signals through planning, code changes, validation, and deployment. Its own codebase has roughly **15–20% autonomy**, while a constrained internal legal workflow is described as effectively fully autonomous.
Builders should invest in agent readiness before longer runs: bounded tasks, explicit completion criteria, dense verification signals, observable workflows, and an ROI link to business goals. The engineer’s role shifts toward maintaining the system that produces software.
Factory frames software delivery as a loop from incoming signals through planning, code changes, validation, and deployment. Its own codebase has roughly **15–20% autonomy**, while a constrained internal legal workflow is described as effectively fully autonomous. Builders should invest in agent readiness before longer runs: bounded tasks, explicit completion criteria, dense verification signals, observable workflows, and an ROI link to business goals. The engineer’s role shifts toward maintaining the system that produces software. Autonomy depends on what can be verified. Factory says visual terminal defects such as flicker still prevent a closed loop in its core harness, so **100% autonomy** appears more attainable first in constrained internal tools than in broad product surfaces.
This grounds autonomy in workflow economics and verifiability rather than model capability alone. Factory’s large gap between its broad codebase and constrained legal workflow confirms that bounded tasks, dense validators, observability, and explicit completion criteria determine how far the loop can close; hard-to-measure visual defects mark a concrete ceiling, while maintainability and approval remain separate concerns.