Best Practices and Lessons Learned

Ask the AI to produce a plan before any code, and read the plan. Strong

The most consistent advice on Project 1 was to treat the AI as an architect first and a coder second. Students who asked for plans, outlines, or section-by-section strategies before letting the model write anything reported smoother work and cleaner code.

"Having the AI make plans for large features is helpful." [S31 · P1] · "Get AI to give you their plan before telling it to execute it." [S43 · P1] · "Using an AI tool to plan out your project first." [S1 · P1] · "When using GitHub Copilot, I found using Plan Mode first and then switching over to Agent Mode to be very effective." [S37 · P1]

When the chat gets muddied, start a new one. Common

Several students independently arrived at the same conclusion: chats accumulate bad context, and prompting harder doesn't fix it; starting fresh does.

"Refreshing the chat helps not muddy the code — don't just keep prompting, and safe often." [S2 · P1] · "Starting a new chat even with the same model fixes problems." [S39 · P1] · "Try start new conversation if the current one won't be able to give what you want." [S42 · P1]

Specificity pays, but a minority got better results by loosening the reins. Strong, with a genuine counter-view

Most students said detailed, explicit prompts yielded the best output: telling the model exactly what to change, what not to change, and where.

"Ask for one change (or group of very similar changes) at a time." [S45 · P1] · "When prompting, specify what need to be changed and what don't need to be changed. Giving sample is generally helpful." [S35 · P1] · "You need to be pretty specific about what u want or it will give you a really simply result." [S26 · P1]

But a visible counter-current, particularly around design work, argued the opposite: hand over aesthetic judgement and let the model surprise you.

"AI performed better the less specific I was, and the more 'free rein' it had to complete a task." [S24 · P1] · "Classmate prompted it to do more general things rather than specific and let AI take more control of the design." [S41 · P1] · "It was easier to use AI in an open-ended way to start and for design features." [S18 · P1]

Show, don't (just) tell: feed concrete references. Common

Visual references and links to inspiration websites outperformed pure text descriptions, especially for layout and style.

"If you want to combine multiple pieces for inspiration, rather than describing it in the prompt, actually provide the sources you want to combine (the link of a cool hackathon website with the link of a cool portfolio you saw)." [S15 · P1] · "Make a sketch in Figma and then tell LLM to make a website that looks like the sketch really helps a lot." [S32 · P1] · "Use AI to view other websites and then generate the format and slowly prompt new elements onto the page." [S5 · P1]

Verify everything: the model will confabulate. Common

Hallucinated details (especially personal info, instructions, and small styling choices) showed up often enough that several students made "check its output" a standing rule.

"Check anything that it writes because it really likes to make things up." [S17 · P1] · "It remembered everything, even from previous prompts. When I made my first skeleton of the website, it had information about me I didn't explicitly write in." [S33 · P1] · "I often had to walk the AI through issues I was facing. It had difficulty finding its own bugs when they were not described in a lot of detail." [S25 · P1]

Ask for explanations so you understand what's being shipped. Some

Treating the assistant as a teacher, not just a typist, was a recurring recommendation; it's useful for the learning goals of the course, and also for being able to reasonably explain the code later.

"When prompting, emphasize that you want to understand why we're changing certain code and what certain code does for us implementing our desired feature." [S21 · P1] · "Asking AI to make the code readable to beginners is a good way to learn." [S40 · P1]

IDE-integrated tools beat the browser window, when you can use them. Some

A small but vocal group found the browser-chat workflow the course prescribed frustrating compared to IDE integrations they already knew, confirming exactly the "notice the limitations" lesson the project was designed to teach.

"Using Claude Code in the IDE was way better than using the browser version." [S8 · P1] · "Using cursor, it is very powerful." [S4 · P1] · "The live preview extension worked well with GitHub copilot, enabling you to directly select elements on your website and let AI modify it." [S36 · P1] · "Use vs code extensions it makes the work flow a lot easier." [S28 · P1]

Try to solve it yourself before pasting the error in. One student

Advice worth highlighting even though only one student voiced it this assignment (the pattern returns later in the semester):

"Always try to solve an error first before copying into the prompt. Even if you just spend 20 seconds looking at it, you will learn a lot more." [S22 · P1]

Model choice matters; credit / rate limits will bite you. Some

Different models excel at different things, and free-tier rate limits surprise people mid-deadline.

"The model you use really makes a huge difference." [S34 · P1] · "Claude is good for good ui design." [S29 · P1] · "GitHub Copilot is very convenient but the credits are gobbled up really quick." [S14 · P1] · "Putting in a contact form is relatively easy with AI — Gemini specific." [S12 · P1]

