# An AI4SE Workshop Is Not a Training Class: Staffing, Cadence, and Funnel Convergence

The most common way an AI4SE workshop goes wrong usually has nothing to do with the model not being strong enough — it’s that the setup itself was wrong.

The first failure mode: treating “having heard of Copilot” as “knowing how to use AI,” leaving a whole week spent teaching keyboard shortcuts. The second: no real project, so product, dev, and QA each practice tools in a vacuum, and opportunity areas never leave the slide deck. The third: every role turns in a “perfect answer for my own job,” but strung together the pipeline still doesn’t work end to end — everyone celebrates a local optimum while the end-to-end flow stays stuck.

What a workshop should buy isn’t training hours. It buys this: on a real project, having end-to-end roles converge AI opportunity areas into an executable playbook. Staffing, cadence, and process discipline — none of them are optional. This article gives directly actionable design strategy across these three areas; for the organizational-level pilot framework, see AI4SE Pilot Transformation for Mid-to-Large R&D Organizations.

Part One: How to Staff the Workshop

If you get the people wrong, no amount of polish on cadence or convergence will save you. Staffing comes down to three rules.

1. Prioritize High-Frequency AI Users

A workshop is for exploration and decision-making, not teaching prompting from scratch. Prioritize people who already use various AI tools day-to-day at high frequency — writing code, writing specs, reviewing, testing, documenting — it doesn’t matter which stage, the key is that it’s become muscle memory.

Putting someone who’s just opened ChatGPT for the first time into an AI4SE workshop is like putting someone who just learned to ride a bike into the Tour de France — not that they can’t learn, just that it’s the wrong setting. Run onboarding training separately; reserve workshop seats for people who can immediately enter a state of human-AI co-creation.

2. Use One Real Project to Align End-to-End Roles

The best approach is to pick one specific project and align roles along the end-to-end delivery chain: product/BA, development, QA, architecture (add ops or security as needed). Opportunity areas are usually stuck at the seams between roles, not stuck in some particular IDE plugin.

A workshop without a real project easily turns into a “tool expo”: everyone feels they learned a lot, but goes home not knowing which pipeline to change first thing Monday. The project is the anchor; the roles are the load-bearing structure.

3. Ideally, the Project Covers Software 1.0 / 2.0 / 3.0 Simultaneously

Here we use Andrej Karpathy’s well-known framing:

Type	Meaning	Why it matters in a workshop
Software 1.0	Human-written rules and deterministic code	AI mostly accelerates implementation, refactoring, testing; acceptance boundaries are clear
Software 2.0	Model behavior trained from data	Opportunity areas lie in data, evaluation, drift, and human-machine boundaries; “correct code” isn’t the same as “a usable model”
Software 3.0	Software driven by natural language / agent orchestration	Opportunity areas lie in specs, tool permissions, Harness, and observability; failure modes are entirely different

The AI entry points, risks, and acceptance criteria differ vastly across these three types. Having them all in the room at once is what forces a “full-stack optimum” instead of a “best-for-the-dev-role optimum.” Organizations can map modules to their own context, but at intake, try to make sure all three have a representative path — otherwise the resulting playbook will be lopsided.

At intake, it’s worth sketching a simple matrix: people × end-to-end role × the primary software type they touch. The matrix doesn’t need to be pretty — the gaps being obvious is already valuable.

Part Two: How to Structure the Weekly and Daily Workshop

Cadence isn’t about “locking people in a conference room” — it’s using a fixed rhythm to compress exploration into decidable progress.

1. Weekly Kickoff: Only Attack a Few Core Opportunity Areas This Week

Align on three things at the start of the week: this week’s opportunity-area list, success criteria, and the level of granularity you’re converging to this week. Take on too many opportunity areas, and everyone ends up “busily exploring,” but Friday still produces nothing that can be strung into the playbook.

A kickoff’s output isn’t a morale slogan — it’s a weekly convergence contract: which hypotheses will be validated, which approaches will be written into documentation, and which paths are explicitly abandoned this week.

2. Daily Standups: Use ORID, Not the Traditional Three Scrum Questions

Traditional standups are good at reporting progress; an AI4SE workshop needs to draw out learning and decisions instead. Use a daily ORID log for reflection:

