GitHub Workflow and AI-Powered Feedback Analysis

  • Learn GitHub Core actions for code management and collaboration
  • Connect to external AI services in a safe and secure manner
  • Use AI to synthesize feedback from multiple sources into actionable insights
  1. Stakeholder Tracker: A simple system to organize your stakeholder research 
  2. Feedback Analyzer: An AI-powered tool that finds patterns and priorities across all your collected feedback

You’ve gathered feedback from friends and family, challenged your thinking, and conducted stakeholder interviews. 

In the Vibe Coding Your Own Founder’s Tookit lesson you built your Founder’s Toolkit with a Feedback Storage module and used localStorage to save your data between page refreshes. 

In this lesson, we’ll learn how to add AI feedback to our Founder’s Toolkit, to help synthesize all the feedback we’ve collected.  

But first, you’ll learn how to improve your GitHub skills. Professional developers use branches and pull requests to experiment safely and collaborate with others. These skills will serve you throughout your entrepreneurial journey.

Advancing your GitHub Skills

Before adding new features, you’ll learn how professional developers work – using branches to experiment safely and making code commits to save progress and pull/push requests to merge code. 

This is important knowledge that will help you throughout your journey with your business app. Most likely you will be collaborating with other students for this project and in real life. 

All of this is done via Git and to understand, let’s dive into some concepts.

Git is a version control system that tracks every change you make across your code. It lets you do things such as:

  • Experiment safely: Try new features without risking your working code
  • Undo mistakes:  Go back to a previous version if something breaks or you changes your mind
  • Collaborate:  Work with others without overwriting each other’s changes

Branches

Let’s imagine you’re writing an important document. Instead of editing your only version, you decide to make a duplicate document to experiment with. If the changes work, you merge them. If not, you still have the original and the new document with the changes that didn’t work. 

Git branches in GitHub work the same way. Here is how it works:

  • main branch – Your “official” working version
  • feature branch – a copy of the main branch where you create a new feature or make any changes. You can name this branch whatever you’d like but we recommend to be descriptive so you remember what the intention is.
  • merge – combining your feature branch and its changes back into the official main branch

Let’s say your main branch works and has been fully tested. You then decide to build a new feature like a new button on a page, or even a simple text change. You create a new branch called “copy-change” from your main official branch. If something goes wrong during testing, then your main branch is still safe and it can be used to start over.

In the next activity, you will make a small update to your app, just to practice the branching and merging process in Github. 

ACTIVITY 1

Practice Github Workflow

Estimated Time: 20 Minutes

Go to Github.com, navigate to your repository, select the branch you worked on in the earlier technical unit.

You should notice a message that says that this branch is 1 commit ahead of “main”. 

This happens because we made code changes in that branch but never pushed those changes to the main branch. 

So let’s go ahead and do that by clicking on that message link.

github screenshot of branch out of sync message

Clicking the link will open GitHub’s Pull Request page where we can compare changes and then create a pull request.

  1. Add a title and description. Github may already have inserted a title from when you created the branch, but you can edit that and add a description of what you did.
screenshot of github pull request page

2. Click the green Create Pull Request button.

Since you’re the only owner of this repo, you are able to approve your own pull requests. In real life apps with multiple team members, it’s a common practice for another developer to review your request and collaborate with you if there are any issues. This is what is often called code review.  

  1. Click to merge the pull request and confirm the request.

    Notice that there is a two-step process here. It’s an important action so GitHub made it a two-step process to ensure that mistakes aren’t made.
github merge pull request window
  1. You should see a button to delete the branch you used to make the code changes. This keeps your repository clean and organized without leftover branches cluttering it up. Click the button to delete the branch.
  1. Navigate back to your repository.
  2. Select the main ” branch” on the top left of your repo to show the list of available branches. 
  3. Select “View Branches” and then create a new one.
  4. Give it a descriptive name for this stakeholder validation lesson.
  5. Click Create new branch. 

