Agentic Coding

Track Promise

Turn an idea into a small working tool with a coding agent, while keeping control of the plan, changes, tests, and what happens next.

A coding agent can help write and change software. Your job is to describe what you want, set boundaries, inspect what changed, and test whether the result does what you intended. A confident explanation is not evidence that the code works.

This Track welcomes builders, hobbyists, students, game makers, and people interested in small automations. Not everyone needs to become a software engineer. Planning, designing, testing, and explaining the work are ways to contribute. The current entry is a Builder project; a lower-friction beginner environment is still missing.

Start Here

Begin with Build a Safe Text-to-Speech Skill — Draft / Drafting · Builder. It is this Track’s signature module for the current version. Turning a short script into audio gives the project a concrete output, but the transferable practice is planning a bounded tool, inspecting its changes, testing failures, and judging the result.

• Signature Activity: Build a Safe Text-to-Speech Skill — Alpha.
• Work beside your coding agent: open the standalone Lab Notebook, which carries the activity instructions and completion checklist.

The static audition-site brief is part of the lab’s full completion criteria. Use the facilitator guide for provisional session planning.

Preparation includes a local project folder, a coding agent, a way to run the generated code, safe-file habits, and the module’s stated Prompting and Context Engineering-or-equivalent preparation. Full lab completion requires a personal provider account and live audio, with a low-spend boundary and human listening review. Planning and mock participation are available without that live finish; see Participation and Access below.

The Building Loop

Describe → Plan → Build → Check → Decide

• Describe one small job and what a useful result would do. Use fictional or suitable owned material, not private client or family data.
• Plan the scope, acceptance criteria, and expected failures before files change. Name permitted files and actions, credential handling, spend limits, and what the agent must ask before doing.
• Build a small, reviewable change with the coding agent. Keep a recoverable starting point and ask it to explain the files it touched.
• Check the actual changes and behavior. Test the expected failures as well as the successful path. For the signature project, dry runs and negative tests come before a budgeted live request; a valid audio file still needs human listening review.
• Decide whether to keep, revise, restore, or stop. Record what the tests showed, what remains uncertain, and the next action you authorize. A working local tool is a valid endpoint.

Repeat the loop when scope changes. Permission to plan is not permission to edit, and permission to build locally is not permission to publish, spend more, or act on other people’s systems.

Choose Your Next Build

These are developing directions, not three more ready packages. The named module and lab ideas below have no dedicated source pages. Choose a useful next project after the signature experience; this is not a sequence to complete in full.

Developing direction

Build a small game

Make one playable interaction from a short specification. Try the controls, test the rules, and change one thing based on what a player does.

• Module idea: Building a Tiny Game
• Lab idea: Build a small browser game from a clear spec

Missing: a beginner environment, bounded starter project, test examples, Activity, and standalone Notebook. A project idea is not a ready game curriculum.

Facilitator build demonstration: Coming Soon

Developing direction

Try a bounded automation

Help with one low-risk job using synthetic inputs and inspectable output. Begin with preview-only behavior and a human decision before any action.

• Module idea: Building a Small Automation
• Lab idea: Automate a low-risk personal workflow

Missing: a safe scenario, explicit permissions, stop and recovery rules, Activity, and standalone Notebook. Private data, external messages, destructive changes, and production workflows are outside this proposed first project.

Facilitator build demonstration: Coming Soon

Developing direction · optional next step

Share and maintain a project

Prepare a reviewable project handoff, then decide whether it needs a public home. Practice a small update with a way back to the last working version.

• Module ideas: Publishing Your Work; Git and GitHub for Learners; Deploying Version 2
• Lab idea: Publish a static project page

Missing: a guided sharing and maintenance package, an agreed Git/GitHub entry point, and a tested rollback exercise. No account, hosting service, or deployment is required just to finish a local build.

Facilitator build demonstration: Coming Soon

Earlier ideas for a code orientation, planning, explaining changed files, and acceptance testing remain in the historical audit linked from the shared Track Map. The Building Loop makes those practices visible here without claiming that separate modules or labs have been built.

Strengthen Your Practice

