Tech Note: Cursor & Github for MBA’s

This note will help you get going with professional-grade version control on Github and an AI-forward IDE (integrated development environment), Cursor.

This note was written for learners using the Case Library on this site where the cases are implemented on JSFiddle. While JSFiddle is excellent for working on small-ish bits of code and chatGPT is great at accepting snippets of code and returning snippets back.

However, you get somewhat bigger sets of code, you’ll probably find that an IDE (integrated development environment) suits you much better. For example, if you’ve completed the case ‘From Design to Database‘, then odds are you’re already getting close to that point. What you’ll be graduating to with this tutorial is a ‘tool chain’ which is very standard for working developers. As such, it also accommodates code collaboration between individuals- so if you happen to need that as well, then, great news, you’ll be learning that, too. In terms of the product pipeline, you’ll learn about items #1 and #3 below (maybe I’ll cover automated tests in a future note).

The idea is for you to go along and actively do all this, so we’ll take it one thing at a time with the sections you’ll find below.

Getting on Github

Why is this first? Pretty much, no matter what, if you’re getting serious about some code, you’ll want it in version control. First off, you need for the same reason you need it on a Google Doc, etc. And, as you may have noticed, code breaks a lot and you’ll need these ‘clues’ about what changes happened when. More so, and on a happier note, comfort with version control frees you to confidently experiment with your code.

Setting up a Github Account and Learning the Basics

Github is a serious service and, as you would expect and hope, they already have a tutorial about how to create an account and the core essentials of version control:
Github Starter Tutorial

The only thing I’ll mention about it is that if you’re coming here as a solo learner/new coder, don’t worry too much about their material on pull requests: those are 100% best practice if you’re on a team, but, for our purposes, that emphasis may not be particularly useful to you unless you’re currently collaborating on your code.

After you finish the above, you should be able to:

1. Create and log in to a Github account
2. Create a repository
3. Create a working ‘branch’ of a repository and edit it
4. Merge (via Pull Request or other) changes you’ve made to your branch into the ‘Main’ branch

Making it all a little Easier on Yourself

We’ll actually be connecting directly to Github from an IDE (Cursor) in the next section. However, things still get goofed up and confusing and, in actual practice, I’ve found students benefit from setting up and running Github Desktop. This is a basically just a local app that you can make aware of the code you’re working on locally, how it relates to your repository, and, from there, it can help you make updates. It works on Mac and PC, and, if you’re coding, etc. on a platform other than that, you’re probably beyond what I can teach you. You’ll find it here:
Github Desktop

I would download it and then create a local version of the project/repository you set up in the last step. That will require three steps. First, download and install the client app (see link above). Second, authenticate to your Github account. Third, use the ‘Add’ button to clone the practice repository you already created (Hello World, etc.).

It’s going to ask you to set up a place locally on your machine because, well, it’s Github Desktop and it’s for working on your machine while doing version control on Github. From there,

1. make a change to the file (on your machine)
2. follow their prompts to stage and commit the change
3. observe the change on the web-based version of Github
   1. note: make sure you’re viewing the right branch on Github and/or be sure to merge your change into main

Get stuck? Do not fear- ask a reasonably specific question and chatGPT will have an answer for you.

Getting on Cursor (from JSFiddle)

In this section, we’ll take the sample code from the case Design to Data Model and port it over to a repository on Github, branching it also to your local machine to use in the Cursor IDE. This will put a few things into play for you, and some of them are a little idiosyncratic to Window vs. Mac, etc., but we’ll just take it one step at a time.

Step 1: Download Cursor, Install it, and Do their Tutorial

You can download cursor directly from their site. Install it, open it, and they’ll ask you to step through a little ‘product tour’ tutorial. As annoying as those generally are, this one is pretty good. They’ll probably prompt you to authenticate to your Github account- though we’ll also step through that next.

Step 2: Update Your Hello World Repository

If you close all the files and projects you have open in Cursor (or close it and restart it), you’ll see a menu like this:

Again, if you’re lost in the various stuff it had you open during the install you can just close it and restart it to get to this screen. Once you’re there,  you’ll click ‘Clone Repo’ (the middle button highlighted in blue) and then click where it says ‘Close from Github’ in the top middle menu. This will show you a list of all your repositories (or prompt you to log in to Github if you haven’t). Choose your Hello World repo and follow the prompts to ‘clone’ it somewhere on your local file system (on your computer).

At this point, the left menu should be showing your files, the Readme, for example. Try making a small edit and then use the VCS (version control system) menu on the left to synch it to your Github repo.

Note: You have to leave a commit message or the commit to your repo won’t work- these commit messages are considered to be such a good habit Github doesn’t even let you not to do it!

When you go to Github on the web, can you see the change?

If not, make sure you’re on the right branch (did you push to Main or a different branch via Cursor)? If it’s still not working, this is what Github Desktop is useful for- see what it says the status of the commit is and the app may make it a little easier for you to close it out. Don’t worry about switching- both Cursor and Github desktop just act as clients to the Github service itself.

