← Applied AI Builder
0/18 complete

Module 01 · Technical Foundations

Technical Foundations: CLI, Git, JSON, and HTTP

40 minfocused lesson5practical steps4grounded questions5source links
Open lesson + course map

On this lesson

Course outline

An AI builder needs four practical foundations before touching a model API: the command line runs repeatable work, Git records exactly what changed, JSON carries structured data, and HTTP moves requests and responses between systems. You do not need to become a systems engineer first. You do need to recognize these four layers well enough to inspect a failure instead of repeatedly changing a prompt and hoping.

This lesson builds one tiny project from end to end without an API key. It creates a versioned JSON brief, validates it in JavaScript, makes a read-only HTTP request, and records what happened. That same shape appears later when the remote endpoint is an AI provider rather than a public test service.

// concept

The Four Layers and Their Jobs

The command-line interface (CLI) is a text interface to your computer. A command runs in a current working directory, receives arguments and environment variables, writes output, and exits with a status code. The current directory matters: node inspect.mjs can only find brief.json where your code expects it. Learn pwd on macOS/Linux or Get-Location in PowerShell, ls or Get-ChildItem, cd, and how to read an error before running another command.

Git is a version-control system, not a backup service and not the same thing as GitHub. A repository stores snapshots called commits. git status shows the gap between your working files, the staging area, and the last commit. A useful commit is small, intentional, and described in plain language. Never commit an API key, customer export, private voice note, or .env file.

JSON is a text data-interchange format. Objects use string keys; arrays preserve order; supported values include strings, numbers, booleans, null, objects, and arrays. JSON does not allow comments or trailing commas. A valid JSON document can still contain the wrong business facts, so syntax validation is only the first check.

HTTP is the application protocol used by most web APIs. A request has a method, URL, headers, and sometimes a body. A response has a status code, headers, and usually a body. A 200-class status usually signals success, 400-class statuses point to a request or authorization problem, and 500-class statuses point to the remote service. Always check the actual status and response body; fetch() does not turn every non-success HTTP status into a thrown JavaScript error.

// worked_example

Worked Example: A Versioned Project Brief Inspector

Step 1: create the project and confirm where you are

Create a folder named builder-foundations, open a terminal in it, and run the commands one line at a time:

// powershell4 lines
git init
npm init -y
git status
Get-Location

On macOS or Linux, use pwd instead of Get-Location. If Git asks for your identity when you later commit, follow Git's message and configure a real name and email at the appropriate local or global scope. Do not copy somebody else's identity just to silence the warning.

Create brief.json in an editor:

// json9 lines
{
  "project": "delivery-faq-prototype",
  "audience": "customers in Lahore and Islamabad",
  "languages": ["English", "Roman Urdu"],
  "constraints": {
    "may_quote_prices": false,
    "must_escalate_unknowns": true
  }
}

Ask Node.js to parse it before trusting it:

// powershell1 line
node -e "const fs=require('node:fs'); const x=JSON.parse(fs.readFileSync('brief.json','utf8')); console.log(x.project, x.languages.length)"

Expected output is the project name followed by 2. Add a trailing comma deliberately, rerun the command, read the parse error, and then repair the file. That failure is useful: it proves the parser is checking the file you think it is checking.

Step 2: inspect an HTTP response instead of printing everything

Create inspect.mjs:

// javascript22 lines
const url = "https://api.github.com/repos/openai/openai-node";

const response = await fetch(url, {
  headers: {
    Accept: "application/vnd.github+json",
    "User-Agent": "ai-school-foundations-lab",
  },
});

console.log({
  method: "GET",
  url,
  status: response.status,
  contentType: response.headers.get("content-type"),
});

if (!response.ok) {
  throw new Error(`HTTP ${response.status}: request was not successful`);
}

const body = await response.json();
console.log({ fullName: body.full_name, defaultBranch: body.default_branch });

Run node inspect.mjs. Notice the gates: the program records status and content type, stops on a non-success status, parses JSON only after that, and prints two fields rather than dumping an entire response. In client work, selective logging reduces accidental exposure of personal or confidential data.

