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 adds an operational constraint to software-factory claims: autonomy rises only where completion can be verified densely and reliably. Factory’s contrast between limited autonomy in its broad codebase and effective autonomy in a constrained legal workflow supports bounded tasks, observable loops, and business-linked validators, while visual defects that remain hard to verify mark a concrete barrier to closing the loop.