Neterverse University / Technology & AI
Build One Useful Thing with AI
Specify, prototype and test a simple local learning tool with visible acceptance evidence
Your learning project
A small local tool, acceptance record and two-minute demonstration
Start with: NVU orientation or an equivalent introduction to evidence and respectful discussion.
Use fictional or appropriately authorized public examples. Personal reflection and completed work can remain private.
0 / 4 correct · artifacts are reviewed separately
AI101-L1
Write the Job
Objective: Specify a small tool before asking AI to build it.
Learn
A useful AI build begins with a clear job. Name the person, the task and the result they need to see. For this course, the person is a learner with ten minutes available. The task is to start, pause and reset a practice session. The result is a readable countdown and an obvious completion state.
Write constraints before generating code. Our starter tool runs in a local browser file, makes no network requests and requires no account. It stores no journal, password or private record. The original version uses a fixed ten-minute session so that the first build remains small.
Define acceptance checks as observable behavior. Starting the timer should reduce the displayed time. Pausing should hold it steady. Resetting should restore ten minutes and clear the running state. Pressing Start twice should not create two simultaneous countdowns. A shortened test session should reach zero, stop and display completion without a negative time.
These checks guide the build and the review. They also give you a way to compare AI help. A confident explanation does not establish that the code works. A screenshot of a page does not establish that the pause button works. You need the right evidence for each requirement.
Write a scope boundary. Publishing, adding accounts, handling payments and collecting personal data are separate jobs. A local timer can be a complete first tool while those other jobs remain outside this exercise. Finish the small job, then decide what the next version needs.
Worked example
Original brief: “Create a ten-minute practice timer for an adult learner. Provide Start, Pause and Reset. Show mm:ss. Run locally without external resources. Preserve the behavior when Start is pressed twice. At zero, stop and display ‘Session complete.’ Include clear code comments and a short test plan.”
Apply
- Write the user, task and visible result in three sentences.
- Copy or adapt the local-only constraints.
- Write the five acceptance cases before building.
- List one feature that belongs in a later version and explain why.
Show evidence
- One-page tool brief
- Five acceptance cases
- One clear scope boundary
Reflect
Which requirement would be easiest to forget without a written check?
Next step
Compare two ways of getting help on the same brief.
Source pointers: DOC01, DOC03. Actual inspection scope appears below.
AI101-L2
Compare the Help
Objective: Compare two prompts or models using the same task and evidence.
Learn
AI comparison is useful when the comparison serves your task. Pick two candidates: two prompts with one tool, or two tools if you already have authorized access. Keep the job, constraints, sample inputs and available time the same. Record the model or tool name and date when available because behavior can change.
Ask Candidate A for an implementation from the brief. Ask Candidate B for an implementation plus a review against the five acceptance cases. These are two different approaches, so record that difference. If you compare two models, use an identical prompt instead. Do not change both the model and the prompt and then attribute the entire difference to one cause.
Score outputs on observed behavior: required controls, acceptance cases passed, external dependency use, clarity and defects. Keep time and cost only if you actually measured them. A quoted subscription price is not your actual cost for this task. A winner on a tiny timer task is not the best model for every job.
Treat generated code as something to inspect. Look for unexpected external scripts, network calls or requests for credentials. This starter task needs none. Do not run unreviewed commands merely because an answer includes them. You can use the supplied prototype to practice evaluation without sending a prompt to a paid service.
The useful result is a decision tied to your brief: which candidate is a better starting point, what you still need to fix and what you learned about asking for help.
Worked example
Fictional comparison: Candidate A has all buttons but pressing Start twice speeds up the countdown. Candidate B prevents duplicate starts but uses an external font. Both need revision under the local-only brief. The correct conclusion is a defect list, not a forced winner.
Apply
- Choose two candidate approaches and record exactly what differs.
- Use the same task and acceptance cases.
- Inspect each output for external dependencies and unnecessary permissions.
- Record actual test results or label the comparison as a plan if you could not run it.
Show evidence
- Two-candidate comparison table
- Observed defects or an explicit unrun plan
- A bounded decision tied to the brief
Reflect
What evidence would change your preferred candidate?
Next step
Inspect and use the small local prototype.
Source pointers: DOC01, DOC03. Actual inspection scope appears below.
AI101-L3
Build the Small Version
Objective: Use and explain a complete local prototype.
Learn
Download the included practice timer and open the HTML file in a browser. The starter prototype is an original teaching example. It uses a page for the controls, styles for readability and JavaScript for the state and timing behavior. It does not need a server or an API key.
Identify its state: remaining milliseconds, whether it is running, the time it started and the interval used to refresh the display. Starting sets a reference time. The display derives remaining time from elapsed time rather than assuming every refresh happens at exactly the scheduled moment. Browsers may delay callbacks, especially in background tabs, so elapsed-time calculation matters. Background behavior still needs testing on the browser you intend to use.
Pausing records the current remaining time and clears the refresh interval. Resetting pauses and restores the initial duration. A guard prevents a second Start press from creating another running interval. When the remaining time reaches zero, the tool stops and displays a completion message.
Make one modest change if you are comfortable editing a copy: change the heading or improve a button label. Ask an AI tool for an explanation of that specific change if needed. Keep the five behavior requirements intact. Do not add accounts, remote tracking or private information to make the demonstration seem more advanced.
Save the starting file and your changed copy under distinct names. Explain what changed and how you checked it. You have now moved from requesting an output to understanding and reviewing a small working artifact.
Worked example
Original change request: “Replace the heading ‘Practice Timer’ with ‘My Ten-Minute Build.’ Keep the duration and button behavior unchanged.” Evidence: two files, a visible heading change and a rerun of the acceptance cases.
Apply
- Download Practice_Timer.html from the studio or open the separate provided file.
- Identify the display, three controls and the variables used for timing.
- Use the controls; optionally make one heading or label edit in a separate copy.
- Save the original and changed versions and describe their difference.
Show evidence
- Opened local prototype
- Component explanation
- One versioned change or an observation record if you did not edit
Reflect
Can you explain the tool’s state without repeating an AI answer word for word?
Next step
Run the acceptance cases and write a clear handoff.
Source pointers: DOC01, DOC03. Actual inspection scope appears below.
AI101-L4
Test and Record
Objective: Produce a test record another builder can understand.
Learn
A tool is ready for this exercise when its small job is demonstrated and its limits are clear. Run each acceptance case in the browser you will name in your record. State the date, version, steps, expected behavior and observation. Do not mark a case passed because the code looks as if it should pass.
Start the timer and confirm that time decreases. Pause it, wait briefly and confirm the display remains stable. Reset and confirm ten minutes returns. Press Start twice and confirm the countdown does not speed up. For the final case, use a copied file with a two-second duration or the prototype’s test setting; confirm it reaches zero, stops and announces completion without a negative display.
Add useful edge cases if a defect suggests one, such as resetting while running or starting after completion. Record keyboard use and a narrow-screen check because visible and usable controls matter. Avoid turning the exercise into an endless test project once the defined requirements are satisfied.
Write a handoff in plain language: what the tool does, how to open it, what changed, what passed, what remains untested and the next sensible improvement. Explain that the prototype has no background alarm guarantee and that the short test run does not establish every browser’s behavior.
For a future GitHub version, use a repository, branch, commit and pull request to preserve and review changes. The official Hello World documentation provides that workflow. This lesson itself does not create a repository or deploy a service. Your completed artifact and honest test log are the evidence for this learning step.
Worked example
Illustrative handoff: “Version 0.2 changes the heading only. Five defined cases passed in the named desktop browser. A narrow-screen check found no horizontal scrolling. Mobile background behavior has not been tested. Next improvement: test on the intended phone before adding any new feature.” This is a sample record; replace it with actual observations.
Apply
- Run and record all five acceptance cases on your submitted version.
- Check keyboard controls and a narrow viewport.
- Explain any failure, fix the defect if within scope and rerun the affected case.
- Write the six-part handoff and choose a next improvement.
Show evidence
- Five-case test record
- Keyboard and viewport observations
- Versioned file and six-part handoff
Reflect
Could another learner repeat your checks from the record alone?
Next step
Apply the same brief, compare, build and verify cycle to one new useful tool.
Source pointers: DOC01, DOC03. Actual inspection scope appears below.
Completion evidence
Complete the four knowledge checks after review and keep the required lesson artifacts. A score alone does not establish completed practical work.
- Four of four knowledge checks correct after review and all required artifacts complete
- Four complete lesson artifacts
- All five acceptance checks pass for the submitted tool; record unresolved defects
This page provides a session self-check. It does not create an enrollment record or independently verified credential. Actual learner timing and pilot outcomes remain unmeasured.
Sources and inspection scope
These original lessons use creator pages, selected descriptions, title metadata and primary references. No full-channel viewing or transcript audit is claimed. A source connection does not endorse every claim a creator makes.
CH07 | Silas AI
Creator account of method and selected indexed video descriptions; no full video review
Adapt fair comparison and visible testing; independently evaluate model outputs and avoid creator income extrapolation.
Open inspected source ↗CH10 | GitHub
Official learning/resource pages and Hello World documentation
Link to GitHub exercises; produce original examples and separate local demonstration from a deployed service.
Open inspected source ↗CH11 | freeCodeCamp.org
Channel description and official companion article; full two-hour course not viewed
Use as technical learning resource; verify implementation details and licenses per individual project.
Open inspected source ↗CH15 | TheAIGRID
Indexed channel description and titles only
Treat news and rankings as leads; verify against original release notes, papers and repeatable task tests.
Open inspected source ↗DOC01 | GitHub Hello World
Official workflow documentation; page read
Open inspected source ↗DOC03 | freeCodeCamp RAG & MCP Fundamentals
Official companion article read; full course video not viewed
Open inspected source ↗