Tip: This step is optional but we highly recommend working on new branches every time you’re doing major updates. You can select to start this new branch from “main” or from another one depending on what your goal is. But it’s usual to start from the official main branch.

While we are opening a new branch, we are going to keep using the Codespace we used for the last lesson. Remember that we saved some feedback from family and friends in localStorage, which is stored in the browser, but tied to a particular URL. Each codespace has its own URL. If were were to open a new codespace, we’d lose that localStorage. 

So, for our Founder’s Toolkit work, let’s keep using the same codespace so we don’t lose that storage and have to retype it over and over.

  1. In Github, go to your Codespaces from the hamburger menu on the left.
  2. FInd your codespace from the last activity, and open it.

Because we deleted our old branch opened a new branch, we want to make sure our codespace updates the new branch.

  1. In the Terminal window at the bottom of the screen, type (on 2 separate lines):

    git checkout main
    git pull origin main

    This syncs your codespace with your main branch. 

  2. Type

    git checkout -b my-branch
    where my-branch is the name you gave to your new branch in Github in step 5.

This checks out the new branch so any updates, when committed and pushed, will go to the new branch. At the same time, you are preserving your codespace and your localStorage in the browser.

  1. Copy and paste this prompt in the Copilot chat section, which should be in the right-most pane.

Reduce the height of all the form entry fields to only one line

  1. Test the changes by typing python3 -m http.server 8000 in the terminal tab in the bottom panel.
  2. Check the running app to see that the form now has reduced height.

In the last lesson you committed and pushed those changes to Github using the Source Control feature in Codespaces. 

You were able to see the files that changed, added a commit statement, and clicked Commit to commit the changes to your repository branch.

source control feature in codespaces

You could do the same here. However, to see how to do it using terminal commands, follow these steps.

  1. Open the Terminal sub tab in the bottom panel.
  2. Click the + icon to open a menu.
  3. Select New Terminal.
  1. Type git status to see info on the branch.
    This tell you any changes you have made that may be ready to move forward in the code process. You should see something similar to this:
git status screenshot
  1. Read the message to see the changes made.
  2. Type git add . to stash your changes. The “.” means that you’re staging all the files changes.
  3. Type git status again to verify that your changes are staged and ready to be committed.
  4. Commit your changes by typing git commit -m “Update form height”.
    “Update the form height” is what’s known as the commit message and it’s important to be descriptive enough for you and anyone else that will review the commit.

  5. Now push to GitHub by typing git push origin tech-unit-2-activity1-updating-form (or whatever you named your branch after origin).
    This tells git to push your commits to the remote Github repository (origin) and put them in the specified branch, in this case, “tech-unit-2-activity1-updating-form”.  

    Tip: Using the -u flag, as in git push -u origin tech-unit-2-activity1-updating-form, sets the origin and your branch to the default, so future commands only require git push.

  1. Return to Github in the browser, and go back to your branch where you pushed those changes.
    You should see a message that there was a recent push on that branch.
  2. Click Compare & pull request that should initiate the flow that you learned in previous steps.
  1. Complete the steps to create pull request and merge the changes to the main branch.

In this case, you can keep your branch to use for the remaining activities in this lesson rather than deleting it.

In the previous technical lesson, you made an input form for your problem statement and friends and family feedback in your Founder’s Toolkit. In this next activity, you’ll add a new tab to your Founder’s Toolkit to allow the input of stakeholder information and feedback that you conducted in the Problem Refinement lesson.

ACTIVITY 2

Create Your Stakeholder Tracker

Estimated Time: 30 Minutes

Go to Github.com, and navigate to your Codespaces and open the one from the previous activity  or you may already have it open in a tab from the last activity.

In Codespaces, in the Copilot panel, add the following prompt.

Add a Stakeholder Tracker Tab where I can view my stakeholder feedback in a structured manner,

The Stakeholder Tracker tab should have:

  • Title: “Stakeholder Tracker”
  • Subtitle: “Manage your interview research”
  • A Form with the following fields:
    • Name (text)
    • Type (dropdown: interview, survey, email, text)
    • Key Feedback (insights, concerns raised, what resonated) (textarea)

