End of Semester Reflection

This post is my response to the end-of-semester CS 480 reflection prompts. I focused on what I learned from Nick Morgan's visit, how I would redesign this course next year given the tensions we experienced, and what I will do this week to move my Nogramming project forward.

What I Took Away From Nick Morgan's Visit

My biggest takeaway from Nick Morgan's visit was his opening mindset: "I don't know... yet." One of professors, Dr. Lam, he has emphasized that phrase so hearing it from someone else was nice. It is something that I believe in and internalize, but it is easy to forget when you are in the middle of a project and feel like you should have all the answers. That mindset is a reminder that it is okay to not know how to do something right now, and that learning and discovery are part of the process. It also encourages a growth mindset, where you can approach challenges with curiosity and openness rather than fear of failure. If you know me, you know if I hear someone else saying something like "I don't know how to do this," I will probably say "yet" to encourage them to keep going. It was nice to hear that sentiment from an industry expert and it set a good tone for the rest of the visit.

I also liked his programming mindset that every engineering decision is a tradeoff. No system is optimized for everything at once. You choose what to optimize for and what to accept as a constraint. That framing made me think about software quality in a more realistic way. Strong engineering is not perfection; it is making deliberate choices that produce the best value for the context.

The part that helped me most was his security mindset: observability matters. He separated this into blue-team and red-team thinking.

From the blue-team (defense) perspective, the key question is how to keep an application reliable when users do unexpected things. That includes understanding the order of magnitude your app or algorithm can handle, limiting inputs to what you actually expect, and logging anything outside those expectations. It also means designing for failure recovery and not just happy paths, for example deciding what happens if a user never receives a confirmation email and cannot complete the normal flow.

From the red-team (offense) perspective, the question is how someone could force behavior the creator did not intend. That means trying unexpected inputs through boundary testing and fuzzing, forcing app flow by skipping steps or going directly to URLs, and testing whether business logic can be manipulated, such as changing prices or bypassing validation checks.

Another valuable takeaway was his discussion of whether AI makes security better or worse. The answer is both. AI can help teams do faster security sweeps, run automated review tools, and move from detection to resolution more quickly with increasingly agentic tooling. At the same time, attackers get similar advantages, and risk also grows through packages, libraries, and external services that teams depend on.

Finally, he highlighted new attack surfaces created by AI systems themselves, especially agents and harnesses. As we rely more on these tools, we need stronger guardrails around them, including isolation approaches like sandboxes, containers, and virtual machines. Overall, I left with a more practical view of security: think in tradeoffs, build for observability, defend expected behavior, test adversarial behavior, and treat AI as both a capability boost and a risk multiplier.

If I Taught This Course Next Year

This class was valuable because it was experimental, and I would keep that spirit. At the same time, I would shape the semester with more visible structure so students can make meaningful decisions without getting lost in open-ended ambiguity.

What I Would Keep

• Industry guest visits. Hearing active practitioners explain current tools, tradeoffs, and constraints made the learning feel real and current.
• Experimenting with different technologies. I liked that we got to try out different models, agents, and tools throughout the semester. It helped us get a feel for what kind of tools are out there and how they work in practice.

What I Would Change

• Less writing and reflections based on readings. I found the initial weeks of reading and reflections very interesting, but as the semester went on, I felt like I was completing the assignment rather than learning from it. I would reduce the number of reflections and focus them more on applying concepts to our project rather than summarizing readings.
• More structured project milestones. I would break the project into clearer phases with specific deliverables and checkpoints. This would help students make concrete decisions and see progress without feeling overwhelmed by open-ended work.
• I would add a ethical considerations component. Given the power of AI tools, I think it would be valuable to have a module on ethical implications, bias, and responsible AI development. This could include discussions, and reflections on how to build AI systems that are fair, transparent, and aligned with user values.

Proposed Course Shape

If I were teaching the course, I would structure it in four phases:

1. Foundations and framing (weeks 1 to 3): tooling setup, short labs, and examples of high-quality decisions and documentation.
2. Guided project launch (weeks 4 to 6): client discovery, scoped planning, and first working vertical slice.
3. Independent build with checkpoints (weeks 7 to 12): implementation sprints, weekly demos, and decision memos.
4. Integration and reflection (weeks 13 to 15): polish, reliability/security pass, retrospective, and public reflection posts.

That structure keeps experimentation, but gives enough guardrails for students to keep momentum and learn from decisions rather than just deadline pressure.

What I Will Do This Week for Nogramming

This week I will focus finish up on gathering all the images from my camera roll that I want the models to create. I will also start writing the prompt for the model to create the images. I will need to be specific about the style, composition, and content of the images to get results that fit my vision for the project. I will also experiment with different models and settings to see which ones produce the best results for my use case. Finally, I will start organizing the generated images and creating the scrapbook.

~ Shree