Alternative, structural comparison
An FDE collapses the same feedback loop a consultant handoff stretches across four artifact transfers.
Both shapes of engagement run an iteration loop: customer note in, shipped behavior out. The difference is not effort or seniority. It is how many system boundaries the loop crosses on every pass. An FDE engagement crosses zero. A consultant handoff crosses four. The loop length is structural; the engineers cannot fix it by working harder.
Direct answer, verified 2026-05-07
How does an FDE shorten the feedback loop a consultant stretches?
- An FDE engagement keeps every iteration of the customer-to-production loop inside one system: the client's repo, the client's CI, the client's eval harness. The loop is a PR + a CI run.
- A consultant handoff splits the same loop across two systems and requires four mandatory artifact transfers per iteration: ticket pickup, stakeholder readout, handoff package, and client integration.
- Loop length is structural, not cultural. A skilled consultancy still crosses four org boundaries per iteration; a junior FDE in the right setup still crosses zero.
- The fix in an FDE engagement is wired to a number on a CI run; the fix in a consultant engagement is wired to alignment in a stakeholder review meeting.
Verified against Pragmatic Engineer's 2025 piece on the role's revival in AI startups, and against the seven-point operational rubric we sign in every PIAS engagement.
What "feedback loop" literally means in an engagement
A feedback loop is the round-trip a customer signal takes to become a behavior change in production. The signal can be a Slack note, a failed agent run in the wild, an eval regression, or a stakeholder saying the wording sounds wrong. The loop closes when the next time the same signal would arrive, the system already behaves differently.
The pages that currently rank for this topic talk about the loop culturally: FDEs care about feedback, FDEs talk to users, FDEs iterate fast. That framing is correct but unfalsifiable. A consultancy can also talk to users and care about feedback. What actually decides the loop length is the layout of the system the iteration runs through. Layout, not effort.
Below, the same loop on the same agent, drawn out twice. Once for an FDE engagement on a client's repo. Once for a consulting handoff against the same agent. The actors are different, the messages are different, and the count of org-boundary crossings is visible by inspection.
FDE loop, four actors, zero boundary crossings
The customer note enters the same Slack the named engineer is in. The engineer adds a row to eval/cases.yaml in the client's repo. The PR runs the eval. The merge ships the change. The customer sees it on staging on the next deploy. Every step lives on the client's side of the org boundary.
FDE feedback loop on a client repo
Consultant handoff loop, five actors, four boundary crossings
Same customer note. The work moves to the consultancy's tenant, gets staged in their fork, surfaces in a stakeholder review, gets packaged as a deliverable, and only then re-enters the client's system as something a client engineer has to integrate. The arrows that cross between actors are the boundary crossings; the round-trip is the same shape, but each leg has a real cost.
Consultant handoff loop, same agent
Where the consultant loop loses the days the FDE loop keeps
Six structural costs of the handoff loop, each of which is paid once per iteration. None of them depend on the consultant's seniority or work ethic; they are forced by the engagement layout. A consultancy can drop one or two of them with effort, but the full set is the price of the title.
The six places a handoff loop loses time the FDE loop does not
- Ticket pickup. A note becomes a Jira row, sits in the consultancy's bench backlog until the next sprint cutoff, then gets assigned. Cost: between 0 and 14 days, mean ~5.
- Bench engineer is not in the client's repo. They write the fix on a fork on the consultancy's GitHub org, which means the client cannot see the diff in their Files Changed view.
- Stakeholder readout. The work product is a deck, not a workflow run. Alignment lands as comments in a deck rather than checks on a PR.
- Revisions are negotiated in a meeting. Whichever side has more authority in the room wins the revision, not whichever side has the higher rubric score.
- Handoff package is built. A zip file, a Word doc, a one-page README. The package is invariant under the actual diff: the package always exists, even when the diff is one line.
- Client team integrates the package. Every integration is a small re-implementation; the consultant's code rarely lands as-is because the test layout, the deps, and the CI shape differ.
(Boxes are unchecked deliberately. These are the six taxes you pay when the loop crosses an org boundary; they are not features.)
What an FDE loop closes that a handoff cannot
On the FDE side, the entire round-trip is five steps in one repo, and every step is observable to the client team in real time. No artifact moves between tenants. No stakeholder readout gates the iteration; readouts gate promotion, which is a separate event.
The five steps of an FDE iteration, all on the client's main
- Customer note arrives in the channel the named engineer is already in.
- The engineer adds the note as a row in eval/cases.yaml. The note becomes a test, not a ticket.
- The engineer iterates the prompt or the agent until the new case passes locally, opens a PR.
- pilot-gate.yml runs the full eval/cases.yaml on the PR. rubric_min_score is the answer to 'is this good enough'.
- Merge to main. The next loop opens by branching off main again. No package, no review meeting in between.
Anchor fact
Six file paths the FDE loop reads on every pass, all on your main
If the iteration loop is closed inside the client's system, every iteration touches the same six files in the client's repo. None of them exist in a consultant deliverable. Their existence is the test for whether the loop is actually short.
- rubric.yaml: numeric thresholds. The answer to "is this iteration good enough" is a number in this file, not a sentence in a meeting.
- .github/workflows/pilot-gate.yml: runs on every PR. Reads rubric.yaml. Required check from day 14.
- .github/workflows/production-gate.yml: runs on the promotion PR only. Asserts seven trailing green nightly runs. Required check from day 42.
- eval/cases.yaml: the corpus. The customer note arrives, becomes a row, becomes a test. Same file, every iteration.
- runbook/<agent>.md: the on-call playbook. Closes the loop on the production side: when the agent misbehaves at 03:00, the runbook is what stops the bleeding.
- flags/<agent>.yaml: rollout flag. The promotion PR is one line in this file.
Six files, one repo, one CI runner, one identity per engineer. That is the loop. The handoff loop reads zero of these on the client side, because the work has not crossed back yet.
Side by side: where the boundary crossings live
Seven attributes of an iteration. Left: a consultant handoff engagement. Right: an FDE engagement on the client's repo. Every row is something a procurement officer can verify against an SOW or against the GitHub access log.
| Feature | Consultant handoff | FDE on client repo (PIAS) |
|---|---|---|
| Where the loop opens | A customer note becomes a Jira ticket in the consultancy's tenant, picked up by whoever is on the bench at the next sprint cutoff. | A customer note lands in #fde-engagement Slack or as a tag on the eval-tail dashboard. The named senior engineer is in the same channel. |
| Where the work happens | A branch on the consultancy's internal fork. The client cannot watch the diff because the consultancy's GitHub org is not theirs. | A branch on the client's repo, opened from the engineer's GitHub handle that is in CODEOWNERS. The diff is visible to the client team in real time. |
| What proves the iteration is good | A stakeholder readout. Slides, alignment, change requests. Signal arrives as words in a meeting, not numbers on a workflow run. | rubric_min_score on pilot-gate.yml. A number on a CI run, attached to the PR. If it passes, the merge button lights up. |
| What gets handed back | A zip file or a private GitHub link, plus a Word doc explaining how to apply it. The client team has to integrate, run tests, and decide whether to deploy. | Nothing. The iteration is already on main when the loop closes. There is no package to ship and nothing to integrate. |
| Number of system boundaries crossed per loop | Four. Ticket pickup (tenant A -> tenant B), stakeholder readout (engineering -> business), handoff package (consultancy main -> client review), client integration (review -> client main). | Zero. PR, CI, eval, merge, deploy: one repo, one identity, one CI runner. |
| What blocks the next iteration from starting | Stakeholder availability and the consultancy's bench rotation. The next iteration cannot start until the last handoff package is accepted. | Merge. The next iteration opens a new branch the moment the previous one merges; nothing else is gating. |
| Whose calendar the loop length tracks | The stakeholder review cadence. Iterations land between review meetings, which usually run on a two-week or monthly drumbeat. | The engineer's. The named senior engineer is on the client's standup; iterations land between standups. |
“Zero org boundaries on every FDE iteration; four on every consultant handoff. The number is fixed by the contract layout, not by the engineers' speed. Most arguments about which model is faster are arguments about a number that is already determined.”
PIAS engagement contract layout, applied across five named production agents
When a handoff loop is the right loop
The handoff loop is not always the wrong shape. If the deliverable is a recommendation, a vendor-selection memo, an audit, or a regulator-facing artifact, the consultant loop is the right loop: the boundary crossings are the deliverable. A board memo that stayed inside engineering tooling never made it to the board.
The FDE loop fits when the deliverable is code on main and the bottleneck is senior engineering capacity on a specific shipping deadline. In that case, every boundary crossing is a tax with no offsetting product. The seven-attribute comparison above is the decision rule, not a sales pitch; if four or more rows on the right column do not apply to your engagement, what you have bought is a consultant in an FDE-shaped wrapper, and the loop will run long.
Want the four boundary crossings priced out against your specific agent?
60-minute scoping call with the senior engineer who would own the build. You leave with a one-pager: the agent, the rubric thresholds, the named senior engineer, and the loop diagram for your stack.
The questions buyers ask after the loop diagram lands
Does this just mean FDEs are faster than consultants?
No. It means the loop they run is shorter by structure. A consultancy can throw twice as many engineers at a problem and the loop will still cross four org boundaries per iteration, because that is what 'handoff' literally means: an artifact crosses from one tenant to another. An FDE engagement removes the boundaries because the engineer is on the client's repo and the client's CI is the source of truth. Same iteration count, fewer boundary crossings, smaller loop.
Where does the four-transfer count come from?
From watching the loop unfold on bake-offs. The four transfers are: (1) ticket pickup, when a customer note becomes a Jira row in the consultancy's tenant and sits there until a bench engineer is assigned; (2) stakeholder readout, when the proposed fix is presented in a deck rather than asserted in a PR; (3) handoff package, when the engagement produces a zip + Word doc rather than a merge; (4) client integration, when the client's own engineers re-implement the fix into their repo because the deps and test layout differ. Drop any one of those and the engagement starts to look like an FDE; drop all four and it is one.
Is this still true if the consultancy has commit access to the client repo?
If they have commit access, named seats in CODEOWNERS, and they ship through PRs against the client's CI, they are running the FDE loop and not a consultant loop. The title on their offer letter does not matter. The test is the loop shape, not the firm's name. The reason the title still matters at procurement is that most firms selling FDE-titled work in 2026 do not actually grant commit access on day one; they offer access after a 3-week discovery phase, and during that phase the loop is the consultant loop.
What does this look like in dollars on a real engagement?
We will not invent a number, because the right comparison depends on the project. The structural answer is: a consultant loop pays a fixed boundary tax on every iteration, regardless of project size. A 6-week FDE engagement that runs 30 iterations pays the boundary tax 0 times; a 6-week consultant engagement running the same 30 iterations pays it 120 times (4 transfers x 30). Multiply by whatever your iteration is worth in your business and you have the cost of the handoff. The number that drops out for an enterprise AI engagement is usually large enough to settle the build-vs-buy question.
Does an FDE skip stakeholder review entirely?
No. Stakeholders still review. The difference is when. In an FDE engagement, the stakeholder reviews on top of the green CI run, the merged PR, and the staging behavior the customer can already see. The conversation is 'should we promote this from staging to production', not 'should we approve this proposed approach'. The review still costs calendar time, but it does not gate iteration; it gates promotion. In a consultant engagement, the review gates the iteration, so each iteration sits in the review queue.
What proves the FDE loop is closed inside one system?
Six file paths in the client's repo, none of which exist in a consultant deliverable. rubric.yaml carries the thresholds. .github/workflows/pilot-gate.yml runs the eval on every PR. .github/workflows/production-gate.yml runs on the promotion PR. eval/cases.yaml is the corpus. runbook/<agent>.md is the on-call playbook. flags/<agent>.yaml is the rollout flag. Every iteration of the loop reads and writes those six files; nothing leaves the repo. If a vendor calls themselves an FDE and cannot point to those six files (or their equivalents) on your main, the loop is not closed inside your system.
Why does the loop length fall out of the system layout, not the engineers' habits?
Because the layout decides what the engineers are even allowed to do. If the engineer is not in CODEOWNERS, they cannot merge. If they cannot merge, they cannot make CI the source of truth. If CI is not the source of truth, the source of truth is a meeting. Once the source of truth is a meeting, the loop is bounded by calendar availability, not by build time. The engineers can be the best in the world; the boundary still costs days. Conversely, a junior engineer in CODEOWNERS, with a real eval rubric on a CI gate, runs the short loop because the layout pays them to.
Where does this break down in practice?
Two cases. First, a regulated handoff (eval results going to an external auditor, a regulator, a board) is a real artifact transfer that the FDE loop does not eliminate, only contains. We document the artifact and ship it; the loop is still closed in the repo, but the promotion event has an external dependency. Second, a true vendor-selection or audit deliverable, where the answer is a recommendation rather than a diff, does not benefit from the FDE pattern at all. In those cases the consultant loop is the right loop. The FDE pattern fits when the deliverable is code on main; it does not fit when the deliverable is words on letterhead.
Is this a real thing PIAS measures, or just framing?
It is the contract shape. Every PIAS engagement signs a week-2 numeric refund clause wired to rubric_min_score on pilot-gate.yml, and a week-6 promotion gate wired to seven trailing green nightly runs on production-gate.yml. Both gates read the same six files in the client's repo. If the loop ever crosses an org boundary (we ship a deck instead of a PR, we send a zip instead of a merge), the gates do not fire and the engagement does not collect on the milestone. The mechanics force the loop shape; the framing is the contract reading itself out loud.
Adjacent reading
More on what the FDE engagement contract actually carries
Forward Deployed Engineer vs Consultant: a 7-point operational rubric
The full 7-criteria contract test: where the work product lives, who has commit access, when the first PR ships, what the eval rubric is, how the refund clause works, what you keep, how the model vendor is chosen.
Day 1 commit access in an AI engagement
The hour-by-hour onboarding our named engineer runs on day 1: SSO invite, GitHub write access, signed commits, PR #0 merged before EOD.
FDE Week 2 prototype rubric
The numeric threshold the week-2 refund clause is wired to, and the cron job that pauses the open invoice if the threshold is missed.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.