Work incrementally. Small prompts, one feature at a time, MVP first. Dominant

The single strongest message across HW2, and almost certainly shaped by the one-hour constraint: students who asked the model to build the whole game in one shot ended the hour with output too big to debug; students who asked for one segment at a time (player movement, then a lane of traffic, then the score display) got something playable within the time budget and felt they understood what they had.

"Prompting it to complete segments of the game rather than fixing all the mistakes at once." [S5 · HW2] · "Control small and important parts without letting it jump into making the whole thing." [S17 · HW2] · "Start simple, and add more features incrementally." [S31 · HW2] · "Do not let AI generate too much content in one time, and care about the in-context surrounding." [S27 · HW2] · "Giving it bullet points of what features to implement at the start got me a great initial product." [S9 · HW2] · "I think building from simpler ideas and then constructing larger ideas would be a good approach." [S23 · HW2] · "Creating a simple plan first and then adding features." [S41 · HW2]

Don't let AI write one giant file. Ask for multiple files. Some

Two independent students landed on the same specific tactic: force modularity at prompt time.

"Don't create crossy road all in one file." [S3 · HW2] · "Tell AI to separate the code in multiple files — I think this makes understanding the logic of the code easier." [S40 · HW2] · "Telling AI to write code in a specific structure helps with debugging." [S36 · HW2]

Screenshots and sketches work better than words for UI bugs. Some, strongly held

When something looked wrong, students who uploaded a screenshot of the broken thing got fixes faster than students who tried to describe the bug in text.

"Taking screenshots of bad UI components and uploading them to the AI was super useful." [S22 · HW2] · "Give screenshots are powerful for AI to recreate." [S35 · HW2]

One AI writes the prompt, another AI writes the code. Some

A two-model workflow appeared for the first time and will recur in later assignments.

"Using an AI to write a prompt for another AI." [S33 · HW2] · "I tried this process where I asked Gemini for prompts and planning while giving prompts to Claude. The process itself was less buggy, I think I encountered less bugs than I would have if I just prompted myself, but it took much longer than my peers to get to the same point." [S24 · HW2]

Student S24's note is important: the quality was better, but the speed was worse. This tradeoff matters.

When a bug won't go away, switching models doesn't always help. Sometimes you need to read the code. Some

Students noticed a specific failure mode: re-prompting, or swapping to a different chatbot, can dig a deeper hole instead of escaping the current one.

"AI is really bad with sticking with small changes you made, such as using pythonRound and not round." [S7 · HW2] · "I had to actually tell the AI to fix itself for it to fix itself." [S10 · HW2] · "Turning towards another model when there's a bug doesn't necessarily help fix it I think you need to manually debug it." [S29 · HW2] · "AI struggled with listening to specific prompts in my crossy road game. Even with multiple, repeated prompts, it was difficult to debug and change as I had to repeatedly play the game to find the bugs." [S38 · HW2]

Environment / library issues ate more time than code did. Some

The AI is not always aware of your Python version or OS. Several students hit wall after wall over package setup, and one explicitly called out that LLMs struggle with system-level requirements.

"AI struggles to understand system requirements. I spent a lot of time struggling because pygame could not work with Python 3.14 and I ended up having to revert to 3.13." [S13 · HW2] · "Downloading libraries was a nightmare for some reason." [S14 · HW2] · "Having your AI model interfaced with your hardware in order to ensure proper portability. Say 'I want this to be able to play from an html page' and then ensuring that the proper libraries are installed and configured for this task." [S21 · HW2]

Different models have different quirks, even on the same prompt. Some, nuanced

The most interesting observations came from students who ran the same assignment through different tools and compared:

"I compared the output of both chatgpt and gemini and I found that chatgpt took longer and tried to create something more sophisticated while gemini was alot quicker however took alot of prompts to get a product but it made less mistakes." [S20 · HW2] · "Different models still have similar ideas of what features to add, such as an eagle that ends the game when the player doesn't move for a while. Different models also had common issues with player locations and moving platforms." [S18 · HW2] · "Even the same model creates very different problems and outputs." [S39 · HW2]

"Ask" mode before "Agent" mode, when the IDE supports it. One student

A specific IDE-workflow tip that anticipates the agentic-development assignments later:

"Use 'ask' mode before 'agent' mode really helps." [S32 · HW2]

Rate limits and Pro tiers become real and brutal when you're on a clock. Some

Students hit model caps during iterative game-building for the first time this assignment, and with a one-hour budget, each minute spent waiting on a throttled response was material.