When the button is clicked:

  1. Store all information in localstorage records, JSON format
  2. Display all stakeholder information in a table at bottom of screen
  3. Show a success message after adding a record successfully

Other guidelines:

  • Keep UI clean and consistent

 

Note about data storage: 

Your stakeholder data is saved in your browser’s localStorage, which from Tech Unit 1, we learned that:

  • Your data may persist between browser sessions, but it’s specific to this browser on this device
  • Also, if you clear your browser data or use a different computer or start a new codespace environment, you’ll need to re-enter your data

For now, this is fine for organizing your research. In later units, you’ll learn about cloud storage for permanent data.

 

This is what our Founder’s Toolkit looks like using this prompt. Your app may look different.

stakeholder tracker form
  1. Enter the information from your AIVA 3: Stakeholder Validation worksheet in the form.
    Note that we left the form minimal and open-ended, so do your best to enter important information you gathered from each stakeholder.
  2. Check that all information entered appears in the table.
  3. Also check localStorage using the Developer Tools to see that all information is stored properly in JSON. 
full screenshot of stakeholder tracker

 

We will continue to add to the app in the next activity, so there is no need to commit and push your changes yet.

Note: Free Copilot use is limited to:

  • 50 chat messages/month
  • 2000 code completions/month (inline code)

Because of this, you should be careful with how many chats you initiate with Copilot in Codespaces. If you run out of credits, it won’t reset until the next month. In that case, you can use other external LLMs (Claude, Gemini, ChatGPT) to help you with your code. While not as immediate as embedded Copilot, they all have the capability to assist you in coding.  You will just have to copy/paste code (in both directions).

Connecting to AI Services

You’ve been able to organize your stakeholder feedback in this tab. And you’ve already done some analysis of the information you have gathered.

Now is a great time to put AI to work to help spot patterns you might have missed. It’s a collaborative tool to help advance the great work you’ve already done.

In this part, you’ll connect your app to a real AI service and build a Feedback Analyzer that surfaces insights from your stakeholder research.

We will use Google’s Gemini as the LLM because it has generous free limits on powerful LLM models.

How AI-Powered Apps Work

You probably used ChatGPT, Claude, or Gemini before. But have you ever wondered how other applications such as Notion, Grammarly, or Duolingo incorporate AI features into their products?

They don’t build their own AI models from scratch. Instead, they connect to existing models and AI services via APIs. We will get into more details in later units, but here are the basic concepts.

An API (Application Programming Interface) is simply a way for one piece of software to talk to another. When your application requires AI capabilities, it sends a message to an AI service, and the service returns a response.

This exchange usually takes less than a few seconds. Your app sends an AI API request, waits for a response, and then displays the result.

This is How Every AI App Works

Once you understand this pattern, you can add AI to any app you build.

Choosing an AI Provider

Similar to how you can choose between different cloud storage providers (Google Drive, Dropbox, iCloud), you can choose between different AI providers. Here are some options:

Provider

Free Tier

Known For

Google (Gemini)

Generous with top models being offered

Apps that require multiple models at the best ratio of performance and cost

OpenAI (ChatGPT)

Limited (free tier only via their ChatGPT app)

First company to have a public LLM model, and it is the industry standard

Groq

Good for development, 30 request/min and 1000 tokens/minute, no credit card required

Provider of LLM models in the cloud. Best for apps that require different models for different use cases, including open-source models

Anthropic (Claude)

Limited (free tier version via their Claude app)

Apps that analyze long documents, logic, and reasoning

For this course, we recommend Google’s Gemini models because:

  1. Google doesn’t require a credit card to access its AI APIs
  2. Generous free tier with very good frontier models
  3. Very easy setup: You can get an API key in under 5 minutes
  4. Good documentation: Easy to troubleshoot if something goes wrong

The concepts you learn here transfer to any LLM provider. If you later want to use OpenAI or Claude in your production app, the code and structure are almost the same. It often just requires a different API Key.

