Dev.to AI 🤖 Ai 👁 0 📖 7 min read

The Role Split Card: A Pairing Session That Assigned Model Work and Server Work Before Any Benchmark

The rule that survived the session A two-hour pairing session left exactly one line in the repository README: the free model writes the patch, the free server runs the process, and a human signs both. Every other propo

The rule that survived the session

A two-hour pairing session left exactly one line in the repository README: the free model writes the patch, the free server runs the process, and a human signs both. Every other proposal from that afternoon was discarded, including two benchmark runs that should never have started. The rule held because it answered a question the benchmarks could not, which is which failure belongs to whom.

The repository was small and unglamorous, holding a webhook receiver, a demo scheduled for Friday, and no deploy pipeline at all. A senior engineer and a mid-level engineer sat down with a free-tier coding assistant reached through MonkeyCode's free model access. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The mid-level engineer wanted model-quality numbers first, and the senior refused to measure anything until each piece of the work had a named owner. The session below is a reconstruction rather than a transcript, and the scripts are templates to run rather than measured results.

Question one: what does this job need that a laptop cannot give?

The first dead end consumed roughly forty minutes of a latency comparison between two assistants on a single code-generation prompt. The numbers looked clean and told the pair nothing, because the real workload was a listener that had to stay reachable through a demo window. A model answering in two seconds instead of four changes nothing when the long-lived process is the thing under test.

The senior's rephrasing moved the session forward by asking for the property the laptop lacks, and the answer arrived immediately. That property is a stable public address plus a process that outlives a closed laptop lid, which is precisely the gap a free server option addresses. It is also entirely separate from which model drafts the handler, and once the split was spoken aloud the benchmark stopped being interesting.

Question two: where does the model's output stop being text?

The second dead end was scope creep through a deploy script, which the assistant offered cheerfully and the junior engineer nearly accepted. The senior's objection was mechanical rather than moral: text that changes infrastructure carries a blast radius a reviewer cannot see in a diff. A workflow file of twenty lines can rewrite permissions, secrets, and the path a release takes to production.

The pair settled on a coarse path rule instead of a case-by-case judgement call. Anything under infra/, deploy/, or .github/workflows/ must be authored by a human, and the assistant may only comment on those files. The rule is checkable in continuous integration, which matters far more than whether the rule is philosophically complete on every edge case.

Question three: what happens the week the offer changes?

Free model access and a free server option are availability claims supplied by the operator, not a contract, and the exact allowance and machine shape were not verified for this article. The senior treated that ambiguity as a design input rather than a reason to skip the experiment. Anything the team built had to keep working on a paid host or a laptop, with the free tier treated as a starting point only.

The practical consequence was that the model choice lives in one environment variable and the host choice lives in one configuration file. Neither identifier appears inside application code, and neither is asserted in a test. If the allowance shrinks or the runtime changes shape, the swap becomes a configuration edit rather than an unplanned refactor across the repository.

Question four: who signs the diff?

The last question produced the artifact the team actually kept, and it is a card rather than a document. Each task carries four yes or no flags, and those flags decide whether work may leave the laptop, whether the model may touch it, or whether a human must own it outright.

Task Flags that matter Owner Hard veto
Handler inside app/ short runtime, no secret free model drafts, human reviews none
Webhook listener for the demo public URL, runtime over one hour free server runs it no persistent state without a plan
Deploy or workflow change changes infrastructure human only model output is a proposal
Secret rotation or token wiring holds a long-lived secret human only never paste values into a prompt
Prompt and model selection churn expected human only keep it in one variable

The check the team runs before any prompt

The script below is a template rather than a product integration, and it contains no vendor-specific commands. It reads a small task file and prints a verdict, which makes the card executable instead of aspirational.

#!/usr/bin/env bash
# split_check.sh - decides whether a task may leave the laptop.
set -euo pipefail

task_file="${1:?usage: split_check.sh tasks/webhook.task}"
get() { grep -E "^${1}=" "$task_file" | head -n1 | cut -d= -f2- ; }

name="$(get name)"
public_url="$(get needs_public_url)"
runtime="$(get worst_case_runtime_hours)"
secret="$(get holds_long_lived_secret)"
infra="$(get changes_infra)"
state="$(get needs_persistent_state)"

verdict="server"; reasons=()
if [[ "$infra" == "yes" ]]; then
  verdict="human"; reasons+=("changes infrastructure: model output is a proposal only")
fi
if [[ "$secret" == "yes" ]]; then
  verdict="human"; reasons+=("holds a long-lived secret: never paste values into a prompt")
fi
if [[ "$public_url" == "no" && "$runtime" -lt 1 && "$state" == "no" ]]; then
  verdict="laptop"; reasons+=("no public URL, short runtime, no persistent state")
fi
if [[ "${#reasons[@]}" -eq 0 ]]; then
  reasons+=("public URL, long runtime, or persistent state")
fi

printf 'task:    %s\n' "$name"
printf 'verdict: %s\n' "$verdict"
for r in "${reasons[@]}"; do printf '  - %s\n' "$r"; done

A task file for the demo listener looks like the listing below, and those same six lines are what the reviewer reads in the pull request.

name=webhook-receiver-demo
needs_public_url=yes
worst_case_runtime_hours=8
holds_long_lived_secret=no
changes_infra=no
needs_persistent_state=no

A second check runs in continuous integration and enforces the path rule that question two produced. It fails closed, so a generated workflow file cannot reach main without a human author attached to the commit that carries it.

changed="$(git diff --name-only origin/main...HEAD)"
if printf '%s\n' "$changed" | grep -qE '^(infra/|deploy/|\.github/workflows/)'; then
  echo "blocked: infrastructure paths must be authored by a human" >&2
  exit 1
fi

The session, in the order it happened

  1. Write the task file before opening any assistant, because arguing about flags costs less than arguing about a finished diff.
  2. Run split_check.sh tasks/webhook.task and accept the verdict, even when the verdict is "laptop" and no server is needed.
  3. Ask the free model for the handler only, with the file path and the task file as context, and reject any suggestion outside app/.
  4. Run the handler locally against a recorded payload, then confirm how it fails when the receiver is unreachable.
  5. Move the process to the free server option, keep the model variable unchanged, and record the public address in the task file.
  6. Attach the task file, the verdict, and the CI output to the pull request so reviewers see ownership instead of a narrative.

Limits and who should skip this

The approach fits teams exploring low-cost tooling on internal or demo workloads, and it fits reviewers who prefer checkable rules over taste. It does not fit anything carrying an availability commitment, since a free tier comes with no service level and can change without notice. It also does not fit regulated data, because prompts leave the repository and the flags cannot express a compliance boundary.

Teams that need a model to touch infrastructure should not adopt the card, because the card assumes a CI guard that blocks those paths. Anyone expecting the free server to preserve state across restarts should test that assumption directly rather than trusting a table. The expected benefit is a shorter review conversation about ownership, which is a modest expectation and not a measured result.

What the card actually changed

The rule kept two things separate that usually get tangled: drafting code is a model task, and staying reachable is a host task. The model kept writing handlers, the free server kept running the listener, and the human kept the two files that could break the demo. Starting from the split instead of the benchmark saved the pair an afternoon of numbers nobody would act on.

Readers who want to try the split on their own workload can start with the free model access and the free server option, and should read the current terms before depending on either.

Tags: model work, server work, ownership, reviewable rules.

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.