"Claude is very very slow and has a tendency to max out quickly." [S2 · HW2] · "Using pro versions is much more helpful. The free version of Claude was not very helpful." [S4 · HW2] · "If you fix small details all the time, most of your time is going to go for you to wait for the model's output." [S15 · HW2]

Two-model workflow: brainstorm and plan with one, implement with another. Common

The pattern that appeared tentatively in HW2 got clearer here: students split "what should I build" from "now build it."

"Planning with Claude / chat / Gemini and using cursor and antigravity to write actual code." [S4 · HW3] · "It was useful for me to develop a plan and brainstorm features with one AI model first, gaining ideas for the project itself. Then implementing with a new AI and incorporating those details in the description helped refine it I think." [S38 · HW3] · "Use general AI like gpt to certain idea and do brainstorm, and use codex or cursor to code and implement the ideas." [S27 · HW3]

One dissent is worth recording:

"It's hard for me to use different ai when I do one project. The logic of different AI is different. I can't intergrade the idea from different AI tools." [S44 · HW3]

Start with a simple, clear idea: don't go with the flow. Common

This is essentially the "incremental / MVP first" advice from HW2, but with a new twist: students warned each other against aimless drift when there's no strong starting vision.

"Having a clear idea / vision was very important. I went with the flow too hard and my project was just very random." [S43 · HW3] · "Start from a simple idea and then build up." [S23 · HW3] · "Implementing code step by step to avoid major bugs." [S20 · HW3]

Be very specific, because the AI can't read your mind. Common

Several students ran into precise phrasing traps, where the same ambiguous English generated wildly different projects.

"For more developed projects, if you don't clearly specify what you mean AI won't be able to do it. It can't read my mind like I thought it would." [S3 · HW3] · "Be very specific when trying to add the api in the project." [S5 · HW3] · "I found that when I would phrase something with 'I want a project that does X so that I can learn Y while building it' I would receive a literal learning module app, rather than an interactive project that would teach concepts by working through the project." [S21 · HW3]

Feed the AI the actual API documentation, or a URL. Common

A concrete technique that multiple students credited for easier integration:

"It felt good to first ask ai to find a database with well define api documentation." [S11 · HW3] · "Make AI read parts of the api file." [S36 · HW3] · "Ask AI to deeply explain the process of executing the AI, which clarified a lot of things in the code, methods and my understanding of an API." [S9 · HW3]

Plus a related finding about model recency:

"I find Google Gemini had some really great recent APIs that I could not only use, but recognized were beginner friendly. It was more updated than things I found in older lists." [S24 · HW3]

When the prompt loop gets stuck, read the code. Some

The HW2 lesson that re-prompting doesn't always work was stated even more crisply here:

"Once there's a bug, it doesn't go away with just prompting you need to read the code to figure it out to be more specific on prompting." [S29 · HW3]

Screenshots / example pages work for UI, color palettes for style. Some

Same show-don't-tell principle as Project 1, applied to HW3 contexts:

"Attaching screenshots really helps the AI with design." [S31 · HW3] · "Its often useful to provide the AI model with an example website interface to model your own of off." [S40 · HW3] · "It's really good have a color palette to start with, and tell LLM a specific style you want (eg. Pixel), otherwise it's going to make it too 'AI-like'." [S32 · HW3]

Don't trust the AI to handle secrets correctly by default. Some

Given that this was the first assignment with API keys, it's notable that the warning came from students who had almost been burned:

"AI is not very specific in what to do to not push an api key unless you tell it explicitly." [S18 · HW3] · "Don't trust that AI tools will persist environment variables correctly." [S22 · HW3]

AI-in-IDE is better at debugging than browser chat. One student

"AI built in in your IDE can be better at debugging." [S35 · HW3]

Miscellaneous observations worth carrying forward. One student each

"At the very least, ChatGPT is quite familiar with Streamlit, a very cool tool for creating easily launch-able websites. I did not even ask it to use it but it automatically did so and performed quite well." [S13 · HW3]

"AI not good at giving terminal related instructions." [S39 · HW3]

"Jetbrains Junie choked trying to do it." [S19 · HW3]

Run separate chats (or agents) for frontend, backend, and data. Strong

The clearest architectural lesson of the assignment: when a project has cleanly separable concerns, give each one its own context window.

"For a project like this, split your work into multiple chats. I had the backend, frontend, game logic and architect chats. Every time you switch, you must tell it the current state of the project." [S15 · HW4] · "I found starting with the backend and then moving on to the frontend (once the backend was working) was a good workflow for this assignment." [S37 · HW4] · "It helps to have your AI model break down the process for which it should implement each of the frontend and backend, and then implement them. So it has more direction." [S11 · HW4]

Plan with one LLM, implement with another: now with explicit hand-offs. Common