Step	Meaning	Typical questions
Objective	What actually happened	What tools were used? What experiments/docs were produced?
Reflective	Feelings and sticking points	What went smoothly? What felt awkward when collaborating with AI?
Interpretive	What this means	Which hypothesis held up / got disproved? How did the opportunity area’s boundary shift?
Decisional	What we’re deciding today	What goes into the proposal doc? What will we validate today?

You can either do the full ORID review at day’s end, or spend five minutes each morning aligning on the day’s Decision. Form serves decisions — don’t let ORID become just another status-report template.

3. Consultants First Introduce the Minimum Shared Context and Industry Practice

Each day, around that day’s opportunity area, the consultant delivers a short, on-demand, immediately usable introduction: the minimum shared understanding needed, and what the industry is currently doing. This is a spark, not a half-day training session.

What learners need is “context they can use to make a decision today,” not “the consultant’s complete body of knowledge on tour.” Teach up to the point where people can act — anything beyond that goes into an appendix or on-demand Q&A.

4. Guide Learners to Brainstorm Solutions Directly With AI Tools

Right after the shared context, get hands-on immediately: humans + AI together break down approaches, compare paths, and record decisions. The consultant’s job is to ask questions, clarify boundaries, and push things into documentation — not to click “generate” on behalf of the learner.

A good daily rhythm:

Time slot	Activity
Short	Shared context + industry practice intro
Main	AI brainstorming to explore opportunity-area solutions
Middle	Pair discussion, comparison, writing back to docs
End	ORID wrap-up, lock in the day’s decisions

Part Three: Seven Disciplines During the Workshop

The quality of a workshop doesn’t depend on “how much was taught” — it depends on whether decisions got captured, whether convergence actually happened, and whether the optimum found is full-stack rather than local.

1. The Coach Facilitates, Doesn’t Train

The default posture is facilitation: asking questions, clarifying, pushing toward decisions. Training happens on demand — when someone is blocked on a specific critical tool capability, deliver the minimum necessary intervention. Once a consultant starts talking, they tend not to stop, and learners easily slip into being “note-taking spectators” — spectators don’t leave with a playbook.

2. Group People, and Pair Within Each Group

Grouping enables parallel exploration; pairing within a group fully absorbs the spirit of pair programming: one person drives the AI and the implementation path, the other watches the goal, constraints, and quality, with roles rotating. Going solo against an agent feels great, but without a second pair of eyes, the proposal doc is left exposed to the “it felt right at the time” illusion.

3. Funnel-Style, Layered Convergence: Pair → Group → Plenary

The funnel isn’t some abstract “from inspiration to best practice” — it’s narrowing layer by layer through organizational units: let pairs within each group diverge fully first, then converge into a group-level proposal, then converge each group’s already-converged content one more time into a single final version. Every layer has a clear input, output, and an explicit “what we’re discarding.”

Level	Who’s present	Activity	Output
L1 · Pair divergence	Pairs within a group	Boldly explore paths, hypotheses, and counterexamples using AI brainstorming; disagreement is allowed to coexist	Each pair’s opportunity-area exploration draft (with decision records)
L2 · Group convergence	Multiple pairs within the same group	Compare, debate, merge; keep validated paths, cut duplication and wishful thinking	Group-level opportunity-area proposal
L3 · Plenary convergence	All groups + consultants + key roles	Compare and weigh group-level proposals, merge into one	Finalized opportunity area (which then feeds into the playbook)

All three layers matter:

• Pair divergence without group convergence → a bunch of parallel universes, with nobody in the group able to say what they actually stand for.
• Group convergence without plenary convergence → each group goes its own way, and Friday produces N “all correct” documents that can’t be strung into one path.
• Jumping straight to plenary convergence, skipping pair divergence → looks efficient, but really just legitimizes whoever spoke loudest.

The consultant’s job within the funnel isn’t to write conclusions for everyone — it’s to protect the layering: don’t rush to a vote when it’s time to diverge, and don’t keep adding drama when it’s time to converge. At the end of each layer, ask: what did this layer keep, what did it discard, and did the reasoning get written down?

Without a funnel, a workshop is an idea bazaar; with a funnel, you actually earn the right to call something a “best practice.”

4. Decisions Must Be Persisted to the Opportunity-Area Proposal Document

