Choosing an AI Development Approach

Campus AI Development Choosing an approach

06 — Choosing an approach

Match the approach to the stakes

Pick the option that fits your project for each factor. The strictest answer sets the approach: one high-stakes factor is enough to call for spec-driven work.

Stakes

Lifespan

Team size

Audit and traceability

Requirements clarity

Risk of silent drift

Recommended approach · Six factors · the strictest answer wins

Driven by: {{ resultDrivers }}

Pick one option per factor

The recommendation updates as you go and is saved on this device.

Minimum controls

Time to first result{{ resultTime }}

Best for{{ resultBest }}

Choose per task, not per project: a quick UI experiment inside a governed system can still be vibe-coded, while a change to a data contract needs a spec (Sarigoz, 2026). Score the project again when it gains users, connects to new data, or outlives its original purpose. Prototypes tend to become production systems without anyone noticing.

Rules of thumb

Quick tests when you’re unsure

Practitioner guides from 2025–26 broadly agree: the choice isn’t global. Pick the level of structure per task or feature.

01The two-sentence ticketIf you’d write a ticket longer than two sentences for a human colleague, write a spec for the agent. If you’d happily throw the result away on Friday, vibe-code it.
02Outlives the afternoonIf the code will outlive the session you wrote it in, start with at least a light spec.
03Cost of being wrongChoose by what happens if the result is wrong, not by what sounds most advanced.
04Explore, then formalizeVibe-code a throwaway spike to understand the problem, then turn what you learned into a spec before building for real.

The hybrid pattern most guides recommend

1 →ExploreVibe-code a throwaway spike to surface the problem and options.
2 →SpecifyWrite down what you learned: requirements, acceptance criteria, non-goals, constraints.
3 ShipAgents plan, task and build against the spec, with human review gates.

The spike is research that sharpens the spec. The failure mode is shipping the spike itself, where AI-generated code that nobody owns becomes hard to change safely within months. The Lifecycle page follows this path in detail.

Synthesized from Sarigoz, 2026; Augment Code, 2026; Tyagi, 2026; 10xTeam, 2026.

Solo vs. team

Team size matters as much as the band

Most controls exist to coordinate people. A solo builder can skip some; a team can’t. Each approach page notes how it works for one person and for a team.

What changes	One person	A team
Shared context	Kept in your head.	Written down: conventions files, specs, decision records. Otherwise every AI session starts from scratch.
Review	Self-review, the weakest check.	A second person, the cheapest real check there is.
Conflicts	None.	Fast agents produce overlapping changes, so you need small tasks, protected branches and automated tests sooner.
Continuity	The tool dies when the builder leaves.	A second maintainer makes it durable.

Once a second person relies on a tool, it needs a second person who can maintain it.

Most AI development on campus is solo: a researcher, a faculty member, an analyst in a business office. The main risk is continuity more than code quality. Meeting this rule usually means moving up a band, to a written spec or a reviewed repository someone else can take over.

Check, measure and move

Is the approach still the right one?

A choice made at the start isn’t permanent. Check three things the stakes alone can miss, then watch for signals that a project should move along the continuum.

Weigh alongside the stakes

01Accessibility and equityAnything students or staff must use falls under ADA Title II, Section 504 and WCAG 2.1 AA. Ask who could be shut out or treated differently by the tool, not only whether it passes a checker.
02LearningWhen students build, or a tool touches assessment, ask what skill the work is meant to develop and whether the approach still exercises it. Set disclosure and integrity expectations before the work starts.
03Cost over timeCount token and API spend, who will maintain it and what happens when the builder leaves. Count the cost of over-caution too: backlogs and workarounds.

Signals to move a project

Promote: add structure

Others start relying on it, or its audience grows
It begins touching more sensitive data
Changes keep breaking things, or take longer each time
An audit finding, incident or user complaint
The builder is leaving and nobody else understands it

Demote: remove friction

The scope shrank, or the data was swapped for public or synthetic data
It’s a prototype that will be thrown away
Review overhead outweighs the risk it controls
People are working around the process

Simple measures

Error and defect rates after release
Time to make a safe change
Audit and review findings
User reports and accessibility complaints
Spend against budget

Review them at a set point, such as each term or each major release. For institutional initiatives, report them alongside the Strategic Compass outputs, outcomes and efficacy measures, and use its Reflect step to decide whether to scale, change or stop. How the two fit

From questions to the chooser

Each factor is one of the six questions

The chooser and the scenario framework ask the same things in two forms. Answer a scenario’s questions first; the answers set the chooser’s factors. See how it fits together.

Chooser factor	Question	What it asks
Stakes	Audience	Who relies on it, and what happens if it’s wrong
Lifespan	Lifespan	How long it lives and who maintains it
Team size	Accountability	Who owns it, approves it and discloses it
Audit and traceability	Data	What it touches and how that data is classified
Requirements clarity	Verification	How you’ll know it’s right, and keep knowing
Risk of silent drift	Reach	What it can read, write or break