The brainstorm-then-build pattern got sharper and more specific about what to pass between models:

"Have one llm generate a step by step plan and then give that plan to another llm to implement it." [S4 · HW4] · "Sometimes I'd ask Claude to generate the best cursor prompts for me. Don't underestimate an AI's ability to write prompts." [S45 · HW4] · "I recommend building ideas with GPT/Gemini and coding with codeX/ Cursor." [S27 · HW4]

Deployment is its own beast. Free-tier hosts will surprise you. Strong

This was the first time deployment itself (not the code) was the main source of student frustration. Render spinning down on free tiers came up repeatedly, as did the Vercel serverless model forcing code changes after local work had already succeeded.

"Render shuts down every time I leave it unattended for several minutes, making it very hard to generate results consistently." [S34 · HW4] · "Render went to sleep often." [S6 · HW4] · "It was challenging to deploy render since it takes a while." [S26 · HW4] · "So when using Vercel vs local testing I can't have a server.js file and that forced me to change a couple of things after finally getting everything to be stable after local testing." [S14 · HW4] · "From my conversation with [REDACTED] I found that some APIs are more specific on how you should display your API key. I also found that using a tool like uptime robot to decrease the amount of time to load the page was useful for demonstration." [S21 · HW4]

Test the backend locally and with curl before deploying. Some, hard-won

The clearest version of this lesson came from a student who didn't do it and paid for it:

"Manually check your API calls using Curl on the host server. I ran into a long problem with pythonanywhere denying SMTP requests, but the AI code ate the logs." [S22 · HW4]

"The AI code ate the logs" (i.e., the generated code swallowed error information instead of surfacing it). A good concrete reminder that AI-written error handling can hide the very information you need to debug.

Database, auth, and cross-service config are where AI stops being helpful. Common

A consistent finding: when a bug lives outside the code (in a database schema, in Supabase dashboard settings, in Google Cloud key restrictions), AI assistance gets much weaker.

"I found setting up supabase to be challenging at first as I couldn't have Ai do it automatically for me. So when I ran into issues with the data storage I couldn't just prompt GitHub copilot to fix the issue as the errors weren't in the code but rather in the way I set up my tables in supabase." [S5 · HW4] · "It's harder when it involves jumping between different services, especially for the database configuration part." [S32 · HW4] · "Setting up auth and database was tricky and AI wasn't super helpful." [S31 · HW4] · "Google Maps APIs force you to expose your API key on the front end source code because it's required to make direct requests to Google's services." [S8 · HW4]

The AI won't tell you if what you're asking is feasible. You have to check. Some

A failure mode students hadn't really seen before: the model confidently tries an approach that cannot work in the environment they're in.

"One thing I found challenging is AI not determining if my request is feasible before trying to implement." [S3 · HW4] · "For some reason, AI (or at least Gemini) really doesn't want to suggest that you do something to find the available API models. The error message I was giving Gemini had to do with models, and it included a function I could call to check available models. Gemini never suggested I run that even when none of the models it suggested were working." [S18 · HW4]

When a library fights you: swap libraries or swap models. Some

Concrete tactics for getting unstuck:

"Sometimes when the AI struggles with debugging when using a specific setup, it helps to change the external library or modules used in the code." [S36 · HW4] · "Switching between models to cope with running out of credits." [S16 · HW4] · "It seems to be much easier to get AI to work with Javascript for the backend rather than Python, perhaps because it was trained on that more?" [S17 · HW4]

Understand the platforms you're gluing together, not just the code. Some

"Honestly, the hardest part for me was understanding how ports worked and how to run things locally. Otherwise, I found AI to be pretty helpful in understanding how the backend should connect to the front end. It just struggled to tell me why." [S24 · HW4] · "Sometimes, when I read AI responses, some words are like hyperlink, I can read it but do not know what it represents for. So I spent more time to understand these professional nouns name." [S27 · HW4]

Use multiple AI models deliberately, for what each is best at. Strong

The multi-model workflow had been emerging in quieter form since HW3 and HW4; Project 2 is where it got articulated cleanly. S38's version is worth treating as the class's working definition of the practice:

"Using multiple AI models helped with splitting up tasks; for example using ChatGPT to brainstorm and get ideas then using Claude for a majority of the code and Gemini to debug certain parts. This helped with the model limits and balancing my AI usage, though one downside is that it might not pick up where you left off for other models." [S38 · Project 2]

Related:

"I found it really helpful to plan with cursor, but still found it better to get actual code with Claude over cursor." [S24 · P2] · "Using multiple families of ai models really helps." [S20 · P2] · "Switched from Gemini to claude." [S16 · P2] · "I recommend building ideas with GPT/Gemini and coding with codeX/ Cursor." (carry-over tactic from HW3/HW4, applied again here by multiple students.)