Step 3: Creating a ‘Real’ Cursor-Accessible Repository

Now, we’re going to create a ‘real’ repository in the sense that it has working code- specifically, the code from this case: From Design to Data Model. I’ll post the working repo at the end of this step, but, if you’re going to be developing with Cursor, my recommendation is to follow along and create your own version from scratch in order to get comfortable.

First, we’ll create the repository. While you can create the repository directly from Cursor, I’ve found it’s less confusing for students to create the repo directly on Github and then clone it onto their machine. While it doesn’t make a huge difference, your local OS will often create distracting junk files, plus by using the native interface on Github, you have greater transparency to the process. Head to Github (via the web), click on Repos, ‘new’, and you should see something like this you can fill out to create your own repository:

If you get stuck there, just ask chatGPT or hit up one the many excellent tutorials specifically about Github- just don’t get lost in the details (all we’re doing so far is creating a new repo).

Second, access the ‘Add file’ menu which you see below.

Before we add our ‘actual’ code files, there is ONE KEY step you won’t want to ignore and it’s the ‘.gitignore’ file. This tells Github itself and the various Git clients (Github Desktop, Cursor, etc.) what files to not worry about. This is important to avoid having your OS add system files that may confuse or break the process. The good news is that you can just prompt chatGPT for the contents of this file: just ask it something like ‘I need a .gitignore file for developing vanilla JS on [mac, windows]’, use the Create New File menu on Github to add it, and paste in the contents. The repository we’re playing with here is public and you can see an example there: GH Repo.

Next, we are just going to reproduce all the content from the JS Fiddles and then refactor and integrate it on the next section about using Cursor. We’ll do all this on the main branch. From the first fiddle (Parts Search), create a .html, a .css, and a .js from the respective panes on JSFiddle. Prefix them all with something consistent, like ‘parts-search.html’, etc. Then, do the same thing with the second fiddle (Part Detail and Review). You should end up with a set of files that look something like what you see below on the repo:

Last step: we’re going to clone the repo on your local machine so that you can use the Cursor IDE on a set of local files. Since it’s just you, we won’t branch- we’ll just develop on Main. To do this, open Cursor, create a new project (command + n) then select the option to Clone a repo. You’ll have an option to do it from Github (do that) and then click the repo you created in the last step. Find the spot you want your local files and then finish. It should then give you an open to open the repo and it should look something like this:

As always, if you get stuck: try with Github Desktop and then hit up the tutorials and chatGPT.

Next, we’re going to look at how to clean up and refactor these files so we can actually get them working on our local machine vs. JSFiddle.

The DX of Cursor!

DX stands for ‘developer experience’ and you’re about to have the best one any developer has every know, yes, seriously. It’s Cursor’s AI-forwardness that makes it so groundbreaking, and it’s no surprise that this tool (est. 2022) is relatively new. We’ll warm up by rationalizing the files in our new repo and then step through the tool’s key modalities. These have a lot to do with context: what do you want the IDE to consider and where do you want it to act? This is the idea behind the classic soup example with chatGPT: ask it to give you a recipe for the ‘best soup’ and it will give you something; tell it more about what you like and it will give you something better. (I don’t like soup.)

The bad news is that the files in our repo make no sense for anything outside of JSFiddle, but the good news is that Cursor will make it easy for us to fix that. We’ll start with the HTML files, the core building blocks of our View/UI. When your web browser finds a site, the first thing it does hasn’t changed in 30+ years: it looks for a file called ‘index.html’. We’ll start there.

For now, all we want is for the View/UI components to work the way they did back on JSFiddle. We’ll start with Cursor’s most powerful mode: ‘agent’. As you probably know, the basic idea with an agentic UX is that you’re not spelling out exactly what you want done; rather, you’re explaining to the AI what you want to have happen and then, like a good manager, seeing how it does with that and if it needs help.

As such, here is my starter prompt: “These files were part of two JS Fiddles and I want to rework the HTML and CSS here to full standard files, meaning that the whole UX starts with an index.html file and everything else proceeds from there.” I do this by opening chat (ctrl/cmd + l), selecting agent mode for the chat, and supplying the prompt above. You can see what I get back in the screen shot below.

To test, you can use Cursor’s ‘Run’ command, which will launch a browser or you can simply open index.html from your browser since this is just ‘vanilla’/plain JS which runs natively in a browser.

I will freely tell you that in this round of agentic prompting I was expecting to update just the HTML and CSS and then deal with the JS, but Cursor took the initiative and fixed up the JS as well. After patting myself and Cursor on the back, I asked it to clean up the old, unused files, putting them in a directory called /old. Everything broke. We managed to get back to everything working by stepping through the cases around the review functionality a few times (no user, user but not review, user and a review). You can see the current state of the code on this public Github repository: 2UhDataModel.

