The 48-Hour PR: A Better North Star for Forward-Deployed Engineering
Measure the complete path from a client request to an approved, merged pull request, not the speed of an isolated AI demo.
Fast code is not the same as fast delivery
Most AI development demonstrations measure the time required to produce code. That is useful, but it ignores the work that dominates enterprise delivery: understanding the request, preserving constraints, validating the workflow, capturing approval, and moving a safe change through engineering review.
A team can produce a prototype in an afternoon and still spend three weeks translating it into tickets, reconstructing decisions, resolving security questions, and persuading engineering that the change is supportable. The bottleneck is not typing. It is the chain of trust between the client request and the production change.
The North Star
A more meaningful operating metric is median time from client ask to merged, approved pull request. The clock begins when a client or business user makes a concrete workflow request. It stops only when the resulting change has been reviewed, approved, and merged into the governed engineering process.
For a forward-deployed delivery platform, an ambitious target is under 48 hours compared with a typical two-to-four-week baseline. The target is not achieved by bypassing controls. It is achieved by carrying context, evidence, approvals, and reusable artifacts through one continuous workflow.
What has to change operationally
Reaching a 48-hour cycle requires more than a coding agent. The delivery system must preserve the original client language, connect it to the working experiment, capture every material decision, and produce an engineering artifact that reviewers can trust.
- Start from a governed product or solution baseline rather than a blank workspace.
- Give each engagement an isolated sandbox with explicit data, tool, and execution boundaries.
- Let users validate a working experience instead of approving abstract requirements.
- Attach intent, constraints, evidence, test results, and approvals to the pull request.
- Separate reusable product learning from account-specific exceptions before merge.
The supporting scorecard
The North Star should be accompanied by measures that explain why the cycle is improving: sandbox-to-PR conversion, approvals captured per engagement, knowledge reuse, weekly active forward-deployed engineers per licensed seat, and net revenue retention created by seat expansion inside systems-integrator accounts.
Together, these measures prevent a false version of speed. A team is not truly faster if it creates more abandoned sandboxes, less reuse, weaker governance, or greater product entropy. Sustainable speed compounds because each engagement leaves the next one with better starting assets and clearer evidence.