Feed the AI documentation and links, not just descriptions. Common

A direct carry-forward from HW3: pointing the AI at real sources consistently outperforms asking it to remember.

"AI is very good when you give it documents to reference such as API documentation." [S1 · P2] · "It helps so much to paste the link to the website for unique APIs so that the AI can parse it to better understand the nuances and help you code." [S14 · P2]

Understand the platforms, not just the code. Common (clearer than on HW4)

Deployment pain continued; Project 2 brought an explicit diagnosis. The class's advice: if you can't explain the platform to a friend, you'll struggle when it fails.

"You should understand the platforms that you are using to prevent repetitive debugging." [S29 · P2] · "One challenge was working with and understanding the supabase system I used. Also working between multiple platforms — GitHub, vercel, supabase." [S10 · P2] · "When you have to build product ready output having user challenges in mind, its hard to explain AI. It messes up the backend interlinking and fixing it step by step takes a lot of time." [S30 · P2] · "AI has not made setting up live websites easier yet." [S22 · P2]

Sometimes the right answer is to read the docs yourself. Some (but quoted unanimously)

By Project 2, students had hit situations where AI's help was actually slowing them down relative to reading the source.

"It wasn't the best to use AI to teach me how to make API calls since it would try to give me the answer many times, so I probably should've read the documentation myself." [S7 · P2] · "I found that Gemini was particularly helpful when I was creating my Python/Flask backend and provided very detailed explanations of the code." [S37 · P2] — the inverse example, where AI-as-tutor worked.

Free-tier limits bite: for models and for APIs. Some

"Free tier APIs really has a lot of limitations…" [S34 · P2] · "Free APIs for making graphs and visualizing data are challenging to use." [S35 · P2] · "Sometimes it might be slower if youre running an ai backend on render than local because a lot of the time free tiers have limited processing like 0.1 cpu or somthing." [S28 · P2]

AI still struggles with cross-screen, cross-file consistency. Some

A specific and persistent limitation for larger projects:

"When there are multiple elements or layers of screens, AI isn't very good at applying formatting changes to all of them consistently." [S18 · P2] · "Antigravity was great but it often created a whole lot of files and folders with barely any code in them. Even now, I don't think I fully understand what each of them do..." [S39 · P2] · "Chat doesn't like to deviate from its own designs." [S6 · P2]

The hardest part, for many, wasn't AI or code: it was the idea. One student (echoes HW3's S43)

"I think the hardest part of the project was finding something meaningful to make." [S4 · P2]

Worth noting that the project writeup itself pre-empts this: "Having trouble coming up with an idea? Talk to an actual human! Maybe even our TAs!"

Gemini is forming opinions across your chats: that's a design hazard. One student

"Gemini started thinking I had the same preferences for the code it wrote for this project and other things, even when I said I didn't (like not leaving any comments, which is for Google Sheets formulas)." [S17 · P2]

Memory across sessions is helpful, except when it isn't. Something to be aware of as models build up user-specific context.

Plan first: incrementally, with the AI writing docstrings or scaffolding you then fill in. Strong

The "plan first" theme that started in Project 1 reached its most mature form here. The standout technique, described by S5, is the one the class should carry forward:

"I found using Claude to explain the project and create a plan by initializing all the functions with doctrings and then using GitHub copilot to read each functions doctoring and implement it worked very well." [S5 · HW6]

Several students said similar things in different words:

"When you tell AI how to incrementally build it becomes really easy." [S3 · HW6] · "Starting small is the way to go." [S29 · HW6] · "Working through the steps in order, as suggested, was very helpful." [S9 · HW6] · "By prompting AI with smaller tasks and telling them what to do exactly, they tend to give more stable codes." [S35 · HW6] · "Detailed specs are really important here." [S20 · HW6]

Separate CRUD operations into separate prompts. Some

A specific modularity tactic for this assignment shape:

"I found that separating the different CRUD operations across different prompts was most effective." [S37 · HW6]

The "DHH sandwich": AI plans → you write → AI reviews. One student (but the best single framework in the survey)

Only one student articulated this, and they wrote it up beautifully. Highlighted here because it directly explains why HW6 scored so well on understanding:

"One really helpful thing I learned from this homework was how effective a framework I learned from David Hanson (DHH) is. Essentially, I had AI help generate my plan for a manually coded feature, then gave it my best shot without the AI's help, then gave it all the code I wrote and had it comment on it. This way, I really understood the code from the start, and any edits/improvements the AI suggested, I actually could directly understand why it was making those changes, because I knew how it impacted the lines around it." [S13 · HW6]

