Jose worked this out in a voice conversation while driving, hands on the wheel, phone propped in the cupholder on speaker. He’s spent time with a range of agentic coding tools, but his team’s upcoming rollout is specifically built around GitHub Copilot — a decision made above his pay grade, by the client. What’s occupied his thinking instead is architecture and process: what structure keeps a team from lighting a client’s money on fire, whether that’s the classic vibe-coding blunder of an agent burning through tokens furiously and confidently to produce a pile of code nobody asked for or verified, or the quieter waste of routing routine work — parsing a JSON file, say — through an expensive frontier model when a script would do the job for a fraction of the cost. He’d been circling pieces of an answer for a while: environment setup for the team’s incoming laptops (shell scripts, already mostly sorted), scaffolding, verification, how to bring a team along. This conversation was where he tried to say how they all fit together, partly to find the gaps and rough edges before committing to them. Below is the framework that came out of it.
Two Tracks, Run in Parallel
Rather than one long document to read and internalize, the plan splits into two tracks that reinforce each other:
- Machine scaffolding — markdown process files and agent skill definitions that agents read directly during actual work. This is the precise, executable version of “how we do things here.”
- Human upskilling — short weekly reading (articles or videos) paired with concept discussion during the team’s existing technical meeting, timed to land just ahead of whichever scaffolding piece is coming next. The idea is that a concept should exist in people’s heads before the artifact that encodes it shows up.
Neither track substitutes for the other. The scaffolding alone doesn’t build understanding, and understanding alone doesn’t produce something an agent can actually follow.
The Five Architectural Pieces
The scaffolding itself organizes around five pieces:
- Context and state management — work state persists in files (task lists, notes, process docs) rather than living entirely inside a single long conversation.
- Process specification layer — the written procedures agents follow, encoded as skill files rather than left implicit.
- Oracle layer — verification that doesn’t depend on the agent’s own account of its work. For a team whose product is a test suite rather than application code, this includes writing acceptance criteria before implementation (a spike produces the test cases, not just a summary) and finding ways to verify that a test would actually catch a real failure, not just that it exists and passes.
- Review and gating layer — a checkpoint, human or otherwise, before work is accepted, treating confident-looking output as something to verify rather than something to trust by default.
- Task decomposition — breaking work into pieces small enough that the other four pieces can function at all; oversized tasks make oracles vague, process docs hard to apply, and review superficial.
Together these form a loop: work gets sized appropriately, an agent executes against a written spec while keeping state in files, output is checked against an oracle independent of the agent, and a review gate makes the final call before anything is accepted.
Distributing Ownership Within a Fixed Shape
The team lead sets the architecture — the five pieces above, and the constraints each one must satisfy. Within that fixed shape, individual pieces get assigned out to be built and refined by different engineers, each with real latitude to optimize their piece. The architecture stays constant; the implementation of any given piece is free to compete and improve.
This does two things at once: it gives people a genuine design surface to work in rather than a checklist to follow, and it keeps the overall system from drifting into as many different directions as there are engineers on the team.
The Underlying Bet
The framework rests on one claim: an agent that can write code quickly doesn’t reduce the value of engineering judgment, it raises the price of not having any. As Jose put it, any Yahoo with a keyboard can tell an agent to build something. Producing something that still works months later requires understanding how the pieces of a system actually relate to each other — which is exactly what the oracle layer, the review gate, and the process specs are built to make explicit and shareable, rather than left as tacit knowledge in one person’s head.
The oracle layer in particular is the part with the least established precedent — mutation testing and acceptance-test-driven development are well-trodden ground for teams that own application code, but a team whose product is the test suite itself doesn’t have a name-brand methodology to borrow yet. That piece, along with the reading curriculum, is where Jose still has real work ahead: not filling in a template, but working out solutions to problems that don’t have an established playbook. The shape of the larger problem is set, though: not which tool to use, but which structure lets a team use it well together, even in the parts still being invented.