Teach OpenCode as a four-stage cohort lab, not a lecture: plan first, verify everything, delegate last

Asked (summary):

How can I efficiently help software engineers at work get started with agentic development, explicitly with OpenCode — workshops, exercises, proven learning methods, and feedback about what works?

This report draws on 44 rows scanned from live web results on 2026-09-15: 20 OpenCode-specific exercises and workflows (10 from official OpenCode documentation, 10 from practitioner reports on GitHub and Reddit) and 24 empirical studies on learning, verification, productivity and collaboration with coding agents. Direct controlled evidence for teaching OpenCode itself is still sparse; most studies evaluate coding agents in general, so OpenCode-specific guidance is badged separately from broader evidence throughout.

The progressive learning pathway

20 exercises from the rows, arranged from fundamentals to guarded autonomy. Hover or tap a node for the exercise, its benefit and its failure mode. Duplicate @-reference and agent-creation concepts are grouped side by side; every source row remains in the table below.

Official OpenCode guidance Practitioner feedback or workshop documented failure mode attached

Tap or hover a node

Each node is one selected exercise: what to practice, why, and how it fails.

What the evidence adds that the pathway cannot

One adaptive 60-minute Prompt Coach session lifted 15 professional developers’ prompt-quality scores 13.73% (63.04 → 71.69, p<.001), with the biggest gains in constraints, error handling and context awareness — short focused instruction works. arxiv.org

A progressive 10-module curriculum for a comparable agentic tool raised 27 professional engineers’ self-efficacy +0.84 on a 5-point scale (2.97 → 3.81, p<.001) — but it was self-report with no control group, so measure real task performance locally. arxiv.org

Pairing two humans with one agent cut the share of AI-generated code from 23.1% to 1.4% while raising collaborative learning and accountability — run labs in pairs, never in isolation. dl.acm.org

Agents improved task completion for 54 students but substantially harmed code comprehension — require explain-back review before any merge. arxiv.org

Evidence matrix: 24 studies, ordered by applicability to training professional engineers

Strength A = randomized, controlled or pre-registered; B = sizable observational or pre/post; C = small, qualitative or self-report. None of these studies evaluated OpenCode directly.

Strength

Theme

Finding and headline number

Source

Measure outcomes, not perceived speed

Perception is unreliable: 84% of longitudinal participants reported productivity gains while worsened developer experience nearly doubled (14% → 27%), and perceived gains do not always match objective completion times. Track these instead, split by task type and experience, with no adoption quota:

Accepted-task lead time — baseline each engineer once without OpenCode, or against recent normal performance, before the capstone.
First-pass test rate — share of agent changes whose tests pass without rework.
Escaped defects and rework — late-stage hotfixes, rollbacks and churn (the Spec Kit field study saw feature lead time drop from 8–12 to 6–9 working days under specification governance).
Review time and agent iterations — how many loops before acceptance.
Cost and tokens — practitioners report single tasks burning $5 in tokens and mode auto-toggle bugs exhausting whole budgets.
Comprehension check — a short explain-back on merged code, since agents demonstrably harm understanding.

Facilitator checklist

Kickoff, 90 min Pairs install OpenCode, run /init, improve AGENTS.md, use @ references, ask the agent to explain unfamiliar code, then Plan → human review → Build on one tiny well-tested change.
Lab 1 Context and specification: derive concise project rules from the top three recurring corrections; keep instruction files brief and genuinely shared.
Lab 2 Verification: seeded-bug and criticize-the-agent exercises (teachable-agent debugging improved novice performance 12% and efficiency 14%); test-driven acceptance of agent diffs.
Lab 3 Bounded delegation: least-privilege permission rules, one review subagent, optionally one MCP server — and stop there; over-split setups create reasoning gaps and redundancy, and MCP tools consume context fast.
Capstone Bring-your-own-project: one genuine bounded issue, baseline first, then OpenCode with tests, diff review, dependency checks and a short decision log. Demo failures as well as successes.
Follow-through 3–4 weeks of rotating driver/reviewer pairs with prompts visible, reviewer explains the code before merge, office hours, and a shared prompt-and-failure cookbook.

All 20 source exercises

Stage	Type	Exercise	Failure mode	Source

Method: 44 rows scanned from live web results on 2026-09-15 — 20 OpenCode exercises (official docs, GitHub, Reddit) and 24 empirical studies (arXiv, ACM, Microsoft Research and others). Stage placement and evidence-strength grades (A/B/C) are editorial judgments over the rows; quantitative results are quoted as published, most from preprints or small samples whose caveats are shown. Long exercise and caveat texts were shortened for space; every row links its own source. Practitioner anecdotes are signals, not proof.

This report was generated automatically by Keenable SELECT at a user's request, from publicly available web sources linked herein. Keenable does not review, verify, or endorse its contents and makes no representation as to accuracy, completeness, or timeliness; AI-based extraction may contain errors. Nothing in this report is investment, legal, financial, or other professional advice. All trademarks and referenced content remain the property of their respective owners; no affiliation or endorsement is implied. To report an error, rights concern, or request removal: legal@keenable.ai.