AI is noticeably weaker at database-related changes that ripple. Some

A specific and useful limitation the class surfaced: database logic is often touched from many code paths, and AI fails to propagate one change to all of them.

"AI seems to be noticeably worse at noticing how changes with a database might require changes in the rest of a program than it is for non-database related changes." [S17 · HW6] · "Generative ai is usually bad at sql so it takes a lot of prompt refining." [S12 · HW6] · "Database has more dependencies so it's less easy for ai or just agent to work on." [S42 · HW6]

AI became a genuine learning tool for SQL this time. Common (very positive tone)

This is the assignment where appreciation for AI as a tutor (rather than just a code generator) showed up most often and most positively.

"AI was a useful learning tool this time around. It was able to explain everything to me clearly and could communicate well why things were the way they were." [S24 · HW6] · "One thing I found challenging was the unorthodox structure of SQLite, but Claude and the documentation was helpful to understand it." [S45 · HW6] · "One thing that was helpful was uploading docs about SQL for ChatGPT." [S1 · HW6] · "I think the structure of this assignment made me interact more meaningfully with the code. I liked the involvement I had with this assignment." [S21 · HW6]

Know what you're committing to git. One student (worth passing along)

"It's about time to have a talk about what should be tracked in git. Your db likely shouldn't be unless you have a good reason to." [S22 · HW6]

Watch out when the tool tries to go beyond the assignment. Some

Multiple students using Cursor / Antigravity ran into the opposite of the HW2 problem: the agent wants to do too much.

"First time using Cursor and it went well. But it was always trying to do more and more, wasn't perfect for a assignment testing your fundamentals." [S15 · HW6] · "Antigravity is too good. I'm hooked." [S39 · HW6]

AI still can't reliably read designs from unclear descriptions. Some

"AI can have issues with formatting." [S18 · HW6] · "Description on UI is difficult understanding for AI." [S27 · HW6] · "AI is getting better at generating UI based on pictures." [S14 · HW6] — suggesting screenshots remain the fix.

A detailed README with a to-do list is the single highest-leverage thing you can leave behind. Dominant

This was the overwhelming consensus. The phrase "READMEs with a to-do list" or close paraphrases appear in well over a third of responses. The key refinement: don't just say what you did; list what's left.

"Yes I tried to clearly state in the read me the features that have already been implemented and created a list of future steps clearly defining what needs to be finished." [S5 · HW7] · "I created a guide document explaining the code and what additions or pieces are missing. I also added very in depth notes and comments throughout the code making it a very clear structure and understandable at most levels." [S10 · HW7] · "Yes, I put in the details in README.md including how to test locally, what functions are there now, what's the project's structure, and suggestions for the future dev." [S32 · HW7] · "Made a detailed README with all details of desired product and to do list." [S39 · HW7] · "I left some specific features out and listed them as starting points." [S45 · HW7] · "I unfortunately was not able to get as much done as I would have like during phase 1 because of a prompt timeout, so I added a to-do list in my reader to help give my partner a starting point." [S37 · HW7]

Ask AI to write meaningful comments as it writes the code. Strong

The companion to a good README is good in-line commentary, and students were explicit about prompting the AI to produce it.

"I asked the AI to write comments in the code. Specifically for tower defense, I asked it to make a clean way to add more tower classes and to tell me how." [S24 · HW7] · "I added documentation throughout the code with comments to explain what each part was doing." [S1 · HW7] · "I explained what features I'd implemented in the readme and made sure my comments were informative and placed wherever needed." [S7 · HW7] · "Made sure to comment all the functions." [S28 · HW7] · "I made a Documentation.me file that explains every code files' usage and purpose." [S47 · HW7]

Architect for extension: split into files and functions that future work can slot into. Common

The students who had thought explicitly about extension points came out ahead.

"Generated and reviewed a nice readme, tried to use best practice packages and break things into separate functions/files." [S31 · HW7] · "I tried to build a very basic but thorough implementation of a basic tower defense game so that the person could easily build upon it." [S4 · HW7] · "I asked [the AI] to make a clean way to add more tower classes and to tell me how." [S24 · HW7]

Document the prompts you used. One student (worth copying)

"I documented my prompts, known issues and things to add, the goal of the app, and made sure the AI coded in a readable way." [S18 · HW7]

The inheritor doesn't just need your code; they benefit from knowing how it got to this state.

A meta-note: "phases" in the README help the next AI as much as the next person. One student

"I included a plan in the read me with all the 'phases' I had planned for my game for AI to build incrementally." [S40 · HW7]