What are API Keys?

When you use Google Drive, Google knows who you are because you’re logged in. But when your code talks to Google’s AI, how does Google know it’s you?

That’s what an API key is for. This is a simple authentication method that works similarly to a password. There are other authentication methods that we will cover in later units. 

API Keys are usually a long string of characters that looks something like this:

AIzaSyB1234567890abcdefghijklmnopqrstuvwx

When your app makes calls to the Gemini’s API, it includes this key. Google checks the key, confirms it belongs to a valid account, and processes your request.

Why API Keys Must Stay Secret

Since API keys are like passwords, they must be kept secure. 

 If someone gets your key, they can cause a lot of harm, such as:

  • Use your API quota, which can add up in charges on paid accounts, or use up your free quota. It can get very expensive.
  • Get your account suspended for abuse, which is really bad

This happens more often than you’d think. Developers sometimes accidentally upload their keys to GitHub, and automated bots can find them within minutes.

For this unit, we’ll use a simple and effective approach: we will store the key in a local file that is accessible only in Codespaces at runtime. It consists of:

  1. An .env file: A special file that stores configuration
  2. This file needs to be added to the .gitignore file so Git knows to never upload it to GitHub cloud
  3. A code package called “dotenv” will load the key from the environment

This keeps your key on your local development environment or local computer, never in your repository.

In later units, you’ll learn about more secure and safe ways to authenticate, such as using GitHub Secrets.

IMPORTANT NOTE ON SECURITY:

 In your Codespaces environment, your API key stays secure because the server handles API calls. In a production app, you’d need additional security measures which you’ll learn in later units. For more info on Codespaces, go to Security in GitHub Codespaces

ACTIVITY 3

Set up LLM Integration and Build Your Feedback Analyzer

Estimated Time: 45 Minutes

  1. Go to aistudio.google.com
  2. Sign in with your Google account (or create a new account)
  3. Navigate to the Dashboard -> API Keys page
  4. If you are new to AI Studio, Google generates a default Gemini API key for you. You still need to click “Create API Key” and it might require you to create a cloud project too.
    If you have used AI Studio before, check for something like “Default Gemini API Key” on this screen.
    Also, if you have any existing projects in Google Cloud, AI Studio might require you to either choose one of those existing projects to attach the API key to, or you might consider creating a new project in Google Cloud Console and attach the new API key to that new project.
default api key in list in google ai studio
  1. Add a descriptive name that lets you remember which app is using the key. If you are using the default key, click on the 3 dots on the far right to rename the key.
  2. You may copy the key and store it in a secure location temporarily. We will use it later.
copy api key in google ai studio

Tip: We recommend having one API key per app that you create to better manage and control usage. In later units, you will also learn additional best practices, such as maintaining distinct API keys for each environment.

Navigate to your Codespaces in Github and open the codespace from Activity 2.

If you already committed and merged your changes and deleted the branch, go through the steps to make a new branch and sync your codespace back with the main branch and checkout the new branch.

Remember that API Keys are like passwords. We need to store it in a special way in our code so Git knows to ignore it and keep it off the GitHub Repository, where anyone else could see it. 

  1. Go to the File Manager in the left panel: Click the icon that looks like two documents in the top-left sidebar.
  2. Create a new file: Hover your mouse over your project name (the root folder). Click the small plus icon (+) labeled “New File”.
  3. Name the file .env  (note the dot in the filename) and add this text through the editor in that file and save it. 

GEMINI_API_KEY=<paste your key here>

For example:

GEMINI_API_KEY=AIzaSyB1234567890abcdefghijklmnopqrstuvwx

  1. Find .gitignore in the File Manager and open it.
  2. Make sure it includes these two lines of text:
    • .env 
    • node_modules/

These two lines instruct Git to ignore these files and folders in all commits, so they don’t get stored back on the Github server.

The first line is for the API key file (.env), and the second is for all the code packages that our app requires to run. It’s recommended to include folders containing code packages, as we don’t want to use all our allotted space on GitHub for them. Copilot may have automatically added many more files and folders to ignore, but search to confirm that .env and node_modules/ are present in the file.