Use these sources to prepare for the current Builder entry or address a difficulty. Their lifecycle and learner availability remain unchanged.

• Prompting Is the Door, Not the Destination — Sketch / Planned. The signature module’s stated dependency: make a useful request, inspect what came back, and repair it.
• Context Engineering — Sketch / Planned. The signature module names this or equivalent safe-file practice as preparation. Select and bound the information available to the agent; a larger context is not permission to use everything in it.
• Safety: Share Less, Notice More — Draft / Drafting. Shared-support candidate from AI Literacy for information boundaries and limited tool authority, not a replacement for the signature lab’s secrets and repository checks.

All three remain primary to AI Literacy. Featuring them here does not add reciprocal Track assignments, change module ownership, or rewrite their dependencies. Their module-owned labs remain on their own pages.

Optional: Share or Publish

A local working project can be the end of the experience. You may give a short demonstration, explain a test or revision, share with a reviewer, or keep the work private. Public presentation is optional.

Before sharing files, review what they contain, whose material they use, and what access they expose. Explain AI’s contribution and the human checks. Publication, deployment, and production use are separate decisions; passing a classroom test does not authorize any of them. Voice cloning remains an idea-only discussion in the signature package, not an approved build step.

Participation and Access

Planning, paired review, and mock testing are valid ways to participate. Learners may describe behavior, review the plan, inspect changes, record tests, or assess supplied output while a partner operates the terminal. These portions do not require a personal provider account, payment, voice recording, or public sharing. Access to a coding agent is a separate setup question; the lower-friction environment has not yet been selected.

The current full lab completion requires a personal provider account and live audio. Its Activity and Notebook call for an MP3 generated through that account, a secret-free test record, and human listening review, along with the plan, failure tests, static audition-site brief, and idea-only cloning note. Never share a classroom API key or paste a credential into the agent conversation. If the secret boundary or spend limit cannot be confirmed, stop at the dry-run portion.

Open artifact mismatch: the facilitator guide accepts a documented mock result as learning evidence, while the Activity and Notebook require live output for full completion. Mock participation is meaningful, but this Track does not relabel it as completing the current full lab. Align those completion expectations in the later artifact pass.

Facilitators should prepare transcripts and supplied outputs, support different review roles, and identify an accessible way to assess audio. The current package still needs accessibility review; an equivalent non-listening completion route has not been established.

For Facilitators

Begin with the signature package’s facilitator guide. Resolve the missing safe repository setup and Voice Auditions inputs before a full learner pilot. Review the current provider documentation and spending controls before any live session; this Track is not a claim that a particular provider’s setup is current.

For a limited planning or mock-session review, state that boundary at the start. Prepare a fictional script, supplied output with a transcript, and roles for planner, operator, test reviewer, recorder, and listener. Model a plan review, an expected failure, and a human decision. Signature walkthrough demonstration: Coming Soon.

Gather actual timing, setup friction, accessibility barriers, and evidence that learners can explain what changed and why they trust or reject it. Record where learners needed help and which participation route they used. Choose the next build from that evidence rather than commissioning all three developing packages at once.

Additional Reading

No additional reading is listed yet.

Status and Feedback

This Track remains Draft / Drafting, with ownership Unassigned. Its signature module remains Draft / Drafting and its signature lab Alpha. The module and lab retain their owner, Mike. Source presence is not a readiness label, and this Track pass does not promote any package.

Use this page’s Track feedback and review links to assess the promise, starting point, preparation, status language, and assigned roles. Are the TTS entry and three developing directions a good fit? Is a lower-friction entry missing? Is any module or lab misplaced? Review composition here; teaching details and completion repairs belong in the separate Module and Lab reviews.

The shared Track Map records this organization, unresolved relationships, missing inputs, and the historical audit. No new module, lab, facilitator demonstration, or deployment is created by this Track revision.

Team review information. You are viewing the team review site. The contributor review tools below are separate from the learner activity and learner feedback.

Review status

• Package lifecycle: Draft
• Learner availability: Drafting
• Review needs: Needs track-level composition, preparation, accessibility, and pilot review.

Review this TrackShare Track feedbackIndependent final QC