Learning to Prompt an AI

For an AI-generated analysis of this blog post created by Google’s NotebookLM service, click on the audio player below.

I’m working on a moon phase calendar for iOS devices (iPhones and iPads). Yeah, yeah, yeah. A bazillion such apps are available on the Apple App Store, but I’m not looking for something to sell, even though the app already looks sellable. I want to learn how to use AI to help me write apps. A moon phase calendar app is perfect since there are some sneaky issues when going from a simple to a pro-grade app for astronomical calculations.

Today’s task was tackling one of those sneaky issues. Since the standard, compute efficient way to determine the lunar phase for a particular date calculates the Moon’s luminosity at noon GMT, there is a 99.93% certainty the Moon will not be at 100% luminosity, i.e., a full moon at noon. That’s where a threshold comes in, with 99.75% illumination enough to call the Moon full. The same difference is valid for a new moon – 0.25% luminosity or below, which is good enough, pro-grade good enough, to call the Moon at its new phase.

While Claude 3.5 Sonnet and I worked through finding a solution (calculate the luminosity at the two boundary times of a day—00:00 and 23:49), I had an interesting moment with the AI that I consider more impressive than fixing the sneaky bug.

Me: Perfect. Now for a few warnings. In the private function createCalendarGrid() in the MoonPhaseViewModel, we get a warning that reads, “Initialization of immutable value ‘suffixDays’ was never used; consider replacing with assignment to ‘_’ or removing it”

Claude: Ah yes, we declared suffixDays but never used it in the function. Since we’re not using the calculated suffix days, we can simply remove that code. Here’s how we should update the createCalendarGrid function:

Claude then provides an update to an entirely different function – calculatePhaseForYear().

Me: We need to update the createCalendarGrid function, not the calculatePhaseForYear function.

Claude: You’re right, let’s update the createCalendarGrid function instead:

Claude then correctly updates the correct function.

Me: What was the root cause of the error in your processing that made you update the incorrect method, calculatePhaseForYear, rather than the correct method, createCalendarGrid? Is there an improvement to my process of creating a prompt for you that would avoid this issue? While it rarely happens, it does every once in a while.

Claude: This is a great question about improving our communication and accuracy. The root cause of my error was:

1. When you mentioned the warning about suffixDays, I quickly searched through the codebase and found the first instance of something that looked similar, rather than carefully verifying it was the exact function you mentioned.
2. I failed to properly verify your exact quote: “In the private function createCalendarGrid() in the MoonPhaseViewModel” before proceeding with my fix.

To help avoid such errors, here are suggestions for improving prompts:

1. When referencing specific code, it would be helpful to provide:

   Function name: createCalendarGrid
   File: MoonPhaseViewModel.swift
   Error/Warning message: "Initialization of immutable value 'suffixDays' was never used..."

2. Or even better, include a small code snippet showing the problematic section:

   // This section in createCalendarGrid has the warning:
   let weekdayOfLast = calendar.component(.weekday, from: lastDate)
   let suffixDays = 7 - weekdayOfLast // Days to append

3. When the codebase has multiple similar variables or functions, explicitly stating which instance needs to be modified would be helpful.

These improvements would make it harder for me to misidentify the target of the changes and help ensure more accurate responses.

Me: Learn something new every day. Thanks!

Claude: You’re welcome! This kind of feedback and discussion about improving our interaction is invaluable. I find that even small refinements to how information is shared can make a big difference in accuracy and efficiency.

It also highlights an important principle in software development – when fixing bugs or warnings, it’s crucial to verify exactly where the issue is occurring rather than jumping to conclusions based on similar-looking code. A few extra moments spent confirming the precise location of an issue can save time and prevent introducing new problems.

Would you like to continue addressing any other warnings or aspects of the Moon Calendar app?

Me: Not today. We will continue refining the app tomorrow.