Vibe coding and project thinking

01 / WORKING WITH A CODING AGENT

What is vibe coding?

Vibe coding is an informal name for making software by describing what you want to an AI coding agent, trying the result, and asking for changes. You might begin with “I want a page where I can keep track of my study tasks.” The agent can turn that request into code, edit project files, and run commands through its tools.

You still make the decisions about the app. Who is it for? What should happen when someone clicks a button? Which result counts as correct? An agent can suggest answers, but it cannot know all your intentions from one sentence. If you leave a decision open, it may make a choice you did not expect.

You do not need to know every line of code before you begin. As you work, ask the agent to explain the files it changes and the parts that control a behavior. For example, find where the Add task button handles an empty title. That connects something you can see in the app with the code that makes it happen.

For this lesson, you will build a small app you can use and explain. A working first version gives you something specific to improve in the next lesson.

02 / CHOOSING A PROJECT

Start with a person and a problem

A project idea becomes easier to build when you can describe a situation in which someone would use it. “A school app” leaves many questions unanswered. “A student needs to remember three tasks for tonight’s study session” gives you a user, a situation, and a need.

This is project thinking: deciding what is useful, what belongs in the first version, and how you will know it works. It begins before you ask for code and continues when you try the app.

Imagine Maya is studying for a math quiz. She writes a few tasks on scraps of paper and loses track of which ones she has finished. An app could keep those tasks together. Maya does not need a schoolwide scheduling system to solve that problem tonight.

A user story describes an action and why it matters to the person using it. Maya’s story could be: “As a student, I want to add and check off study tasks so I can see what I still need to do.” The sentence helps you connect a feature to a purpose.

Choose one of these situations, or describe a similar problem from your own day. Ask a partner to act as the user: when would they open the app, and what would they expect to do first? Their answer may change your plan.

03 / PLANNING THE BEHAVIOR

Define a first version you can check

The scope of a project is the work you include. For Maya’s first version, the scope is adding a task, changing whether it is complete, and keeping the list after a page refresh. Reminders and shared calendars can wait. Each extra feature adds decisions and more behavior to test.

A prototype is an early version used to try an idea. It can be small and still be useful. Before coding, sketch one screen on paper: a heading, a title field, an Add task button, and a list. Draw what the page looks like before any tasks exist. Then draw one task after it has been added.

The app needs data, the information it keeps: each task needs a title and a complete or incomplete state. For this prototype, it will use localStorage, a browser feature that keeps small amounts of data between page loads for that site. The list will stay in that browser profile. Another device or browser will have its own list, and clearing site data can remove it.

An acceptance check states an action and the result you expect. “Looks good” is hard to judge. “Add Review fractions and confirm that exactly one incomplete task appears” tells you what to do and what to look for. Also check a case where the input is missing. This is an edge case, a situation outside the usual successful path.

Build a small first version in my existing VCC project.

User: A student planning one study session
Problem: I lose track of the small tasks I want to finish before a quiz.
Input: A short task title, such as Review fractions
Main action: Add the task to a list, then mark it complete
Visible result: The task appears in the list with a visible complete or incomplete state.
Leave for later: Due dates, reminders, accounts, and sharing with classmates

Acceptance checks:
1. Add Review fractions. Exactly one new incomplete task appears.
2. Submit an empty or spaces-only title. No task is added and a helpful message appears.
3. Mark Review fractions complete, then incomplete. Its visible state changes both times.
4. Refresh the same browser tab. The task and its latest state remain.

First inspect the project and summarize a short implementation plan. Add this app at /my-project with a link from the starter page. Keep the existing idea notebook, database, and its tests working. Use the existing stack and add no packages, accounts, external services, or AI features. Store this new app's list and completion states in this browser using localStorage, with a storage key specific to this app. Treat typed titles as text. Use labeled controls, a readable layout, keyboard-operable buttons, and a helpful empty state.

Implement only this first version. Run the existing tests and build, and add relevant behavior tests for the new list and its empty-input handling. Report the files changed, actual check results, and the steps I should try in the VCC sandbox preview. If you could not run a check, say so.

04 / ASSIGNMENT IN VCC

Build and try your first version

Use your brief to build the app in a new VCC project. The example prompt keeps the existing starter notebook working and adds your app on a separate page at /my-project.

1. Copy your project brief and build prompt above into your notes. Open VCC Projects ↗ in another tab and create a project named for your idea. Use your classroom login and stay in VCC sandbox.
2. In Build & activity, paste the prompt into Ask agent. Read its plan and activity as it works. Use one agent task at a time so two tasks do not edit the same files.
3. When it finishes, inspect the reported tests and build. Select Open coding workspace, then Start workspace if needed. Open Preview and follow the link from the starter page to your app.
4. Perform each acceptance check yourself. Record the actual result next to the expected result, including any failure. Check the new app at a narrow preview width, use Tab to reach its controls, and try submitting with the keyboard. Confirm the original idea notebook still saves an idea after refresh.
5. Choose one small improvement based on what you observed. For the study planner, you could add a count of incomplete tasks. Write the expected result before asking: with two incomplete tasks the count is 2, checking one makes it 1, and unchecking it makes it 2 again. Rerun the earlier checks after the change.

A passing build means the project can be built. Automated tests check the cases they cover. Your own preview checks show whether the app meets the behavior in your brief. An agent’s message saying “all done” is a report to inspect.

If a check fails, give the agent a repeatable example. Debugging means finding the cause of a problem and correcting it. The following example tells the agent exactly which behavior failed; replace its details with what you actually observed.

In the study planner at /my-project, I expected a task's completed state to remain after refresh.
Steps: add Review fractions, mark it complete, then refresh the same browser tab.
Actual result: the task is still listed, but its checkbox is unchecked.
Find the cause and fix this behavior. Keep the other features working. Run the relevant tests and build, report the actual results, and tell me what to check again.

Use made-up study tasks, supplies, or book entries for testing. This version only needs those titles and their checked states. Your project files are saved in VCC; your prototype’s list is stored separately in the browser.

05 / REVIEW AND SUBMISSION

Explain what you built

Before you finish, ask a partner to try the main action from your brief. Watch where they hesitate. Write one observation and decide whether it needs a change now or belongs in a later version.

Turn in:

• Your project brief and one-screen sketch, including what you left for later.
• A screenshot or short demonstration of the working main action, plus your acceptance checks with their actual results.
• The reported test/build results and one change you requested after trying the app. If a check still fails, identify it.
• Your project files or Git commit, and a short explanation of who the app helps and where its data is stored.

In VCC, review git status and git diff in Bash, then use Git History → Commit All to record a version you can explain. If the agent already made that commit, inspect it. Select Save checkpoint, wait for the saved time, then select Save and stop.

Review question: If you had one more class period, which single improvement would help your user most? Give the action and expected result you would use to check it.