Course intro, GitHub, and your first deployed site

Today was setup day. We went from an empty GitHub account to a page live on the public internet, and along the way we spent a long stretch off the slides working out what an AI agent actually is. That discussion is written up below. The habit to keep: put something trivial online first and confirm it works, then write the real content.

• Who I am, what this course is for, and what it is deliberately staying away from.
• An open discussion of what an AI agent is.
• How the course is graded: checkpoints every two weeks, weekly logs, project walkthroughs, the final project, and participation.
• The hands-on: create a repository, clone it, write a file, commit, push, turn on GitHub Pages, open your live URL.

We built this on the board in class, from your answers. Here it is written down, with the parts I added.

Your definition of a chatbot: something with a script inside it, close to a decision tree. It answers questions. It waits for you at every step.

Your definition of an agent: something that can autonomously do work on its own. It completes tasks. You give it context and a direction, and it goes and does several steps by itself instead of stopping after each one. Someone added that an agent carries a specific set of instructions and a memory. Someone else pointed out that both of them sit on top of a foundation model.

That last point is where to start, because everything else sits on top of it.

Every one of these tools sends more than your question. When you type "where is Babson College" into ChatGPT or Claude, that sentence is your user prompt. Along with it goes a system prompt you never see: a long block of standing instructions telling the model who it is supposed to be and how to behave. This is why tokens get consumed faster than you would expect from the length of your own question. You are paying for the instructions too.

They also carry context and memory. The context window is how much information the model can hold in one pass. Memory is what it has stored about you across conversations. Both ChatGPT and Claude have a settings page where you can read what they think they know about you, and it is worth looking at once.

And they can use tools. The first time you used ChatGPT it probably could not answer a question about last week, and it was bad at arithmetic, because it had no tools. Now it has a browser, and it can write a small Python program and run it to get an answer. That is the biggest single change.

So my answer to the question we opened with:

The chatbot products you already use carry a system prompt, a context window, memory, and tools. A few years ago those capabilities were most of what people meant by an agent. The useful question now is a different one: how far will it go on its own before it comes back to you?

That is the loop, and it is what still separates them. An agent is given a task and keeps going until it is done. It tries something, it fails, it reads the error, it tries a different way. The original version of this idea is called ReAct, short for Reason and Act: the model reasons about what to do, takes an action with a tool, reads the result, and reasons again. Anything that stops after one failed attempt is doing something else.

The diagrams I pulled up came from a live search, so you can find the same ones. Search "agent loop" and "ReAct agent" and look at the images. Every version shows the same shape: a model in the middle, tools and outside data around it, and an arrow going back to the model before an answer comes out. That returning arrow is the idea.

Why coding is where agents landed first. These explain the shape of this entire course.

1. Code is easy to check. You can run it. It either works or it does not. Most tasks you might hand an agent have no such test, so nobody can tell whether the agent did well.
2. The tools already existed. Decades of command-line tools have been sitting there, each one doing a single job with a text interface. A model can call them the same way a person would. Nothing had to be invented.

For the same reason, an agent is good at the thing beginners find hardest: when you change one line, knowing what else in the project has to change to match. That is a limit on how much a person can hold in their head at once, and it is much less of a limit for a model. What an agent still cannot do is on the slides, under What Actually Matters Now.

If you want to go deeper into how the models themselves work, that is a different course: Deep Learning in Business covers the neural network side properly.

Reading, if you are interested: MIT published its report on AI and education in August. It is the most realistic thing I have read on the subject. The course takes two lines from it: AI detectors do not work and should not be used, and because AI is strong at coding, instructors can now assign projects that are far more ambitious than before. That second line is why this semester is built around projects.

When you type an address and press Enter, the page is not on your computer. Your browser sends a request to a server, which is a machine sitting somewhere, usually rented from Amazon, Microsoft, or Google. The server sends back files: .html, .css, .js, images. Your browser takes those files and draws the page.

That is it. A website is a folder of files that a server hands over when asked.

For everything you build in this course, the server is GitHub. You put files in a repository, and GitHub serves them to anyone who visits your URL.

Thursday is mostly this: everything that happens between pressing Enter and the page appearing, in proper detail, plus a first look at DevTools.

1. Create a repository on github.com/new. A repository is a project folder that GitHub keeps track of.
2. Clone it. Cloning copies the repository from GitHub down to your own computer. Use the green Code button, then Open with GitHub Desktop.
3. Edit. Open the folder in VS Code and change a file. A dot appears next to the filename until you save it with Ctrl+S (Windows) or Cmd+S (macOS).
4. Commit. A commit is a saved checkpoint with a short message describing what changed. Committing does not lock anything down permanently. You can always go back to an earlier commit, which is the entire reason to make them.
5. Push. Committing saves the checkpoint on your computer. Pushing sends it to GitHub.

Then GitHub Pages takes over: Settings → Pages → Source: Deploy from a branch → main / root. Give it about a minute and your URL is live.

Commit and push are the two you will use every week. The order of the first two steps is not fixed, and on Thursday we start from the other end: make the folder on your own computer first, then push it up to a repository. Both directions end in the same place.

Your repository name has to be exact. For your personal site the name is <your-github-username>.github.io, spelled precisely, all lowercase, with nothing extra. This name is special to GitHub. If you name it anything else, GitHub treats it as an ordinary project and serves it at <your-github-username>.github.io/thatname/ instead of at your root URL. Someone hit this today. It is a two-minute fix when you catch it, and a confusing week when you do not, so open your URL now and check.

Filenames: lowercase, and hyphens where you need a space. Write my-page.html, never My Page.html. Spaces in filenames cause problems on the web that are tedious to debug, and capital letters cause problems the moment you move between Windows and a server. Start the habit today and you will never think about it again.

Deploy something trivial first. The page we put up in class contained the single word hi, and nothing else. That was on purpose. It separates two questions. If hi shows up at your URL, your pipeline works, and any problem after that is in your file. If you write a whole page first and get a 404, you have no idea which half is broken.

• Course site: oim3690.github.io is the go-to place for everything except deadlines, which live on Canvas.
• GitHub Student Developer Pack. Apply now, because approval takes a few days. It gives you more Copilot usage and free domain registration, which you will want later in the semester when you put a real domain on your site.
• Paul Graham's essays. The line I put on the slide: people who want to start something one day often think they should be studying economics or finance, and they should be learning how to build things.

1. Get your personal site live at <your-github-username>.github.io, and open the URL in a browser yourself to confirm. The single word hi is enough. If you have the time and want to go further, slide 36 walks through having Copilot write the real page, which is the part we ran out of time for. Describe what the site is for and who it is for, keep everything in index.html, and read what comes back before you accept it.
2. Submit your site URL on Canvas. This is how you get access to the parts of the course site that are open to enrolled students only.
3. Read the syllabus. It is on the course site.
4. Finish the pre-course survey if you have not already.
5. Apply for the GitHub Student Developer Pack if you have not. Approval takes a few days, so start it now.

Thursday we will also start your oim3690 course repository, which is where your exercises and weekly logs will live. If something is broken, send me a message before Thursday or find me at the start of class.