The moral of this story is that while having an AI agent to update your code is a lot more awesome than not having it, it’s still not perfect and you still have to put in the work to clarify your intentions and iteratively check if the agentic coding is actually headed in the direction you want. While this interaction was pretty good (by my standards), I’ve also had a few instances where I had just had to revert all the changes it made and just take things more step by step. This bring us to our next topic, the various ‘modes’ Cursor offers: Agent, Ask, and ‘Manual’.

Let’s say our next item is enabling actual orders of these HVAC parts, an epic like: “As Trent the Technician, I want to order a part so I know when it will arrive and I can plan my next steps with the customer.” We could use the ‘Ask’ mode to help us think about how to approach this with a prompt like: “Next I want to enable a standard shopping cart functionality where users can add items or buy now, and also check out. How would you approach that?” You can ‘fork’ (copy) the repository and see for your self, but essentially what Cursor gives me in this case is a detailed explanation (including sample code) of how it would modify and augment the HTML, CSS, and JS to afford this functionality. I can ask further questions or just say ‘do it’.

Let’s say we’re in one of those ‘it’s just not working’ situations with the agentic mode or we just plain know what want to happen and don’t want to potentially conflate the changes with other changes the agent might undertake (yes, we’re going to micromanage the AI). Let’s say we think the buttons on the part detail page look inconsistent with the rest of our UI and we want to see if the AI has an easy answer on fixing that.

This is sounds like a job for Manual mode on Cursor. Here, we can also specify the context of our question- in this case I’m going to specifically reference detail.html and main.css. While this codebase is relatively small, this feature is particularly useful as your codebase grows.

I prompt it: “Please make the two buttons more visually consistent with the rest of the site.” Here’s the result I got, which I think looks better.

I wish I could tell you that neatly came together in Manual mode, but it didn’t. Was it me? The AI? I’ll tell you what happened and you can be the judge. On the first prompt, Cursor went in and made the changes but they didn’t work. This was because it hadn’t referenced main.css in detail.html. This seems like an obvious oversight (so, I blame Cursor) but also it’s kind of funny to have two CSS files for a small project like this- so I also went back to agentic mode and consolidated the CSS files. As needlessly messy as this might sound, I think it’s actually a pretty good example of how you have to strike a balance between being aware of your code, focusing your intent, and iteratively giving your AI the right context.

There’s one last DX on Cursor that’s even more contextual- you reach it with cmd/ctrl + k and you can even highlight specific chunks of code. Let’s say I want to do something particularly arbitrary like make those two buttons above bright green. I would open detail.html, highlight the applicable HTML, open the generate (cmd + k) dialog and make the change.

Doing so, I get this update which I can accept or reject:

Is that everything about Cursor? No, but it is the big fundamentals I think you’ll need to get started. From there, I think you and your AI coding partner will find your way just fine. Crucially, it is still important to follow a disciplined process where you:

1. Focus your design intent- because the current versions of AI can’t read your mind
2. Unpack what you want to do in codeable steps, or at least read carefully what the AI is telling you it’s decided to do so you can reprompt it … promptly
3. Effectuate between major stack components- because the AI doesn’t understand the larger economics of your code and platforms. For example, if this team had standardized on a standardized CSS toolkit like Tailwind CSS, we’d want to prompt the AI to use those classes.
4. Iteratively code, test, and debug- now more than ever, being able to link your intent in step #1 to a repeatable set of tests will help you and the AI do better, more predictable work.

End Notes on Cursor, etc.

There are a few things you may or may not run into, but I figured I’d make a quick list based on my work with students:

1. Don’t let Cursor’s light grey buttons (in the chat) fool you: you *can* click them, even though the grey is so light it kind of suggests ‘offline/unavailable’.
2. If you’re testing your code locally by opening it in the browser, you need to make sure you’ve saved (cmd/ctrl + s) your changes so they’re actually written to the files you’re opening. This is the same thing as MSFT Word: even if it autosaves, it’s not actually writing what you’ve done to your MSFT Word file until you save.
3. There are a ton of options to revert changes on Cursor itself, even before you use version control.

Automating Deployment

This is the last section and, take heart, it’s amazingly easy. There are a lot of good options out there, but Amazon’s Amplify service is particularly well put together, and we’ll use that for example purposes.

Step 1: Create an AWS Account and Add the Amplify Service

Create an account on AWS. This is pretty straightforward and, to the extent it isn’t, it’s better documented/AI’d elsewhere. What I will say is that, for current purposes, the ‘Basic’/free tier of support will be fine.

This shows the current interface for adding the Amplify service:

Step 2: Configure the Amplify Service & Deploy

I don’t want to sound like an AWS fanboy, but this part is so easy it blows my mind. I wanted to include a whole section on how hard this used to be, but my collaborators warned me off of it. First, you’ll need to authenticate t0 Github (see below).

Following that, you can get on the rails by just accepting the defaults and going to deploy. The service will show you the deployed URL, which you can visit:

From there, every time you synch changes to Github, it will trigger an update to that repository.