This prefigures the SPEC.md work of HW8 and HW9.

Brief free-text advice from inheritors, consolidated.

The class broadly agreed: clarity of README, quality of comments, and modular file structure made inherited code workable. The inverse made it painful. Specific items students called out as making their job easier or harder (paraphrased, because these came from many short responses across two survey questions):

• Easier: Clear README with file-by-file explanation; a to-do list of remaining work; inline comments near complex logic; consistent naming; a running deployed demo to sanity-check behavior.
• Harder: Large single files, cryptic variable names (the qp-for-"question points" complaint recurs in HW8), no comments at all, unstated assumptions about the environment, features described in the README that weren't actually implemented.

A detailed SPEC.md pays off: but getting it right takes judgement. Dominant, with real nuance

The most common single claim on HW8: the quality of the spec determined the quality of everything downstream.

"I found that making the spec very detailed from the start helped me to be able to save time later and led to a more desirable output." [S37 · HW8] · "Thoroughness and creativity go a long way in the SPEC.md file. Prompting precisely is incredible important." [S45 · HW8] · "AI works best when you outline a specific plan. It is extremely helpful for them to have the structure built up and only having to fill in the gap." [S35 · HW8] · "AI, like humans, work best when they have plans and are able to organize their own work flow." [S34 · HW8] · "The more specific at first, the easier it gets later." [S42 · HW8]

But the class also identified a concrete failure mode: too much specificity doesn't improve results, it boxes the agent in. One of the best pieces of writing in the whole dataset:

"I found I had to strike a balance between specificity and freedom in my spec. If given too much specificity, the AI could not do its job and the benefit of time saving was removed. If I wasn't specific enough, fixes to the code later on would no longer be simple syntax/functionality changes, but rather fundamental structural changes that the AI is not as good with." [S13 · HW8]

A related observation: underspecify deliberately when you'll want to iterate later.

"It was good at producing the result I described, but it might be helpful to be a little vague with the spec and fix the app later, for time's sake." [S17 · HW8] · "If you don't have something specific to say, don't write it in the plan." [S29 · HW8]

Acceptance criteria are read literally. Everything not listed will be skipped. Common

A specific, technical thing about the SPEC.md format that students learned the hard way:

"The acceptance criteria was taken very seriously and features mentioned elsewhere were not implemented." [S7 · HW8] · "AI is very strict about what counts as passing the acceptance criteria." [S18 · HW8] · "I found it a little challenging to get the agent to follow what was outlined in the spec.md rather than doing its own thing." [S10 · HW8]

Practical implication: if you want something, put it in the acceptance criteria, not in a paragraph somewhere else.

Design the user flow before writing the spec. Some (pointed)

Some students got to the end of a spec and realized the design was the missing step all along:

"Designing is an important step we may miss in this way if we want to control the design. I think it should come before writing the spec cleanly. When I realized after completing the spec, I would've made a better spec if i spent time on designing the user flow better." [S30 · HW8] · "I noticed that basic technical understanding is helpful and even necessary for a good spec. I failed to specify file structure. I hope I can obtain enough knowledge about architecture to be able to do so in future projects though." [S39 · HW8]

Use AI to help draft the spec itself. Some

Several students (one with a slight "I know this wasn't really allowed but…" caveat) pointed out that the SPEC.md itself is a document an LLM can help scaffold.

"I know this wasnt really allowed but have an llm brainstorm and write a general skeleton for spec md helped alot actually and helped it to be alot more detailed." [S20 · HW8] · "Asking chat what would be useful to include in spec.md made that step a lot easier." [S40 · HW8]

Conversational → agentic is a reasonable progression. Common (predictive of later HWs)

The best summary of the meta-workflow:

"I think going from conversational to an agentic build might be the best strategy for building with ai." [S4 · HW8] · "With projects that spans multiple files or have bigger complexity, I think using agentic development is a really good starting point and I think writing the spec out actually really helps with organizing your thoughts for what exact functionalities you want versus just going with the flow in increments in conversational AI." [S38 · HW8]

Spawn a new agent when context / code quality deteriorates. Some

Students hit context-window rot differently than in previous assignments; the agentic build ran long enough that context started breaking down.

"I found it very challenging to read and understand the code that the AI wrote. I had to create a new agent so that it could fix all the shitty named variables across the project. e.g. using variable name qp for 'question points' it becomes very hard to read when working with a large file." [S8 · HW8] · "The context is too short for a chat window, if we are plan to do a huge project, agent may not read SPEC to stop the whole project." [S27 · HW8] · "Try different agents." [S23 · HW8] · "I would try using different models to help AI unstuck itself." [S14 · HW8] · "Agents don't share memories." [S36 · HW8]

