Smoke test: A quick, surface-level check that your app launches without crashing. Not a deep test; just "does it turn on?"
Never skip testing and validation when you build a solution.
In Composer, press Shift+Tab to show Plan Mode.
The agent produces a plan (steps, file references) before coding. You can edit the plan and run it, or skip and prompt directly.
Open Composer Cmd+I, then:
Rule of thumb: Use Composer for building features, Chat for understanding code, Inline Edit for surgical changes.
Cursor connects to different language models. You can switch based on your needs.
Open the dropdown at the top of Composer. For this course, the default is fine for most cases.
MCP lets the agent use tools — fetch URLs, browse the web, query databases.
Try: The agent fetches a webpage and summarizes it. You see the tool call in the panel.
Takeaway: The agent isn't just auto-completing. It can reach out to the world through tools.
Think of Rules as a standing brief, Skills as a reference manual, and Subagents as specialist assistants.
Plane 1: Everything here is Plane 1 — agents helping you code. The same mechanisms power Plane 2 (Week 7+): agents inside your product. We lean on subagents only once we can test and constrain them.
# Week 1 .cursor/rules
## Stack
- Python 3.11+
- Streamlit for all UI components
- Keep all code in app.py (single file only)
## Code Style
- Add a comment above every function explaining what it does
- Use type annotations on all function signatures
- Print clear error messages if any API calls fail
## Behavior
- If I ask for a new feature, add it without removing existing features
- Prefer simple, readable code over clever, compact code
- Ask before making large structural changesThis file is your first system prompt — the same idea powers in-app agents (Week 7). Better context = better output. This is context engineering.
"It knows them in general. The .cursor/rules file tells it about YOUR project specifically. It's the difference between a contractor who knows how to build houses in general, and a contractor who has read your specific brief."
The file doesn't add knowledge — it adds context and constraints.
Build a web app
Build a Streamlit web app that
shows current weather for Seattle
using the Open-Meteo API (no API
key required). Display temperature
in Fahrenheit, humidity percentage,
and wind speed in mph. Add a
Refresh button. Make it
mobile-friendly.Specificity is a design decision. Every detail you include prevents a bad guess.
"Professional developers spend 40% of their time planning what to build. Writing the spec. Talking to users. Drawing the architecture. 20% is the actual generation. 40% is testing and verification."
"The feeling of inheriting a codebase full of AI-generated code you don't understand and cannot fix. It looks like it works. Then something breaks at 2am before a deadline. And you have no idea where to look."
Every lab is designed to force this ratio. Keep this ratio in mind when you are working on the lab.
Build a Streamlit web app that
shows current weather for Seattle
using the Open-Meteo API (no API
key required). Display temperature
in Fahrenheit, humidity percentage,
and wind speed in mph. Add a
Refresh button. Make it
mobile-friendly."Watch what I do, not what the AI does. The AI is just the keyboard. I'm the architect."
I-P-O: Your First Architecture View
Separation of Concerns: Input (UI) vs. Process (logic + API) vs. Output (rendering). This three-part split reappears as 3-tier architecture in Week 5.
Check structure and intent now. Save edge cases and math verification for the testing checklist.
Before running the code, I want your prediction.
Why predict? Prediction forces you to form a mental model of the code before seeing the output. This is how understanding develops.
The app works. Now we add wind direction — an incremental prompt:
Add a wind direction indicator (N, NE, E, SE, S, SW, W, NW)
based on the wind_direction_10m field from the Open-Meteo API.
Show it next to the wind speed metric with a compass emoji.Turn to the person next to you. Explain the code in plain English. No jargon.
8 lines of code from our demo app. Explain what each section does to your neighbor — as if they have never written code. Your code might be different than what you see on screen.
# Fetch weather data from API
def get_weather(city: str) -> dict:
url = f"https://api.open-meteo.com/v1/forecast?latitude=47.6&longitude=-122.3"
response = requests.get(url)
return response.json()
# Display results
data = get_weather("Seattle")
st.metric("Temperature", f"{data['current']['temperature_2m']}F")The word "function" is allowed. Everything else — translate it.
The app we just built is technically functional.
But does anyone actually need a Seattle weather app?
The same technical components can solve completely different problems when pointed at the right need:
The first thing you do in lab today is not open a computer. It's a conversation with a GIX staff member.
"When [person] needs to [task], they currently [workaround], which causes [pain]."
This sentence emerges from the interview. Walk in curious — not with an app idea already in your head.
In today's lab, you'll meet Dorothy, who needs a system for purchase requests. There's a catch:
Does data need to be persistent? If your answer is yes, how can we record and retrieve information robustly? How do you structure the data?
Keep this constraint in mind as you conduct your interview and draft your problem statement.
You are always at both ends of this loop. The agent is the middle. You start it, and you judge the result.
Next week, we will start writing code using terminal-based agents.
Action Item: Please get either Claude Code or Open Code ready before next week's class.