Campus AI Development Campus practices

09 — Campus practices

Where vibe coding stops on campus

In central IT, student affairs technology and research computing, the question isn’t which approach is best. It’s where each one is acceptable.

Vibe coding is usually limited to
  • Internal experiments and personal productivity tools
  • Early prototypes of student-facing ideas, before any real data
  • Learning and exploration by staff or student developers
Default shifts to agentic-with-review or spec-driven once work touches
  • Student data and FERPA
  • Accessibility (WCAG)
  • Equity impact
  • Identity systems
  • Anything more than one person will maintain

Why structure maps to governance

TraceabilitySpecs, acceptance criteria and decision records create an audit trail that chat history doesn’t.
Equity and biasExplicit non-goals and acceptance criteria make it easier to check for disparate impact before code is generated.
Human oversightMatches the human-in-the-loop principle many institutions are writing into AI policy.
Living documentationSpecs that stay current reduce the “who knows how this works?” problem when staff leave.
Security & complianceConstraints on authentication, PII handling, logging and least privilege are easier to enforce once they’re written down.

By role

Practices by who adopts them

These practices recur in published course reports, research-computing guidance and campus IT programs. They're grouped by who adopts them.

Faculty & instructors

Teaching and learning

  • Tiered AI policies per assignment Mark each assignment as no AI, AI for explanation only, or AI permitted with disclosure, and state the tier in the syllabus.
  • Hint-only course assistants Tutors that coach toward a solution without writing it, available at all hours and grounded in the course materials.
  • Assess the process, not just the artifact Oral code walkthroughs, commit histories, reflection logs and in-class practice without AI.
  • Teach verification explicitly Students write tests for AI output, find seeded bugs and critique the code a model generated.
  • Explain-before-submit Students annotate any AI-generated code in their own words. Code they can’t explain doesn’t earn credit.
Researchers & RSEs

Research computing

  • Vibe-code the prototype, engineer the pipeline Explore an analysis quickly with AI, then rebuild the version you publish with tests and pinned environments.
  • Provenance in the methods section Report which models, versions and prompts helped produce analysis code, as journal policies increasingly require.
  • Reproducibility checks Re-run notebooks from a clean environment, and compare against hand-checked results on a small subset.
  • Keep sensitive data out of public tools Use enterprise or locally hosted models for IRB-governed, export-controlled or human-subjects data.
  • Pair research software engineers with domain experts RSEs review AI-written research code the way statisticians review analysis plans.
Central & distributed IT

Campus IT and administration

  • Licensed, contract-covered tools Negotiate enterprise agreements with data-protection terms that comply with FERPA instead of relying on personal accounts.
  • Sandboxed agent environments Give agents ephemeral environments with scoped, read-only credentials. They never get production access to the student information system.
  • Citizen-developer guardrails Staff who build tools with AI get templates, hosting and a lightweight review before anything touches institutional data.
  • Accessibility as a gate Automated WCAG checks plus testing by people on all AI-built interfaces before launch.
  • Measure delivery, not keystrokes Track lead time, change failure rate and incidents. Don’t use lines of AI-generated code as a metric.

Verification

Testing code nobody fully read

“I tested it and it worked” is weaker evidence with AI. The code may handle only the cases you tried, and the model that wrote it can change underneath you. Security studies show why review has to be deliberate.

  1. 01Test the rule, not the exampleProperty-based tests assert what must always hold, such as “credits never go negative”, across thousands of generated inputs.
  2. 02Scan for generated patternsStatic analysis, secret scanning and dependency checks on every merge. Confirm each suggested package exists and is the one you meant; models invent package names.
  3. 03Pin and re-runRecord model and prompt versions. When either changes, re-run tests and evaluations before trusting old results.
  4. 04Evaluate AI featuresAny feature that calls a model gets a fixed set of graded examples. Track the pass rate over time, not a single demo.
  5. 05Compare against known answersRun old and new versions on the same inputs. For reports, reconcile against a figure someone checked by hand.
  6. 06Review the tests and the reachWhen no one can read every line, review what the tests cover, what permissions the code holds and how much it could break.

Change management

Policy is not adoption

Checklists say what’s allowed. People still need a reason to change, the skill to do it and somewhere to ask. Structured approaches such as ADKAR (awareness, desire, knowledge, ability, reinforcement) apply here as they do to any system rollout.

  1. 01Explain what changes for each roleAwareness and desire: say what a builder, reviewer or manager does differently, and why.
  2. 02Train on real tasksKnowledge and ability: hands-on sessions with campus-licensed tools and the person’s own work, plus office hours.
  3. 03Build communities of practiceReinforcement: regular show-and-tell, a shared channel and recognized builders in each unit.
  4. 04Draw the “for me / for everyone” lineA tool for yourself can be anything. Shared with colleagues: register and review it. For everyone: move it to a supported path.
  5. 05Make access equitableLicense tools for all students and staff, not only technical departments or units with budgets, and offer training that assumes no coding background.

Research software

When the code is part of the science

Research tools carry obligations that ordinary campus software doesn’t: others must be able to trust, reproduce and cite the result.

  1. 01ProvenanceKeep the prompts, model and version, and the AI-generated changes in version control, so it’s clear what the AI contributed and what a person verified.
  2. 02ReproducibilityPin dependencies and model versions, record random seeds and environments, and test results against known cases. A model update shouldn’t silently change findings.
  3. 03Citing AI assistanceDisclose AI use in methods sections and software papers in the form the journal or field expects. Cite the software itself, with a persistent identifier.
  4. 04Funder and journal rulesCheck data management plans, software-sharing and AI-disclosure requirements before you start. Restricted or human-subjects data needs IRB and data-steward sign-off, whatever the approach.

Teaching and student-facing work

Teaching when students build with AI

The role practices above cover course policy. Three questions need more than a syllabus line.

Assessment redesignWeight process evidence (commit history, oral walkthroughs, design notes) alongside the artifact. Keep some assessment AI-free where the skill itself is the outcome.
DisclosureGive students one consistent format: which tool, for what, and what they changed. Ask for it on every assignment that permits AI, not only when they are caught.
Learning outcomesDecide per course whether the outcome is writing code or directing and verifying it. Rewrite outcomes so both students and graders know which.
Student-built agents are their own risk classWhen a student project reads other students’ data, posts to the LMS or calls institutional APIs, it needs staff-level controls: synthetic or sandboxed data, scoped tokens through an approved developer program, a faculty sponsor and an end date.