If not, then add them in new lines and save the file.

  1. Verify that the .env file is ignored by typing git status in the terminal window.
  2. Check what git status returns to make sure you do not see .env listed. If you do, ensure that your .gitignore file is saved correctly, and includes the .env line we added.

Your current app is not enabled to read .env files on its own. That is why we need to install a popular code package called “dotenv,” which loads your environment variables, so your code can access the API key without it being written directly in your code.

There are other alternatives, but this is one of the most common approaches, and most developers are familiar with it. 

  1. Go to the terminal panel and type npm install dotenv
  2. Wait for the package to be installed (it should do it in just a few seconds)

Now that you’ve added the API Key in a safe and secure way and installed the code package “dotenv” that can load your environment variables in your .env file (your API Key), you’re ready to use Copilot to add the Feedback Analyzer module.

Copy and paste this prompt:

Your task is to make the following changes:

  1. Create a new tab called “Feedback Analyzer” with the specific instructions below

For the Feedback Analyzer tab:

  • Add a subtitle with the text “Find patterns across all your feedback”
  • A field for the user to enter the problem.
  • A button to “Save Problem” and store it in localStorage.
  • A button “Analyze All Feedback” 
  • An output area for results

When the Save button is clicked, the problem is stored in local storage.

When the Analyze button is clicked:

  1. Query the problem and all the stakeholder records stored in localStorage.
  2. Send all the problem and stakeholder feedback information to the AI for analysis by making an LLM API call to Gemini.
  3. Show the AI analysis results as  returned by the LLM.

AI Prompt: 

Use the following system instruction prompt:

“You are an expert business analyst. Analyze the stakeholder feedback provided as it relates to the problem and structure your response with the following sections:

  1. PATTERNS: What themes appear across multiple sources? (3-5 bullets)
  2. SURPRISES: Where sources disagree and what that might mean (3-5 bullets)
  3. ASSUMPTIONS TO REVISIT: What assumptions were challenged or proven wrong? (3-5 bullets)
  4. RED FLAGS: What concerns or risks surfaced? (3-5 bullets)
  5. TOP 3 INSIGHTS: The most important takeaways for your problem (3-5 bullets) “

Technical Requirements:

  • Use local env environment to load the API Key
  • Add a simple backend  Node.js/Express server to read from .env
  • Make an API request using the Gemini API Key, following their API spec guidelines
  • Use Gemini Model “gemini-2.5-flash” with the following configuration:

Temperature = 0.7

Note the technical requirements. Because we want the API key to be read from the .env file to be more secure, it requires a backend server to do this. That is why we are asking it to use the Node.js/Express server. 

Copilot might prompt you to install express, node, and @google/generative-ai packages. Follow its instructions to install required packages. 

Tip: It is impossible to keep track of all Google’s latest models. As of January 7th, 2026, “Gemini 3 Pro” is Google’s latest and most powerful AI Model, and it’s available for free in Google AI Studio with certain limits. Typically, it is recommended to use the most advanced, free model available at this early stage of your AI business idea process. But once you deploy, you need to ensure you select the right model that meets your specific needs and balances cost and performance. Gemini Pro 3 is very expensive to run in live production and should be used wisely.

Once the AI has finished building the module, you can test it.

  1. Install any dependencies needed, as instructed by Copilot.
  2. Before running your app, check that Copilot added the correct Gemini version (for January 2026!)
    • Open server.js
    • Search for the string “generativelanguage.googleapis.com” and check that is using gemini-2.5-flash. 
  1. Run the app by typing npm start in the terminal panel.
    This is a different command because now you are running a backend server so there are dependencies.
  2. npm start will open a different port (3000) so it has its own localStorage.
    You will have to reenter the stakeholders and feedback into the app.
  3. Then navigate to the Analyzer tab and enter your problem statement and save it.
  4. Click the Analyze All Feedback button to call the Gemini API. 
  5. Wait for the results. It may take a few seconds. 

