Trust, Verification, and Research Integrity

Everything else in this track makes you faster; this unit decides whether the fast version survives peer review. An agent will hand you plausible work at a rate no human collaborator ever has, and plausible is precisely the quality that slips past a tired reviewer and detonates after publication. Verification is the difference between using these tools and being used by them.

• Review an agent's implementation plan and reject it before it touches your code.
• Read a diff you did not write and say what it changed and what it risked.
• Keep credentials out of prompts, repositories, and context files.
• Write a disclosure statement appropriate to coursework, a thesis, and a submission.
• Identify data that cannot go to a cloud model at all, and say what you run instead.

Google Antigravity — an AI-first VS Code built on the Windsurf codebase. Your existing extensions, themes, and keybindings carry over on first launch. The difference is the Agent Manager: instead of suggesting the next line, it deploys autonomous agents that plan, write code, run terminal commands, and test in a built-in browser. Up to five agents in parallel on different parts of a project.

Before an agent touches your code it produces three artifacts — the Trust Layer:

• Implementation Plan — a pre-flight review describing architectural choices, files to be modified, and the validation strategy. Review this before saying go.
• Task List — a live checklist of concrete steps. Watch it during execution to catch scope drift early.
• Walkthrough — a post-flight summary of all changes including screenshots, test logs, and a video recording. Effectively release notes for peer review.

The structure means you act as the architect rather than the typist. It is also an early preview: agent loops, unpredictable crashes, and high cognitive overhead from supervising several agents are all common. Keep your regular editor for daily work and use Antigravity for prototyping and exploration — not for anything on a deadline.

Reproducibility

An agent in your pipeline is a non-deterministic component, and a non-deterministic component in a published result is a reproducibility problem. The minimum:

• Pin every dependency. Seed every random process. Capture the environment.
• Log the model version and the exact prompt alongside the result — a model updated underneath you is an unlogged change to your method.
• Checkpoint to Drive, because Colab's disk resets between sessions.
• Commit the context file with the code. It is part of how the result was produced.

Data you cannot upload

@Drive grounding means Google reads the file. For some research data that is not a tradeoff, it is a violation:

• Human-subjects data under an IRB protocol that does not permit third-party processing.
• Embargoed or pre-publication datasets you do not own outright.
• Student records under FERPA.
• Anything under an industry NDA or a data use agreement.

§6.5 (Data privacy: when local models are non-negotiable) is the curriculum's treatment, and for this category it reads as a compliance requirement rather than a preference. /stacks/local-agents-nvidia is what the alternative looks like in practice.

Antigravity's Trust Layer is §6.1's verification habit after a product designer got to it: plan review before, task list during, walkthrough after. Learn the habit and every future tool's version of this is familiar on sight; learn the UI and you are a beginner again at the next rebrand.

Part 6 is six sections and the densest part of the curriculum for this audience: §6.1 (Reading code you didn't write), §6.2 (Git discipline for AI-generated code), §6.3 (Testing without being a tester), §6.4 (Secrets, API keys, and what NOT to put in a prompt), §6.5 (Data privacy), §6.6 (The deployment cliff).

For disclosure and citation norms, see /academic/disclosure.

1. Give Antigravity a real task in a throwaway repository. When the Implementation Plan appears, read it and reject it — change something about the approach before approving.
2. Watch the Task List while it runs. Note the first step that drifts from what you asked for.
3. Read the Walkthrough end to end. Ask whether it is sufficient for a peer reviewer who was not watching.
4. Now read the diff yourself, without the summary. Name what changed and what it risked.
5. Audit a repository you already have for committed secrets — API keys, tokens, connection strings, and anything pasted into a context file.
6. Pin your dependencies, set your seeds, and record the model version and prompt alongside one existing result. Re-run it and confirm you get the same answer.
7. Inventory your research data and sort it into two piles: can go to a cloud model, cannot. For the second pile, write down what you would run locally instead.

A disclosure statement for a current assignment, a repository that passes a secrets audit, and a two-column inventory of your research data with the local alternative named for anything in the second column.

• The Implementation Plan looked fine and the Walkthrough says all tests pass. What have you still not verified?
• Your result came from a model that was updated last week. What in your logs lets you reproduce the original?
• Which of your current datasets would be a protocol violation to put in a @Drive folder?
• You pasted a connection string into a prompt six weeks ago. What is the remediation, and what is the timeline?