Key decisions from human-AI brainstorming and consensus reached between people must be written back into the opportunity-area proposal document — and this has to follow the funnel’s layering: pair drafts, group-level proposals, and the plenary final version each retain their own layer’s decisions, avoiding “losing the reasoning during convergence.” Chat logs disappear; the document is the source of truth.

This discipline drives two things at once: decision-oriented interaction between humans and the agent, and debate between people. Arguments can get heated, but the conclusions of the argument have to land on paper. Otherwise, all you have on Friday is a pile of screenshots and “we discussed this.”

5. Weighted Analysis + Dedicated Proposals From Key Roles

Plenary convergence (L3) is not a simple vote. The consultant needs to identify representative team members across end-to-end roles and perform a weighted analysis on each pair’s / group’s output document: whose constraints are harder, whose acceptance criteria are more real, whose path is more implementable. At the same time, key end-to-end roles in the workshop should still be invited to produce a dedicated opportunity-area proposal for each opportunity area.

Pair- and group-level documents are the raw material for the funnel; the key-role final draft is the accountability anchor before the final version. Both are needed — otherwise you end up with either a lively but unaccountable draft, or an authoritative but untested single-sided proposal.

6. All Opportunity-Area Proposals Ultimately Chain Into a Complete Playbook

Scattered opportunity-area proposals aren’t the end goal. The workshop’s key output is a single end-to-end playbook that strings the opportunity areas together: who does what at which stage, with what spec and tools, how it’s verified, and how it’s written back into assets.

For engineering leaders, judge the workshop by the playbook, not just by a satisfaction survey. A survey measures the experience; a playbook measures whether it’s something people can actually take away and use.

7. Optimize Globally, Not Locally — Treat Both People and Agents as Full-Stack Generalists

Always ask: is this a full-stack optimum, or a per-role optimum? If dev speeds up but testing gets worse, specs get vaguer, and releases get riskier, that’s not an AI4SE success — that’s just moving the bottleneck. For the end-to-end best-practices view, see AI4SE End-to-End Software Delivery Best Practices.

An even more important point: don’t design opportunity areas around “best practices for dev / best practices for QA / best practices for BA.” Role boundaries are a convenience of organizational division of labor, not the coordinate system for optimizing the AI era. What a workshop should pursue is the global optimum of the end-to-end chain — not translating old job descriptions into a set of mutually incompatible AI tricks per role.

This means two “generalist” assumptions need to hold at once:

Subject	Generalist assumption	Practical implication
People	Participants collaborate as full-stack generalists, rather than sticking to their own role’s script	Product can touch acceptance and risk, dev can touch spec and testability, QA can touch implementation paths and release constraints — everyone shares accountability for the end-to-end outcome around the opportunity area
Agent	Treat the agent as a generalist collaborator, not a role-specific plugin	The same agent chain can span spec, implementation, verification, documentation, and feedback — don’t invent “BA-Agent / DEV-Agent / QA-Agent” and optimize each separately, only to find the interfaces don’t line up

At intake, you still need representative end-to-end roles in the room (otherwise constraints and acceptance criteria will be distorted); but when designing the optimization, downplay the role walls: an opportunity-area proposal should describe “how this chain gets faster, more stable, more verifiable” — not “how this particular role gets a better experience.”

One-line comparison:

• Local optimization: customize a toolchain and playbook for one specific role — the role’s KPIs look great, but the handoffs are still just as clogged.
• Global optimization: treat both people and agents as generalists, and improve the end-to-end chain together; roles contribute perspective and veto power, not a fenced-off territory that doesn’t talk to anyone else.

A local optimum is worth celebrating; only a full-stack optimum is worth writing into your rollout checklist.

Three Sentences for Engineering Leaders

1. A workshop doesn’t buy training hours — it buys a verifiable path built from “end-to-end roles + a real project.”
2. Judge it by the playbook, not by a learner satisfaction survey.
3. A local optimum is worth celebrating; only a full-stack optimum is worth rolling out — make both people and agents generalists, optimize end to end, not just one role.

---

One-line summary: staff the right people, lock onto the opportunity areas, use ORID to force decisions, and converge into a playbook through a Pair → Group → Plenary funnel — so that consensus, both between human and agent and between people, all lands in the same document.

Related Reading

• AI4SE Pilot Transformation for Mid-to-Large R&D Organizations
• AI4SE End-to-End Software Delivery Best Practices
• The Next-Step Dojo: An Airborne Kata for the AI Era