A sandbox for one person
- Campus-licensed account, not a personal one
- Public or synthetic data only
- No production credentials
- Throw away or promote
8.1 — Capacity to experiment
Most good ideas start as one person’s experiment. The institution decides whether it happens somewhere safe, with the right skills and partners nearby.
Competencies
Effort moves from writing code to deciding what to build and checking it. This builds on the skills table; the right-hand column says where each skill matters most.
| Competency | What it looks like | Matters most for |
|---|---|---|
| Writing specs and acceptance criteria | What it does, what it doesn’t, how you’ll know it works, written before the agent starts | Functional analysts, enterprise teams, platform makers |
| Designing verification when not every line is read | Tests from the spec, protected test files, and diff review for what was removed as well as added. Spec-driven | Enterprise teams, research software engineers |
| Scoping agents | Permissions, context, budgets and stop conditions set before a run | Platform makers, IT, anyone running agents |
| Reviewing AI output critically | If you can’t explain it, don’t ship it | Everyone; faculty teaching it |
| Knowing the data | Its classification, authoritative source and steward | Business users, analysts, researchers |
| Knowing when not to use an agent | High stakes, unfamiliar systems, regulated data or no way to check the result | Everyone |
Environments
Three tracks, each with its own data rules. Moving between them is the promotion step.
Tools
People use personal accounts when the approved path is slower. These four things remove most reasons to work around it.
Over-governing has its own cost; see proportionality and the shadow tool case.
Patterns
None of these needs a new office. Each puts domain knowledge and technical judgment in the same room.
The person who knows the work builds; IT or a platform team supplies the environment, credentials, integration and review.
Builders across units share specs, prompts, guardrails and mistakes. It also shows where tools overlap before they multiply.
A second person reviews diffs, tests and data access before others use the tool, scaled to the tier. A research software engineer plays this role for research code.
On campus
Emerson’s shared environment and doctrine
At Emerson, the people building knew the operations; none needed to be programmers. IT leadership supplied a shared approach: a written development plan, the “doctrine,” fed into every AI session, with architecture decisions recorded back into it, and a schema designed before features.
That combination let seven systems reach production. Read the case
Next: when a pilot turns into something others rely on, see scaling to production.