Skip to content

Project 4: Sprint 3

This project assignment is worth 1300 points.

This homework is to be done as a team.

P4 is due on Gradescope, Monday April 20, 2026 11:59pm.

Submission

Submit P4 as a PDF file to Gradescope.

If you prepare the response in some other software (like Tex), please export as PDF before submitting. Include your name and Andrew ID at the top of the document.

Learning Goals

  • Use Large Language Models (LLMs) as part of an automated workflow -- not only to chat, but to drive repeatable steps in your engineering process.
  • Integrate automation with GitHub Actions (and related CI patterns) so that generation, verification, or review runs in a controlled, inspectable way.
  • Apply coding agents (for example, Claude agents or similar) where they help, and document what you chose and why.
  • Deliver three new user stories end-to-end: implementation, automated testing in CI, and automated code review assistance. Keep humans in the loop for judgment, security, and merge decisions.

1. Project Context

In P2, you used LLMs to produce user stories, UI, and code. In P3, you focused on verifying that work with human-readable specs and machine-run tests. In this sprint, the emphasis shifts: how much of that loop can you automate responsibly using LLMs?

You will add three new user stories to your product (stories that were not already implemented and merged before this assignment). For each story, you will use LLMs to help with:

  1. Code generation — producing or refactoring the implementation toward the story.
  2. Testing — producing tests that run in your test framework.
  3. Code review — an LLM-assisted review step that runs as part of your process (for example on pull requests).

2. Three new user stories (100 points)

  1. Write three new user stories for your startup application. Each must follow the same expectations as in P2: proper template (“As a \<user> I want \<action> so that \<benefit>”) and machine and human acceptance criteria.
  2. Each story should be small enough to design, implement, test, and verify in roughly two weeks or less; split or merge if needed.
  3. Create GitHub Issues for all three. Turn in the Issue URL for each story.
  4. Briefly justify in your PDF why these three stories are the right next increment for your product after P3.

If you used an LLM for any part of this section, attach a chat log or a shareable URL to the chat, accessible to all 17-356 instructors.

3. Automated code generation for each story (200 points)

For each of the three user stories, use an LLM as part of a repeatable workflow to help generate or complete the implementation (frontend and/or backend as appropriate). Your submission must make clear:

  1. What was automated and how you did it — for example: agent instructions, Action steps, scripts, or a documented sequence that you run the same way for each story, not only one-off messages.
  2. What humans were responsible for — merges, security-sensitive configuration, product decisions, and fixes when the model was wrong.
  3. Evidence — branch and PR history showing the work for each story; each story should land via a pull request merged to main (or your team’s equivalent), following your team’s process from P2 (code review before merge; Kanban updated).

Turn in:

  • A URL to the merged PR for each of the three user stories, labeled with which story it implements.
  • In the PDF, a short note for each of the three user stories, explaining what you asked the automation to do, what worked, what failed, and how you corrected course.

Attach chat logs or shareable URLs accessible to all instructors.

4. Automated testing in CI (200 points)

For each of the three user stories, use an LLM to help author machine-executable tests that exercise the behavior of that story. Requirements:

  1. Use a real testing framework (e.g., Jest). You may not substitute "the LLM ran it once" for automated tests.
  2. Tests must run in GitHub Actions (or another CI system your repo uses, with equivalent visibility) on relevant events, for example pull_request or push to your integration branch. Document which workflow file(s) run the tests.
  3. The LLM may write the tests.
  4. The LLM must also follow good GitHub hygiene. As a reminder, it must
    1. Create a GitHub Issue work item to track the creation, development, and checkin of the tests and connect this issue to the GitHub Issue for the user story being tested.
    2. Create a new branch for working on the tests
    3. Connect its commit of the test code to the GitHub Issue
    4. Having the tests code reviewed prior to submitting a PR
    5. Have that PR reviewed
    6. Accept the PR to merge the test code into the main branch of your repository.

In your PDF, for each story:

  • Describe which tests correspond to that story and what they assert.
  • Paste or link to a successful CI run that executed those tests (for example a link to the Actions run summary).

Turn in a URL to a PR (can be the same as implementation or a dedicated test PR) that added or updated the tests for each story, or clearly identify the commits in a merged PR.

Attach LLM chat logs or shareable URLs accessible to all instructors.

5. Automated code review (200 points)