Step 3: commit a known-good state

Create .gitignore containing:

// prompt — copy me3 lines
node_modules/
.env
*.log

Then run:

// powershell4 lines
git add brief.json inspect.mjs .gitignore package.json
git diff --cached
git commit -m "Add JSON and HTTP foundations lab"
git status

git diff --cached is the review gate. Check that it contains no secret or private record. The final git status should report a clean working tree. A clean tree does not prove the code is correct; it proves you know which version you tested.

// failure_cases

Failure Cases to Diagnose

7 cases to diagnose

  • Wrong directory

    “file not found” may mean the terminal is in the wrong folder, not that the file vanished. Print the current directory and list files.

  • Invalid JSON

    single quotes, comments, trailing commas, and unescaped line breaks are common causes. Use a parser, not visual inspection alone.

  • Valid JSON, wrong meaning

    "may_quote_prices": "false" is a string, not the boolean false. Later lessons add schemas to catch this.

  • HTTP failure hidden as data

    check response.ok or the numeric status before treating the body as a successful result.

  • Rate or network interruption

    a timeout, DNS failure, or 429 response is not evidence that your code's business logic is wrong. Record the category before deciding whether to retry.

  • Unreviewed commit

    git add . can stage local datasets or credentials. Review the staged diff and repository status every time.

  • Remote response changed

    public APIs evolve. Depend only on fields you validate and handle a missing field explicitly.

// pakistan_angle

Pakistan Angle

A learner working on mobile data or an unstable connection should keep the development loop local: edit JSON, validate it, and run local tests before making a remote request. Small fixtures cost no API money and transfer quickly. Save package installers or documentation for offline use only where licenses permit, and avoid repeatedly downloading large sample media.

Shared family computers and office laptops need extra care. Use a separate operating-system account where possible, never save client exports inside a public repository, and remove credentials before screen-sharing a terminal. Roman Urdu and Urdu are valid Unicode text; preserve UTF-8 encoding and test the exact script and spelling the intended audience uses. Treat phone numbers, CNIC values, addresses, payment records, and private messages as sensitive inputs, not convenient test data.

// hands_on

Hands-On Exercise: Produce a Reproducible Evidence Pack

5 steps

Build a new local repository called foundation-proof and produce these artifacts:

  1. brief.json with a project name, audience, two languages, and at least two boolean constraints.

  2. inspect.mjs that makes a read-only GET request, prints method/status/content type, stops when response.ok is false, and prints no more than three selected response fields.

  3. .gitignore that excludes .env, log files, and dependency folders.

  4. RUNBOOK.md containing the exact commands a reviewer should run and the expected categories of output. Do not paste secrets or a large response body.

  5. Two commits: one for the initial fixture and one for the inspected HTTP request. Use git log --oneline to show both. Temporarily break the JSON and temporarily change the URL to a path that returns an error. Record the two different failure messages in RUNBOOK.md, then restore the working version. This proves you can distinguish a local parse failure from a remote HTTP failure.

// completion_rubric

Completion Rubric

6 grading bands

  • Pass — reproducibility

    a reviewer can clone or copy the folder, follow RUNBOOK.md, and get the same class of result.

  • Pass — data discipline

    JSON parses, booleans are booleans, and only necessary fields are printed.

  • Pass — HTTP discipline

    method, URL, status, and content type are inspected before the body is trusted.

  • Pass — version discipline

    the working tree is clean and the commit history separates the two meaningful changes.

  • Pass — privacy

    no credential, personal identifier, client record, or full remote payload appears in Git or the runbook.

  • Needs revision

    any command depends on an unexplained directory, a failed response is treated as success, or the staged diff was not reviewed.

// sources

Sources

5 official sources — check every claim yourself

// check_yourself

Check yourself

4 questions · answers and options are taken word-for-word from this course

0/4

  1. 1 / 4 · diagnose

    Your work shows this failure mode: “Invalid JSON.” The lesson describes it like this: “Single quotes, comments, trailing commas, and unescaped line breaks are common causes.” What does the lesson tell you to do about it?