Calling an LLM API (part 2) · code organization · MP3 work time

We finished the AI chatbot: adding an LLM to your own page is the same fetch you already know, and once the function works the look is a separate problem. Then we wrapped up the basics with how to organize your code as a project grows: split data from logic into separate files, do not repeat yourself, and give numbers real names. The one habit to keep: when you learn a better way to write something, go back and refactor the code you already have. The walkthroughs are in the calling an LLM API slides and the code organization slides.

• One lightning talk, on how AI is being used to discover new drugs.
• Part 2 of calling an LLM API: the chatbot from last class actually answering, plus why our code looks different from OpenAI's own docs.
• Where an API key really hides, and why .gitignore alone is not the whole story.
• How to organize your code into separate files as a project gets bigger.
• A short set of everyday software habits: comments and TODOs, DRY, no magic numbers, testing.

Adding AI to your site is just another API call. The askAI helper takes your prompt, sends it with fetch, and reads the text out of the JSON reply. Same fetch, await, and JSON you already know. Get the function working first; the interface (making it look like a real chat) is a separate step you do afterward.

Why our code differs from OpenAI's docs. OpenAI's quick-start installs the openai library and runs on a server (Node.js). We are on GitHub Pages, which is pure front-end with no server, so we use a plain fetch instead of the library. Same idea, fewer moving parts. A library (or SDK) is just pre-written code someone packaged so a task is easier; you will recognize npm install ... in AI's output now.

Where does an API key actually hide? .gitignore keeps your key out of the repo. That does not make it safe. If the key is used in front-end JavaScript, it still ships in the page and anyone can read it in view-source. A key is hidden only when the code that uses it runs on a server the visitor cannot see (for example a Vercel serverless function). GitHub Pages has no server at request time, and a GitHub Actions secret only exists at build time, so neither hides a key from a live fetch.

You usually do not need the biggest model. A small, cheap model handles most class work. Bigger reasoning models cost many times more per call. Model names and prices change every few months, so check the provider's models page before you build.

AI often does not know what model it is. Ask a chatbot "what model are you?" and it may confidently name the wrong one, because newer models are trained partly on older ones. Do not trust a model's answer about itself; check the code that calls it.

Organize your code: separate data from logic. One giant script.js gets hard to find things in, easy to break, and hard to reuse. Split it: put your data in a data.js, keep the logic in a main.js, and import only what you need. The payoff comes later. When you outgrow a hard-coded list and want a real database, you swap the data source without touching your main logic.

Small habits that pay off.

• Comments and TODOs. A // TODO is a bookmark for where to pick up later (handy when you run out of AI credits mid-task).
• DRY (Don't Repeat Yourself). When you catch yourself writing the same thing twice, wrap it in a function or a shared file.
• No magic numbers. A bare 0.06 in your code means nothing to you (or to AI) a month later. Give it a name like TAX_RATE.
• Write for humans, start small. Build the simplest version that works, then improve it. Ask AI to test your business logic and cover edge cases; the visual parts still need your own eyes.
• Refactoring is normal engineering. Restructuring working code to make it clearer is how you get better at this. It does not mean you did the first version wrong.

1. Finish MP3, your API-powered app. If you have not, read the MP3 assignment, create a new public repo first (lowercase, hyphens, named for what the app does), and write your PROPOSAL.md. Final is due Sunday, 7/12. If your API needs a key, protect it with config.js and .gitignore, and deploy the key-hiding version on Vercel.
2. Finish the ai-chat exercise if you have not. In your oim3690 repo, make an ai-chat/ folder with index.html, script.js, and config.js. Add config.js to .gitignore and commit that first, then put the class key in config.js. Make one successful call, then let AI turn it into a small chat page. Run git status and confirm config.js never appears. (The shared class key is deactivated next week, so do this soon.)
3. Start your final project proposal. Read the final project instructions, draft a PROPOSAL.md (what it does, who it is for, and what it deliberately does not do), and make it public by Tuesday, 7/14. We pair up to review each other's proposals on Wednesday, 7/15.
4. Do the code-organization exercise from today's slides. In your oim3690 repo, make data-app.html plus a js/ folder with data.js and main.js. export an array from data.js, import it into main.js, and link only main.js with <script type="module" src="js/main.js">. Build a tiny version by hand, then let AI fill data.js with real data and render it in main.js.
5. Keep your weekly logs current (logs/wk07.md, logs/wk08.md). New this checkpoint: your AI-collaboration note must be specific. Name one piece of AI output you did not accept as-is, what you changed, how you knew, and the commit where the change landed. MP3, the logs, and the practice pages are all checked by Checkpoint 4, due Sunday, 7/12.

While you are at it, look back at MP2 or MP3 and ask whether one big JavaScript file could be split, or any repeated code pulled into a function. That is the "review your own code" habit from today.

Next class (Monday, 7/13): the MP3 Final Showcase and the kickoff of your final project.