The real danger of agentic development: you stop reading the code. Some (the most important critique)

This is the single most self-aware observation in the entire HW8 dataset, and echoes through HW9 as well. It's worth quoting at length:

"I found this way of working caused me to not read my code at all. The only reason I understand what's happening at all is because I am fluent in Python. Spec to project was trivially easy, and I thought the finding bugs like this to be more efficient, but maybe in retrospect now, I would've preferred finding the bugs myself through physical testing rather than just trusting the bug existed and then trusting the AI solved it." [S24 · HW8]

"I did not like that it wasn't as conversational. a lot of the commits and file generation was kind of lost on me." [S12 · HW8]

The drop in the "how much of the code did you read" score (5.0 on HW6 → 3.2 here) is the data signature of this concern.

Writing a SPEC.md in a single 45-minute window felt too short. Some (instructor-actionable)

"Writing the Spec in only 45 mins was difficult to encompass everything." [S6 · HW8] · "When writing the SPEC, I was constantly thinking what I was missing." [S15 · HW8] · "Writing SPEC was hard." [S3 · HW8]

Platform setup was harder than coding. Strong

The single most repeated complaint on HW9 isn't about AI at all; it's about tooling. Expo, Android Studio, the live-reload loop, the emulator.

"Setting up expo and having the live updates work was a bit difficult at first." [S41 · HW9] · "The most difficult part was setting up the expo and the novelty of tools working with. The agentic part and prototyping and testing was not that difficult." [S15 · HW9] · "The actual coding part was easier for AI than figuring out the setup." [S18 · HW9] · "Just getting Android Studio to work." [S14 · HW9] · "Make the application run is hard for me." [S44 · HW9] · "It was quite challenging to go through the tutorials and learn how to develop an app for the first time." [S45 · HW9] · "Making a phone app was so different than making a web app — i was very surprised." [S12 · HW9]

SPEC.md still earns its keep: focus it on an MVP. Strong

Carried forward from HW8, with a new emphasis on scoping the spec tightly:

"Spec is the most important thing you can do with your time." [S13 · HW9] · "Writing a good spec made the process very easy, I spent most of my time thinking about the design of the app and writing the spec." [S4 · HW9] · "I found that writing a very very detail spec.md was generally extremely useful." [S1 · HW9] · "When writing the spec, focus on an MVP first." [S31 · HW9] · "The SPEC.md helps give clear instructions to the agents." [S5 · HW9] · "The spec file was really helpful." [S26 · HW9]

A counter-voice (represented, but unusual) questioned its value on this assignment:

"For this one the spec.md is less useful for completing it." [S42 · HW9]

And a caution: writing a spec for a domain you don't understand (mobile) is harder than writing one for a domain you do.

"I found it quite challenging to write a spec when I already wasn't entirely sure how things were working. Like I knew I needed to use a camera function, but had no idea how to write that into my spec other than literally and hope that is made enough sense." [S24 · HW9]

Plan + build + review: one agent builds, another agent reviews. Common (the most mature workflow described)

S30's description is essentially the end-state workflow this course was trying to surface, stated crisply:

"I made a plan after spec using cursor ai's plan mode and created a detailed plan first and then asked one agent to build and other to review. It got done in 3-4 agent prompts." [S30 · HW9]

Related specifics:

"Asking non-agentic model for specific debugging and then pasting its response into agentic model is helpful." [S29 · HW9] · "Having agent actually be able to test the output so that it can find and fix bugs on its own." [S39 · HW9] · "Adding rules to cursor is quite helpful." [S17 · HW9]

Managing agent context is now a recurring design problem. Some

S8's comment here is useful because it names an issue that will get larger, not smaller, as projects scale:

"I found it challenging that as the code base grew the usage for each agent became higher and higher. I would keep spinning up new agents in order to combat this but this doesn't seem sustainable once you have a large enough code base with enterprise code." [S8 · HW9]

"You stop reading the code": the HW8 warning returns. Some

"This might just be me, but whenever I write a SPEC or write something agentically, I naturally never look that deep into the code." [S3 · HW9]

Mobile-specific asides worth sharing. One student each

"It might be more efficient to have a website demo running first, with backend (database, apis, etc) all configured, than start everything from scratch on a mobile dev." [S32 · HW9]

"If you ever need custom icons, typically the ai generated ones arent the best." [S28 · HW9]

"3D graphics is still really hard for Gen-AI." [S6 · HW9]

An honest admissions worth sharing. One student each

"I found it challenging to improve and figure out where to better the human interaction and ux capabilities and features of the app." [S10 · HW9]