What you should see:

  • The AI analysis should synthesize all the feedback from all your stakeholders
  • The output should be organized into the sections prompted

What if it doesn’t work:

  • Check that your API key is correct and stored in the .env file
  • Ask Copilot (or another LLM) to help you debug the issue.

Take a few minutes to read the output from the Gemini API. You might want to copy the output and save it in a document for future reference.

Here are some things to consider:

  • Which patterns have high confidence that the AI detected that you wouldn’t have caught by yourself? Also, the reverse. 
  • Did stakeholders say something different from friends and family?
  • What gaps might you need to explore further?
  1. Once you are satisfied that the Analyzer works well, commit and push your changes to Github, either using the Source Control feature in Codespaces, or typing the git commands in a terminal window.
  2. Open Github and your repository in a new window, find the commit for your branch, create a pull request, and merge it.
  3. To keep things organized, you can delete the branch you created for this unit.
  4. Close the codespace tab to save your codespace credits (see tip below) but do not delete the codespace. . 

Tip: Your free Github account gives you a limited amount of time in Codespaces (as well as limited Copilot credits). For Codespaces, you get:

  • 120 core-hours/month (on a common 2-core machine that means about 60 hours/month)
  • 15 GB of storage

This should be enough Codespace use for this project.

It is good practice to close the codespace browser tab when you finish working in a codespace, so you are not using up any idle time that counts towards your monthly allowance. You can always open it again by accessing it from your Github account. 

Codespaces will automatically be deleted after 30 days of non-use. However, if you have committed and pushed changes, you won’t lose any code, even if the codespace is removed. You can always create a new codespace in Github.

Reflection

You spent a good amount of time vibe-coding to create a Founder’s Toolkit app to store and synthesize various pieces of information. Here are some questions to think about:

Sunset and reflection over lake
01

Organization
How does having all your feedback organized in one place change how you think about your problem?
02

Patterns
What patterns did the AI synthesis find that you hadn't noticed when reading feedback separately?
03

Your MVP
How might you use AI analysis in your own app to help users?

Key Terms

  • Git — A version control system that tracks every change made to your code over time, allowing you to undo mistakes, experiment safely, and collaborate with others.
  • Branch — A parallel copy of your codebase where you can develop new features or make changes without affecting the stable main version.
  • Commit — A saved snapshot of your code changes at a specific point in time, accompanied by a descriptive message explaining what changed and why.
  • Pull Request (PR) — A formal proposal to merge changes from one branch into another, often used as an opportunity for code review before changes become official.
  • Push — Uploading your local commits to a remote repository on GitHub so they are saved in the cloud and accessible to collaborators.
  • Repository (Repo) — The central location where all your project’s files, folders, and version history are stored, either locally or on GitHub.
  • API (Application Programming Interface) — A standardized way for two pieces of software to communicate. When your app needs AI capabilities, it sends a request to an AI service’s API and receives a response.
  • API Key — A unique secret string that authenticates your app to an external service, functioning like a password that identifies who is making a request.
  • .env File — A hidden configuration file used to store sensitive values like API keys locally, keeping them out of your source code and away from version control.
  • .gitignore — A file that tells Git which files and folders to exclude from commits, preventing sensitive data (like .env) or unnecessary files (like node_modules) from being uploaded to GitHub.
  • dotenv — A code package that reads your .env file and makes its values available to your application at runtime, without hardcoding secrets into your code.
  • LLM (Large Language Model) — A type of AI model trained on vast amounts of text that can understand and generate human language, used here to analyze and synthesize stakeholder feedback.
  • LLM Temperature — A parameter that controls how creative versus predictable an AI model’s responses are. Lower values produce more consistent outputs; higher values introduce more variety and creativity.
  • npm (Node Package Manager) — A tool used to install and manage reusable code packages (like dotenv and Express) that add functionality to your project without writing everything from scratch.

Additional Resources

Lesson Content
Previous Quiz
Back to Course
Next Quiz