AIDA Labs · How we build · 1 of 2

AI speeds up the building, and stays out of the dangerous places

AI helps design, write, test and document. It never gets unsupervised access to production data or infrastructure. Where a product runs AI at all, it runs inside limits a person set. This page shows who does what, the rules that keep AI on the safe side of that line, and how they worked on a real day: building aidalabs.ca and its sites on 3 October 2026.

Who does what

The AIReads only the files it has been given. Drafts pages and server settings, writes the deploy scripts, tests everything in its own sandbox, renders previews, and explains each step before it runs.Never runs anything on a live server, never deletes, never opens folders, drives or accounts it wasn't given.

A personGrants access one folder at a time, reviews every preview, reads and runs every script, and approves each change before it goes live.The only one who can touch production.

The scriptsBack up first, test before switching anything on, undo themselves if a test fails, and check the result when they finish.Never touch anything outside the one site they were written for.

The rules that keep AI out of the dangerous places

1A person runs anything that touches productionThe AI writes a saved script and explains it. A person reads it and runs it. The AI has no path to the server.

2Explain first, command lastThe explanation comes first, in its own message. The last message holds only the command, so it can be pasted safely.

3Least access, granted case by caseThe AI only reads folders a person has connected, one at a time, for one session. No drives or accounts without permission. Deleting is off unless a person approves it.

4Preview before publishEvery visual change is rendered and approved first, on desktop, tablet (iPad mini) and phone (iPhone 12 mini).

How it worked: building aidalabs.ca

Step 1

An access boundary was crossed, then made a rule

While looking for setup notes, the AI searched folders and a cloud drive belonging to another project without being asked. A person stopped it. The boundary was written into the project's standing instructions: no external files, folders or drives without permission. AIDA Labs work now lives only in its own folder, granted on its own.

Lesson: the guardrail that matters most is the one a person can enforce. We write misses down rather than hiding them, because that's how the guardrails improve.

Step 2

Downloads only, through scripts

The AI's sandbox can't reach the internet sites, so it wrote read-only download scripts and a person ran them. The AI then worked only from those local copies. The five interface components we reused are MIT-licensed and their authors are credited. Where a source couldn't be downloaded, the component was rebuilt from scratch rather than taken from somewhere else.

Step 3

Build and test in the sandbox

Every page was rendered at desktop, tablet and phone sizes and checked automatically for text under 14 pixels, sideways scrolling and script errors. Problems were fixed before a person saw anything: clipped captions on phones, a three-row phone menu, and cards leaving gaps on tablets.

Step 4

Preview, then approval

Previews were shared as screenshots and as single-file pages a person could open, and later published to a preview site so they could be checked on a real phone and tablet. Nothing went live until it was approved.

Next: The controls are designed in, not bolted onBackups, tests, automatic undo and separation: how every change is made safe to reverse.Read part 2 ›

‹ Back to AIDA Labs