For each of the three user stories, put in place an LLM-assisted code review that runs as part of your development workflow, not only a human typing questions into a chat window, but automation you can point to. Examples (you are not limited to these):

  • A Claude agent (or similar agent) that comments on pull requests or summarizes diff risk.
  • A GitHub Action that invokes an LLM with a structured review prompt and posts results on the PR.
  • A required or documented step in your PR template that runs a scripted review before human approval.

Requirements:

  1. Repeatability — another teammate (or the staff) should be able to see how review was triggered and where output appears (PR comment, check run, artifact, etc.).
  2. Human judgment — your team still approves merges; describe how you used LLM output versus human review.
  3. Per story — show that the automated review was applied to the PR(s) for that story (link to the PR with visible bot/agent output or workflow logs).

Turn in:

  • For each story, a URL to the pull request where the review feedback is visible, plus one paragraph on what you changed (if anything) after seeing the automated feedback.

Attach chat logs or shareable URLs accessible to all instructors.

6. Automated development specifications (200 points)

For each of the three user stories, put in place an LLM-assisted code documentation process that runs as part of your development workflow, not only a human typing questions into a chat window, but automation you can point to.

Whenever a PR connected to a feature that implements a user story is approved, your automation should ask an LLM to generate/update a development specification (as specified in P2) and check it into your repository (of course, following proper GitHub hygiene).

Turn in:

  • The prompts used to generate a new development specification. Make use of the prompts you developed in P2.
  • The prompts used to update an existing development specification after the user story or the code that implements it has been updated.
  • For each story, provide
    • A URL to the approved pull request that contains the commit(s) and review of the development specification to the repository.
    • A URL to the GitHub Issue that was created to track the creation of the development specification (it should be linked from the commit(s)).

Attach chat logs or shareable URLs accessible to all instructors.

7. Automation architecture summary (required in the PDF) (100 points)

Include a section that covers:

  1. A diagram or bullet-level pipeline: what triggers what (for example: open PR -> Action runs tests -> Action or agent posts review then human approves).
  2. Setup instructions covering how a developer can setup your workflows and automations if they are new to the project.

8. Landing page for product web site (200 points)

On Friday, April 3, you were asked to develop a landing page web site for your startup's product. In this sprint, you will complete the content and publish it online.

Requirements:

  1. The content presented on the web site must be complete.
    1. No dead links
    2. No pointers to web pages that you did not and do not plan to implement.
    3. All graphic placeholders are filled in with final pictures.
    4. All videos (including screen recorded demos) are narrated and visibly captioned. Screen recoordings should magnify font sizes to be fully legible.
  2. There must be at least 2 distinct calls to action.
    1. One call to action must provide a way to download the app, register an account, and/or log into the product (if it's a web site). This link/download must actually work. Yes, you need to have shipped a working prototype by the time this Sprint is over.
  3. The web site must have at least 5 informational sections.
  4. The web site must have an About the Team section with photos, team roles, and bios for everyone. This section has to impress investors as well as customers.
  5. Reminder: Your app is targeted at the Pittsburgh community. Please include references to that on the web site to show Pittsburgh that they hold a special place in your team's heart.

Turn in:

  • A URL to your publicly accessible web site.
    • Note, if your startup needs remain in stealth mode, put a password on the site and give access to the instructors.
  • A URL to the GitHub repository that contains the source for your web site.

9. Working Prototype (100 points)

On Monday, April 20, when this Sprint is over, you must have a working prototype that everyone in the class can use (on their own computers, web browsers, tablets, and/or phones). Your app must be deployed live and running from the time you turn in this assignment until the end of finals, Tuesday, May 5, 11:59pm.

On Tuesday, April 21, we will hold an in-class Bug Bash. Everyone in the class will try out your startup's app by testing out your app's user stories. To successfully allow newcomers to try out your user stories, your app must either 1) support live, automated account creation or 2) have prebuilt accounts (at least 30 accounts) with pre-canned content. If your user story requires uploading tons of content before it is human-testable, create a prebuilt account with all the content required, and direct your users to test just that user story with the prebuilt account.

If your classmates find any bugs, they will file them immediately in your team's GitHub Issues page. Your team must address (fix or close) all filed bugs by the day of the final presentation, May 4, 2026.

Turn in:

  • A URL to use your app. This can be a download URL for a desktop app, a URL to a web application, a URL to an app in some app store, etc.
  • Any pre-built account information required to evaluate the app. Do not submit the account name/pw information in your assignment. Instead, post account information in your team's private Slack channel and the instructors will use/distribute it securely to the class as needed.